On Sat, Apr 12, 2014 at 09:02:50PM -0400, Salz, Rich wrote: > > Would you please elaborate on how it differs from what you've been > > using in production? > > Local platform issues, mainly. Conceptually, nothing different about > the security. >
Hello Rich et al. I believe Akamai's secure malloc, in current form, to be ineffective against heartbleed. In order to achieve ~4-fold improvements in RSA signing speeds, many implementations (including OpenSSL) bundle pre-computed Chinese remainder theorem parameters in private keys (so-called quintuple representation). [1] Akamai's secure malloc appears to only protect the private exponent (d) and two primes (p and q) leaving both CRT exponents (e1 & e2) and the first CRT coefficient (coeff) unprotected. However, the public exponent (e), modulus (n), and either CRT exponent (e1 or e2) is sufficient to recover a prime and therefore the full private key. Rather than plaster math equations here, I've attached a small perl script that demonstrates this by way of an example. Recommendation: protect the rest of the private key material. My analysis has focused on problems related to *what* should be protected not on the effectiveness of *how* it is protected. The *how* also merits close review. One immediate observation I have on that front is that secure_malloc_init() is never called. --mancha [1] https://tools.ietf.org/html/rfc3447
akamai.pl
Description: Perl program
pgp4KhDIjk_fD.pgp
Description: PGP signature
