Ron Teitelbaum made a clever solution to resisting memory-scanning attacks when using private keys in an image. Upon asking KeyHolder holdKey: yourPrivateKey, it forks off a while loop which generates a random sequence of bytes (ByteArray) to encrypt yourPrivateKey with it. It then delays 100ms, decrypts the key and immediately re-encrypts it with a new set of random bytes (two new memory locations), and wiping the old random and old key ByteArray's. Repeat.
The result: a memory-scanner attack needs to find both pieces of information (the random number and the encrypted key) in the image memory within 100ms. Obviously this consumes some processing power and garbage collection, but it's not noticeable. On shutdown, all instances are automatically wiped, saved images are clean of private keys. It's part of the CryptographyCore package on SqueakSource. http://www.squeaksource.com/Cryptography/CryptographyCore-cmm.9.mcz On Tue, Sep 20, 2022 at 9:59 AM <[email protected]> wrote: > I feel compelled to revive this old (almost 10 years!) thread because I’m > faced with a similar problem and certain points seem unresolved. > > Assuming that one needs the actual password in the image (in my case to > authenticate via IMAP), Norbert’s suggestion to have a helper app that runs > with elevated privileges makes sense, but I’m wondering about a few other > comments: > > - > > Sven mentioned that it’s common to have sensitive info “lying around” > on the filesystem, with .ssh being an example. However, my (non-expert) > understanding is that the best practice to add a passphrase to one’s > private key protects against just such situations as we consider here, no? > - > > There seems to be a hard distinction drawn between memory and disk > storage. However, this being Smalltalk, this seems only to be the case if > the image is guaranteed never to be saved, otherwise its memory, including > any plaintext sensitive information, would end up on disk. > > As I was thinking through my use case, I was considering, for example, > storing the password in a non-string collection e.g. ByteArray, so that I > could use the password and zero it out in memory right afterward. >
