nCipher chief is standing down
<http://www.cambridge-news.co.uk/business/news/2007/06/26/2105e214-4586-4393-92be-1387bdff1fd9.lpf> CEN : Businesss : News : nCipher chief is standing down ALEX van Someren is to step down as chief executive of nCipher after 11 years. Neil Lloyd will join the company as chief operating officer and a director on July 1 and it is planned that he will replace Mr van Someren on January 1 next year. Mr van Someren will remain on the board as a non-executive director after he has stepped down. He said: "Neil's leadership qualities and management experience will help drive the continued growth and success of the company. "After 11 years as chief executive officer, I have decided to step down and I am looking forward to working with Neil during this period of transition." Nicko van Someren will resign from nCipher's board with effect from July 1. He will continue as chief technology officer and the company hopes to appoint an additional, independent non-executive director to the board later this year. -- ----------------- R. A. Hettinga <mailto: rah@ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
OK, basic question (I think)... Let's say I have some kind of stored reputation or identity that communicates with the outside world. Let's say I am able to access the server that this identity is stored on securely, and I do so for the purpose of updating information, etc, that I want to share with the outside world. (Let's assume the sharing process is gated my either me or an autonomous process running on that server.) What is the protocol for locating and updating my identity on that server without anyone else being able to determine which identity I am accessing? Let's assume that I always initiate a session from the same IP address, and that the identity is encrypted. What I don't want is for anyone to see that "I" always access identity No. 268. In other words, observers know... 1) I use this service 2) Many others use this service 3) One of the identities visible to the outside world is me But what I don't want them to know is which identity in the outside world is me. Is this even necessary? Am I in effect protecting against someone taking a core dump of the server, or are the issues more significant than this? -TD _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm
On Wed, June 27, 2007 10:49, Tyler Durden wrote:
Let's assume that I always initiate a session from the same IP address, and that the identity is encrypted. What I don't want is for anyone to see that "I" always access identity No. 268.
If we can also assume that you perform this update over a secure connection, then (also assuming the secure protocol used is intact) no one outside of the identity server can see the contents of the session. The update protocol should also perform basic protective steps, such as making all traffic of uniform size, using good-quality randomness for padding and the like.
Is this even necessary? Am I in effect protecting against someone taking a core dump of the server, or are the issues more significant than this?
Essentially, you *can't* prevent Mallory the Evil Admin from doing 'sudo cat /dev/kmem > chump_dump.img'. So you need to tune your threat model accordingly. You face two attack surfaces: your connection to the identity server (which is probably defendable) and the server itself (which, if we posit local hardware access by Mallory and Co., is toast and he already knows you are Number 268). I'd think the method of choice would be to intermediate the update process. If updates can be done with an encrypted blob in an email, you can use the remailer networks and Tor to break the connection between "you" and "268" so Mallory only knows that someone with the right keys is updating 268. Even if direct connections are necessary, a Tor session should help by making sure that updates to 268 always come from different IPs. Even if it's only a describable set of exit nodes, all Mallory knows is that 268 is Tor-literate. But overall, if you don't trust the admin crew, how do you trust the server itself? And should you even be placing your credentials in its care in the first place? -- Roy M. Silvernail is roy@rant-central.com, and you're not "Antelope Freeway, one sixty-fourth of a mile." - TFT CRM114->procmail->/dev/null->bliss http://www.rant-central.com
Roy Silvernail wrote...
I'd think the method of choice would be to intermediate the update process. If updates can be done with an encrypted blob in an email, you can use the remailer networks and Tor to break the connection between "you" and "268" so Mallory only knows that someone with the right keys is updating 268. Even if direct connections are necessary, a Tor session should help by making sure that updates to 268 always come from different IPs. Even if it's only a describable set of exit nodes, all Mallory knows is that 268 is Tor-literate.
Well, there's still the problem of private information on the server being leaked to the publically-accessible side. In other words, let's say I want to store my income on the server and then release it to certain other users in exchange for a payment. Of course, I could store such private information on my own machine, but this is problematic for several reasons (including the fact that I may want some of this information to be automatically released to anyone willing to pay the $ for it, meaaning I don't want to have to initiate a Tor session every few seconds). But I definitely don't want a user to be able to extract private info without paying for it, and perhaps there's some info I never want released publically. Now, having my admin not know who I am (or which reputation belongs to me) is even better, and hopefully would be solved via the same mechanism. -TD
From: "Roy M. Silvernail" <roy@rant-central.com> Reply-To: roy@rant-central.com To: "Tyler Durden" <camera_lumina@hotmail.com> CC: cypherpunks@jfet.org Subject: Re: Permanent secret identity Date: Wed, 27 Jun 2007 13:19:41 -0400 (EDT)
On Wed, June 27, 2007 10:49, Tyler Durden wrote:
Let's assume that I always initiate a session from the same IP address, and that the identity is encrypted. What I don't want is for anyone to see that "I" always access identity No. 268.
If we can also assume that you perform this update over a secure connection, then (also assuming the secure protocol used is intact) no one outside of the identity server can see the contents of the session. The update protocol should also perform basic protective steps, such as making all traffic of uniform size, using good-quality randomness for padding and the like.
Is this even necessary? Am I in effect protecting against someone taking a core dump of the server, or are the issues more significant than this?
Essentially, you *can't* prevent Mallory the Evil Admin from doing 'sudo cat /dev/kmem > chump_dump.img'. So you need to tune your threat model accordingly. You face two attack surfaces: your connection to the identity server (which is probably defendable) and the server itself (which, if we posit local hardware access by Mallory and Co., is toast and he already knows you are Number 268).
I'd think the method of choice would be to intermediate the update process. If updates can be done with an encrypted blob in an email, you can use the remailer networks and Tor to break the connection between "you" and "268" so Mallory only knows that someone with the right keys is updating 268. Even if direct connections are necessary, a Tor session should help by making sure that updates to 268 always come from different IPs. Even if it's only a describable set of exit nodes, all Mallory knows is that 268 is Tor-literate.
But overall, if you don't trust the admin crew, how do you trust the server itself? And should you even be placing your credentials in its care in the first place? -- Roy M. Silvernail is roy@rant-central.com, and you're not "Antelope Freeway, one sixty-fourth of a mile." - TFT CRM114->procmail->/dev/null->bliss http://www.rant-central.com
_________________________________________________________________ Who's that on the Red Carpet? Play & win glamorous prizes. http://club.live.com/red_carpet_reveal.aspx?icid=REDCARPET_hotmailtextlink3
participants (3)
-
R.A. Hettinga -
Roy M. Silvernail -
Tyler Durden