so i assume any intermediate values from the RSA computations will end up in the heap and may be accessible by an attacker. is it possible to reconstruct the key from these values?
i could be missing something but it looks like signing does m mod p and m mod q and part of these operations involves doing a left shift on the divisor (p, q) and this is allocated to a temporary buffer. if these buffers are allocated near the heartbeat buffers then they could be leaked.
i'm looking at crypto/rsa/rsa_eay.c and it is possible that this code is not the code that is being used to do the signing in ssl.
/* signing */
static int RSA_eay_private_encrypt(int flen, const unsigned char *from,
unsigned char *to, RSA *rsa, int padding)
{
..
..
if ( (rsa->flags & RSA_FLAG_EXT_PKEY) ||
((rsa->p != NULL) &&
(rsa->q != NULL) &&
(rsa->dmp1 != NULL) &&
(rsa->dmq1 != NULL) &&
(rsa->iqmp != NULL)) )
{
if (!rsa->meth->rsa_mod_exp(ret, f, rsa, ctx)) goto err;
static int RSA_eay_mod_exp(BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX *ctx)
{
..
..
/* compute I mod q */
if (!(rsa->flags & RSA_FLAG_NO_CONSTTIME))
{
c = &local_c;
BN_with_flags(c, I, BN_FLG_CONSTTIME);
if (!BN_mod(r1,c,rsa->q,ctx)) goto err;
}
else
{
if (!BN_mod(r1,I,rsa->q,ctx)) goto err;
}
..
..
/* compute I mod p */
if (!(rsa->flags & RSA_FLAG_NO_CONSTTIME))
{
c = &local_c;
BN_with_flags(c, I, BN_FLG_CONSTTIME);
if (!BN_mod(r1,c,rsa->p,ctx)) goto err;
}
else
{
if (!BN_mod(r1,I,rsa->p,ctx)) goto err;
}
#define BN_mod(rem,m,d,ctx) BN_div(NULL,(rem),(m),(d),(ctx))
int BN_div(BIGNUM *dv, BIGNUM *rm, const BIGNUM *num, const BIGNUM *divisor,
BN_CTX *ctx)
..
sdiv=BN_CTX_get(ctx);
..
if (!(BN_lshift(sdiv,divisor,norm_shift))) goto err;
BN_lshift() shifts a left by n bits and places the result in r (r=a*2^n).
EDIT: obviously if you leak p and q you can trivially reconstruct the private key :) but it is possible other intermediate values might be leaked as well that allow for key reconstruction.
though, considering left shifted p and q look a lot like normal p and q i'm surprised no-one has found this by just searching through the leaked data. so maybe this is not leaked or it requires a read at the correct time because these buffers might be trashed by another computation.