security model (was: [PATCH gnupg v12] Disable CPU speculation-related misfeatures)

[Jacob Bachmeyer]

On 7/11/25 04:34, Robert J. Hansen via Gnupg-devel wrote:
>> 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.

Thank you.

> [...]
>
> 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.

Either you plan much farther ahead than the common cybercrook or we are 
talking about targeted attacks instead of the much common "spam" 
attacks.  (That said, GnuPG is *supposed* to stand up against targeted 
attacks.)

> Unprivileged Mallory is either (a) a brief period of time before
> becoming Privileged Mallory, or (b) a popular myth among security
> researchers.
>
> [...]

The catch is that the "juicy" stuff is typically *in* the user's account 
on a single-user box... and therefore accessible without elevation if 
Mallory is hitting the client.

Why risk the exposure (and correction) of a privilege escalation exploit 
when everything Mallory wants is right there without it? (I note that 
*I* might also be overestimating Mallory's intelligence or 
underestimating arrogance here.)

Brief access as the "unprivileged user" is all Mallory needs for a 
smash-and-grab.  Persistence increases the risk of detection and 
elevation requires an additional exploit that might be captured and 
analyzed.

In my model, Mallory's ideal goal is make off with your data and/or 
private keys and/or an unauthorized signature without leaving a trace 
aside from possible intentional tampering.

This is one of the problems I have with tokens instead of 
passwords---the former basically must be stored on the machine somewhere 
accessible to the user's account, while the latter can be memorized or 
stored offline (or [*sigh*] kept in "passwords.txt" on the user's desktop).

> [...] 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.

In that environment, a smartcard is not sufficient; you need an isolated 
box.  If Mallory can gain persistence as the user, then Mallory need 
only wait until the user unlocks the smartcard and can then abuse the 
card right under the user's nose.


-- Jacob