Hey there, On Thursday 07 Nov 2002 6:13 pm, Eric Rescorla wrote: > I'm not one of the developers, but I have it pretty hard to get excited > about this sort of thing.
Well I'm tempted to agree with you - a lot of the whole key-scanning attack hoopla has been wildly overstated, and from both ways of looking at it; (a) It's not as bad as some like to make out. There are a variety of ways to stamp out key-scanning attacks - the most obvious of which, of course, is to not let untrusted code run inside the same process nor as the same user as a process holding/managing SSL keys! The argument that "keys in memory" poses a security risk is, IMHO, logically equivalent to saying that network architects who let 3rd parties run CGIs/libraries in the same process as their SSL/TLS applications should be forced to community service. (b) The "solutions" to this problem aren't as good as some like to make out. Eg. putting the keys in hardware, which is essentially the same as putting the keys anywhere else out of reach (eg. different process, different user account, different machine), will only stop you reading/copying the key-data - it doesn't implicitly stop you doing key operations. AFAICS, keys are only useful for doing key operations so being able to do key operations is all you really need. The subtle difference is that if you can read keys, you will *always* be able to do key operations (key-revocation isn't that effective yet), whereas otherwise your attacks last only as long as they go untreated. But you may only need one key operation performed fraudulently to do quite some damage (eg. I could sign a CRL request for your expensive cert/key). So the scope of risk is a little different, but the absolute "is it secure or isn't it?" exposure to it is much the same. > In the case of SSL in particular, the private key is generally > kept in memory for the life of the process. If it's not zeroed, > there's not a lot of point in zeroing other keys, since compromise > of the private key is usually sufficient to reveal all other keys. Yes, although the argument does at follow that you have the *option* of putting SSL/TLS keys outside the realm of "copy" attacks (putting aside the issue of "unauthorised key operations" for a moment). Session keys on the other hand pretty much have to be in-memory whether you like it or not, you don't get much choice about that. So correct zeroing may perhaps make some people feel better. Note, on the possibility of having session secrets in hardware too ... there are ways to do it, the most obvious of which is to rewrite an SSL/TLS implementation from scratch to support it. You'd also need a hardware device that supports the necessary logic, but that may also exist. However, you really start to wander aimlessly (and expensively) into the territory of calling something "secure hardware" because it's just a computer that can't do anything except security. Computers that can't do anything except security are quite straightforward to create already - eg. install an SSL/TLS (or HTTPS-forwarding) proxy on a linux box and disable all other services. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
