Securely signing build artifacts (was: Signing a file given its hash only)
Jacob Bachmeyer
jcb62281 at gmail.com
Mon Jun 2 05:56:12 CEST 2025
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20250601/9b0bb42d/attachment.html>
More information about the Gnupg-users
mailing list