"Wan-Teh Chang" <[EMAIL PROTECTED]> schreef > Tom wrote: > > > > > My question is how Netscape 6.2.* handles this kind of stuff. At first sight > > Netscape 6.2.1 passes the test: I have imported a self generated client > > certificate into Netscape 6.2.1 and use it to visit my test-webserver which > > requires both server and client authentication. After that, my > > PhysicalMemoryScanner doesn't seem to find the private key. So I would like > > to ask you all if special care was taken to avoid that the private key shows > > up plain-text in memory ? > > > Yes. NSS (the crypto libraries used in Netscape 6.2.*) keeps its > private keys "wrapped" (encrypted) until actually needed.
But how is the key data-structure handled *after* it was used ? 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. 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 ? 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.
