On 6/1/25 09:54, Richard Stoughton via Gnupg-users wrote:
[...]
So we'll try another approach to preserve the security level of M on L:
H injects a secret nonce into a build run on M. M uses the nonce to
create a MAC for each artifact it creates. M pushes the MACs along
with the artifacts to L.
To sign an artifact H fetches the artifact and the corresponding MAC
to its local file system. Then H verifies the MAC using the secret
nonce it has previously injected into the build on M. If the MAC is
valid then H signs the artifact using gpg. Then H pushes the signature
to L.
A simple variation: the trusted build operator (someone approves the
use of the keys stored on H...) generates an emphemeral keypair on a
secure workstation (perhaps H itself?); the private key is injected into
M and the public key is given to H as part of the process to approve
signing build artifacts. (Presumably, the ephemeral public key ends up
in an audit log somewhere while the ephemeral private key is destroyed
when M shuts down.)
To sign an artifact, H fetches the artifact and the corresponding build
signature to its local filesystem. Then H verifies M's signature using
the ephemeral public key created for that specific build. If the
signature is valid, H signs the artifact using its secure keys and
pushes the signature to L, where it is again verified.
This can be done without adding additional software to H aside from
scripts to drive the process: gpgv can be used to verify the build
signatures. Using symmetric MACs would require additional software, but
H already needs GPG for its basic job.
The only major problem with this I see is fundamental to this
architecture: a compromised M can generate backdoored artifacts and sign
them as if they were legitimate, with H and L none the wiser. Since you
have mentioned that M is an ephemeral cloud instance, I presume that a
compromise of your hosting provider is outside of your threat model.
-- Jacob
_______________________________________________
Gnupg-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-users
