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