[cryptography] Best practices for paranoid secret buffers

Jeffrey Walton noloader at gmail.com
Wed May 7 08:15:54 EDT 2014


On Tue, May 6, 2014 at 11:56 PM, Tony Arcieri <bascule at 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


More information about the cryptography mailing list