> > But how is the key data-structure handled *after* it was used ?
NSS is pretty agressive about clearing out key material and passwords. Private keys are not only stored in wrapped format, the wrapped format is flushed from memory and re-read from disk when needed. Now at this point, I believe an important disclaimer should be made: For any software token, once the integrity of the process memory has been compromised, all bets are off. Malicious programs can interpose themselves between the OS and application and steal passwords right from the keyboard. With the passwords, keys can be decrypted from the disk. If you are trying to protect yourself from these kinds of attacks, you should be using some sort of hardware token. That being said, NSS does try to protect against accidental key loss due to scanning core dumps, or generalized key scanning techniques. For the paranoid user, you can turn on FIPS mode for NSS. In this mode *NO* key material leaves the softoken unwrapped. You can then convince yourself that the softoken properly clears out key material after use. Even without FIPS mode, keys generally only leave the soft token when 1) They are wrapped (for key exchange purposes), 2) they are being transfered to another token, or 3) the application uses the key extraction interfaces. Neither PSM, nor the Netscape servers use the 3rd interface (typically only 3rd party applications will use these interfaces, and only after being lectured by me on why these interfaces are a bad thing(tm). These applications usually use the interfaces because the are trying to map some older crypto interface which does not have a strong notion of key protection and separation). Note the the above statement applies only to symetric keys. Token Private keys are never extracted unwrapped. (Temparary private keys may be, these are usually generated or unwrapped to insertion into some hardware token which cannot to key generation or unwrap operation on the token itself. In this case the software token is just used to unwrap or generate the key, it is copied to the token, then cleared from memory). Passwords and pins are never stored in the tokens. When you log into to softoken, a PBE is generated from the password, any local copies of the password are cleared, and only the PBE is maintained. Note that if you know where the PBE is, you can extract the PBE to decrypt the private key. That is why we do not keep even the encrypted private key in memory if we can help it. NOTE: we have less control over this part than others, it is possible that the OS and database caching system would keep the key in memory. That is way my second statement above. Just because it is harder to find the key in NSS memory, does not mean it is impossible. Applications can store pins and passwords indefinately, though any that were designed within reach of NSS developers do not. Communicator 4.X cleared out passwords once they were used. I'm pretty sure PSM does as well (most of that code was copied from Communicator). Servers need to keep passwords around to initialize other components that run as separate processes. They wrap the password with a generated key. When the new processes starts, the server unwrapps the password, sends it to the process, then clears the plain text password out. The process uses the password then clears it. > > At some point the private key will be needed in plain-text for the secure > connection. So it will resist in memory. Let's assume this is quite > harmless, since it is only for a short time. But it is important that the > key data-structure is cleared or overwritten after it is no longer needed. Yes, you can examine the entire life-cycle of the private key by examining the code in mozilla/security/nss/lib/softoken. Also note that these statements apply to the user's token, or permanment key. Temporary or "session" keys stay in memory in the clear for the lifetime of the key (though they are also cleared out after use). > > As my recent study shows, many tools do *not* clear/overwrite this... Simply > waiting untill all variables go out of scope is not enough. The memory will > indeed be 'recovered' by the Operation System, but this can take a long > time. Especially on todays PCs with a lot of RAM, there's mostly no need for > the OS to recover the memory quickly, so the key can stay in memory for a > 'long' time making it vulnerable for tools like a PhysicalMemoryScanner. > > So I can be sure that the memory of the (private) key itself is > cleared/overwritten by Netscape 6.2.* as soon as possible ? Most of this you can verify by looking at the softoken. The other place to look for is the PK11 wrapper code which does most of the key movement, and pretty much the only other place you will find in the clear key material. Victor's point about passwords would require checking the password code in the application. bob > > Also, as Victor Probo wrote, other components involving with 'secret' > information should also be aware of this and make sure they don't store it > in memory for a long time... > > > Thanks, > Tom. > > > >
