But many side channels, such as those arising from speculative execution, are observable by an unpriviliged third party user of a VM host (and not just cloud, on-prem is no different in principle).
Sorry to jump in here, but for 25 years I've told people "only run GnuPG on hardware you control." That also applies if your underlying hardware is a virtualized environment.
I side with Jacob here. Once Mallory has access to your hardware, it's
game over.
I don't mean to sound rude, but I also think your "observable by
an unprivileged user" remark is not serious.
If I'm Mallory my order of operations is, roughly:
* Gain access
* Persist the access
* Elevate the access
* Prepare for termination of access
I don't hit the target unless I know how to do all four and have the
process automated.
Unprivileged Mallory is either (a) a brief period of time before
becoming Privileged Mallory, or (b) a popular myth among security
researchers.
The usual response is, "but if the attacker knows we're not defending
against unprivileged attackers with access to the local hardware, it
just encourages them to make unprivileged attacks!"
Which is kind of true, if you're in an environment where OpenPGP traffic
is the highest-value target and would be a single-trove haul to justify
the incursion. If that describes your risk landscape I strongly advise
against doing any key operations on the box: use a smartcard instead.
Otherwise, the high-end crews have shopping lists of things they want to
exfil, many requiring elevation.
Mallory's going to elevate. Count on it.
Only run GnuPG on hardware, real or virtual, that you control.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-devel mailing list Gnupg-devel@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-devel
