|
|
Subscribe / Log in / New account

Breaking Libgcrypt RSA via a side channel

Breaking Libgcrypt RSA via a side channel

Posted Jul 6, 2017 0:55 UTC (Thu) by vomlehn (guest, #45588)
Parent article: Breaking Libgcrypt RSA via a side channel

...the practical implications, at least for those not running on virtual machines alongside those of attackers, would seem to be fairly small.

But...there are a bazillion VMs out there in data centers sharing servers with any number of other VMs. This would seem to be a huge deal. I don't understand how information would leak from one VM to another in this case, though. Maybe a bit more info?


to post comments

Breaking Libgcrypt RSA via a side channel

Posted Jul 6, 2017 1:05 UTC (Thu) by sfeam (subscriber, #2841) [Link] (2 responses)

According to the article, the side channel attack monitors the hardware L3 cache. So I guess the only information that needs to leak from the VM is that a decryption is in progress.

Breaking Libgcrypt RSA via a side channel

Posted Jul 6, 2017 3:51 UTC (Thu) by wahern (subscriber, #37304) [Link] (1 responses)

IIRC there are published cross-VM key recovery attacks breaking both Intel SGX and AMD Secure Encrypted Virtualization. So, yeah, I would be wary of qualifying the issue by assuming that VMs provide any substantial, intrinsic mitigation. They don't even do that well when using technologies _intentionally_ and _carefully_ designed to make hosted VMs more secure and trustworthy.

Breaking Libgcrypt RSA via a side channel

Posted Jul 6, 2017 19:52 UTC (Thu) by cplaplante (subscriber, #107196) [Link]

Yup, here's a great one: https://arxiv.org/abs/1702.08719

Breaking Libgcrypt RSA via a side channel

Posted Jul 6, 2017 6:30 UTC (Thu) by matthias (subscriber, #94967) [Link]

The only attack vector across VMs that I can think of is in the case that some deduplication is effective. Then it could happen that the victims VM and the attackers VM are actually using the same copy of the code. In this case, observing which part of the code is in the cache should allow the attack.

Such an attack is described in the paper "Wait a Minute! A fast, Cross-VM Attack on AES" (DOI: 10.1007/978-3-319-11379-1_15) that is referenced from the RSA attack paper.

If the VMs use different copies of the encryption algorithm, the attacker should not get any information. At least the flush+reload attack can only observe whether some code that the attacker has access to is in the cache (by timing analysis).

If there is any other attack vector, I would really appreciate some clarification.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds