Re: [cryptography] Best practices for paranoid secret buffers
On Tue, May 6, 2014 at 11:56 PM, Tony Arcieri basc...@gmail.com wrote: Can anyone point me at some best practices for implementing buffer types for storing secrets? There are the general coding rules at cryptocoding.net for example, that say you should use unsigned bytes and zero memory when you're done, but I'm more curious about specific strategies, like: - malloc/free + separate process for crypto I think this is a good idea. I seem to recall the new FIPS 140 will have some language for it. I also seem to recall something about Microsoft's CryptNG, but I don't recall the details. - malloc/free + mlock/munlock + secure zeroing On Microsoft platforms, you have `SecureZeroMemory` (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366877(v=vs.85).aspx). It is guaranteed *not* to be removed by the optimizer. On Linux, you have `bzero`, but I'm not sure about any guarantees. On OpenSSL, you have OpenSSL_cleanse. OpenSSL_cleanse is most acrobatic of the three. - mmap/munmap (+ mlock/munlock) Keeping secrets out of the page file or swap file can be tricky. VMs can be trickier. Should finalizers be explicit or implicit? (or should an implicit finalizer try to make sure buffers are finalized if you don't do it yourself?) Not all languages have finalizers. Java has finalizers but tells you to put secrets in a char[] or byte[] so you can overwrite them manually: See, for example, http://docs.oracle.com/javase/1.4.2/docs/guide/security/jce/JCERefGuide.html#PBEEx (I think that link may be dead now). For those languages that do provide fianlizers, its sometimes impossible to ask them to wipe. See, for example, EditText and Sensitive Information (Wipe/Zeroize), https://code.google.com/p/android/issues/detail?id=36233. Are paranoid buffers worth the effort? Are the threats they'd potentially mitigate realistic? Are there too many other things that can go wrong (e.g. rewindable VMs) for this to matter? I think they are worth the effort. Target's data breach was the result of (among others): memory scraping malware. At minimum, they cost next to nothing. You also have wrapping. That is, a buffer get a quick dose of XOR to mask the secrets while in memory but not in use. .Net's SecureString uses wrapping (http://msdn.microsoft.com/en-us/library/system.security.securestring(v=vs.80).aspx), and NIST has a key wrap for symmetric encryption keys (http://csrc.nist.gov/groups/ST/toolkit/documents/kms/key-wrap.pdf). Maybe the later would have helped with Heartbleed, too... who knows. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Best practices for paranoid secret buffers
On 05/07/2014 05:56 AM, Tony Arcieri wrote: - malloc/free + separate process for crypto - malloc/free + mlock/munlock + secure zeroing - mmap/munmap (+ mlock/munlock) Separate process protects from a different threat than mlock/munlock (the latter prevents swapping out the pages to the swap device). Depending on your paranoia level, maybe scramble the buffer if it is held unused for a long time. The scrambling secret should be short enough not to stick out like a sore thumb in a memory dump. Although that probably won't help much (it works better if the secret key and the scrambling key are in different processes). ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Best practices for paranoid secret buffers
Mprotect() to keep stray pointers out. Obfuscate data kept in that memory. You can do a lot in software and in practice that might be enough. In theory, true security can only be achieved through hardware based security modules-atleast thats what I feel, others might disagree. Paranoid buffers do have some overhead involved but if that overhead is going to delay obtaining secrets from a memory dump, i'd say its worth it. On May 6, 2014, at 8:56 PM, Tony Arcieri basc...@gmail.com wrote: Can anyone point me at some best practices for implementing buffer types for storing secrets? There are the general coding rules at cryptocoding.net for example, that say you should use unsigned bytes and zero memory when you're done, but I'm more curious about specific strategies, like: - malloc/free + separate process for crypto - malloc/free + mlock/munlock + secure zeroing - mmap/munmap (+ mlock/munlock) Should finalizers be explicit or implicit? (or should an implicit finalizer try to make sure buffers are finalized if you don't do it yourself?) Are paranoid buffers worth the effort? Are the threats they'd potentially mitigate realistic? Are there too many other things that can go wrong (e.g. rewindable VMs) for this to matter? -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Best practices for paranoid secret buffers
On 07/05/2014 16:27, Swair Mehta wrote: Mprotect() to keep stray pointers out. Obfuscate data kept in that memory. You can do a lot in software and in practice that might be enough. In theory, true security can only be achieved through hardware based security modules-atleast thats what I feel, others might disagree. Paranoid buffers do have some overhead involved but if that overhead is going to delay obtaining secrets from a memory dump, i'd say its worth it. hello, does something like softHSM or ssh-agent helps? -br ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Best practices for paranoid secret buffers
On 5/6/2014 11:56 PM, Tony Arcieri wrote: Can anyone point me at some best practices for implementing buffer types for storing secrets? There are the general coding rules at cryptocoding.net http://cryptocoding.net for example, that say you should use unsigned bytes and zero memory when you're done, but I'm more curious about specific strategies, like: - malloc/free + separate process for crypto - malloc/free + mlock/munlock + secure zeroing - mmap/munmap (+ mlock/munlock) Should finalizers be explicit or implicit? (or should an implicit finalizer try to make sure buffers are finalized if you don't do it yourself?) Are paranoid buffers worth the effort? Are the threats they'd potentially mitigate realistic? Are there too many other things that can go wrong (e.g. rewindable VMs) for this to matter? -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography I do think it is worth the effort. Yes, what you are talking about takes extra work but it is better to be safe than sorry. I will say, however, that you should understand the read/write process is taxed. This is what I mean: Let's assume you set aside a chunk of memory. At some point it needs to be freed. How often do you wish the algorithm to do this? It is important to figure this out because your ram will be used and flushed (in part) over and over. -- Kevin ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Best practices for paranoid secret buffers
On Wed, 7 May 2014, Kevin wrote: [...] Should finalizers be explicit or implicit? (or should an implicit finalizer try to make sure buffers are finalized if you don't do it yourself?) Probably time to mention this classic: http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf In brief, can you trust your compiler? I'm told that one version actually escaped from BBN, but thankfully it ran on hardware (a P40, I think) that exists only in museums. -- Dave ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Best practices for paranoid secret buffers
On Wed, May 7, 2014 at 8:15 AM, Jeffrey Walton noloa...@gmail.com wrote: On Tue, May 6, 2014 at 11:56 PM, Tony Arcieri basc...@gmail.com wrote: Can anyone point me at some best practices for implementing buffer types for storing secrets? There are the general coding rules at cryptocoding.net for example, that say you should use unsigned bytes and zero memory when you're done, but I'm more curious about specific strategies, like: - malloc/free + separate process for crypto I think this is a good idea. I seem to recall the new FIPS 140 will have some language for it. I also seem to recall something about Microsoft's CryptNG, but I don't recall the details. - malloc/free + mlock/munlock + secure zeroing On Microsoft platforms, you have `SecureZeroMemory` (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366877(v=vs.85).aspx). It is guaranteed *not* to be removed by the optimizer. On Linux, you have `bzero`, but I'm not sure about any guarantees. On OpenSSL, you have OpenSSL_cleanse. OpenSSL_cleanse is most acrobatic of the three. - mmap/munmap (+ mlock/munlock) Keeping secrets out of the page file or swap file can be tricky. VMs can be trickier. Should finalizers be explicit or implicit? (or should an implicit finalizer try to make sure buffers are finalized if you don't do it yourself?) Not all languages have finalizers. Java has finalizers but tells you to put secrets in a char[] or byte[] so you can overwrite them manually: See, for example, http://docs.oracle.com/javase/1.4.2/docs/guide/security/jce/JCERefGuide.html#PBEEx (I think that link may be dead now). Right; in Java you can't count on when the finalizers will be called (they aren't like DTORs in C++), so you best do so immediately, probably in a 'finally' block to make sure it is done. Also, In Java, I suspect that you have to beware of JIT optimizers like HotSpot. In Java, disabling HotSpot or any other JIT on the server side is just not going to happen and AFAIK (would love to be shown I'm ignorant here), you can't disable JIT optimizers for just a few classes. [If you can, someone *please* tell me how.] [snip] Are paranoid buffers worth the effort? Are the threats they'd potentially mitigate realistic? Are there too many other things that can go wrong (e.g. rewindable VMs) for this to matter? I think they are worth the effort. Target's data breach was the result of (among others): memory scraping malware. At minimum, they cost next to nothing. You also have wrapping. That is, a buffer get a quick dose of XOR to mask the secrets while in memory but not in use. .Net's SecureString uses wrapping (http://msdn.microsoft.com/en-us/library/system.security.securestring(v=vs.80).aspx), and NIST has a key wrap for symmetric encryption keys (http://csrc.nist.gov/groups/ST/toolkit/documents/kms/key-wrap.pdf). Yes, in Java, the Cipher class supports the key wrapping, at least for AES. I'm never tried of for something else like DESede. Maybe the later would have helped with Heartbleed, too... who knows. Perhaps; it's doubtful that it would have hurt unless it was done in some way that would introduce some sort of blatant timing side-channel attack, which seems very unlikely if you always do it in the same place and in the same manner regardless. However, I don't think it's a panacea. Didn't someone have an attack where they were able to reconstruct AES encryption keys by recovering some fraction of the S-box values? I thought that was either Felten, et al, Cold Boot attack or something that was discussed in the literature around that time. Maybe I'm just blabbering here since I can barely remember what I had for lunch two days ago much less recall details of papers that I've read from 5 or 6 years ago. Anyhow, I'm sure someone on this list knows the details and I probably have it all wrong anyway. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ NSA: All your crypto bit are belong to us. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Best practices for paranoid secret buffers
Can anyone point me at some best practices for implementing buffer types for storing secrets? There are the general coding rules at cryptocoding.net for example, that say you should use unsigned bytes and zero memory when you're done, but I'm more curious about specific strategies, like: - malloc/free + separate process for crypto - malloc/free + mlock/munlock + secure zeroing - mmap/munmap (+ mlock/munlock) Should finalizers be explicit or implicit? (or should an implicit finalizer try to make sure buffers are finalized if you don't do it yourself?) Are paranoid buffers worth the effort? Are the threats they'd potentially mitigate realistic? Are there too many other things that can go wrong (e.g. rewindable VMs) for this to matter? -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Best practices for paranoid secret buffers
On Tue, 6 May 2014, Tony Arcieri wrote: Should finalizers be explicit or implicit? (or should an implicit finalizer try to make sure buffers are finalized if you don't do it yourself?) I've never trusted OSs that cleared buffers in the finaliser. Do it yourself, then you know it's done. For that matter, I've never trusted malloc() either, but at least calloc() promises to clear it. Are paranoid buffers worth the effort? Are the threats they'd potentially mitigate realistic? Are there too many other things that can go wrong (e.g. rewindable VMs) for this to matter? Even paranoids have enemies :-) -- Dave ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
