[openssl-users] request for TLBleed information / non-constant-time vulnerabilities
Michael.Wojcik at microfocus.com
Fri Jul 27 14:12:46 UTC 2018
> From: Michael R. Hines [mailto:mrhines at digitalocean.com]
> Sent: Friday, July 27, 2018 07:48
> On 07/27/2018 08:35 AM, Michael Wojcik wrote:
> > (I'm only commenting on TLBleed here because I'm not sure what you
> > mean by "non-constant-time attack". TLBleed isn't a timing side channel, so
> > what does constant time have to do with the question?)
> The paper is in fact based on a timing attack. Both Intel (and a nice
> blog from Redhat) confirm this; In fact that's the only way this
> particular vulnerability works. It leaks bits by observing the branch
> path of the code referencing each bit while processing a private key
> based on the time it takes to hit/miss a lookup in the TLB.
Oh, yes, of course you're correct. Sorry - that's what I get for responding early in the morning.
> If the
> cryptographic implementation is constant-time, then the bits are not
> discoverable and the attack is then unavailable.
Hmm. I suppose this is true, but it's not the usual sense of "constant time" when referring to cryptographic implementations - that is, it's not constant-time explicit operations (arithmetic, etc) but constant-time memory access, which requires the implementation to predict which pages it will touch, and to know something about the TLB algorithm used by the particular CPU it's running on.
I think that goes back to the TLBleed authors' mention of partitioning the target process virtual address space. For a library, that would be difficult, since it receives the key at an arbitrary address from the application.
> We're trying to decide if we can avoid disabling hyperthreading, as our
> measurements show that the performance losses (even with integer
> workloads) are significant.
> Might anyone be able to comment on this particular type of attack in
Certainly I'd need to do a lot more research before I'd feel comfortable speculating about possible mitigations within OpenSSL. I'll be interested to see if anyone else does.
Distinguished Engineer, Micro Focus
More information about the openssl-users