Signing a file given its hash only

[Jakob Bohm]

On 5/21/2025 17:09:21, Jay Acuna wrote:
> On Wed, May 21, 2025 at 9:00 AM Jakob Bohm via Gnupg-users
> <gnupg-users at gnupg.org> wrote:
> 
>> Please stop suggesting less secure solutions to those who have already set
>> up high security compartmentalized systems.  It makes you look malicious .
> 
> These are not less secure solutions.  It is not a fact that a
> "compartmentalized"
> system is secure.
> 
> There are well-established standards for what counts as a secure cryptographic
> hardware module.  In the scenario described this server "H" does not
> qualify as a
> secure module. The recommendation is to use qualified secure
> cryptographic modules with any necessary physical security controls and
> offline signing workstations.
> 

Compartmentalization isn't limited to what a HSM can do.  It also
provides isolation at more human levels, such as who can log in to the
high security machine and who can provide software updates that are
likely to be trusted for install on that machine.  For example, in a
software build scenario as described elsewhere in the thread, the medium
machine has to install, update and run a variety of build tools and
build libraries, which are not needed by the high security signing
machine.  That is an order of magnitude more software on the medium
machine.

On the physical level, an H machine will ideally contain an actual HSM
for the private key operations and a stripped down hardened hardware and
OS configuration, all locked in a physically secure cage/room under
video surveillance, where only the signing officer can enter and run the
few commands needed.

> The existence of H does not improve the signing process, since it can't actually
> review what it is signing.  Since H behaves as if M is an implicitly
> trusted agent, and
> automatically signs what M presents to be signed without being able to
> verify anything: H and M do not act with any independent or separable
> agency during
> the signing process.
> 

H will usually have authentication and human controls limiting what can
be done.  In particular, none of the build scripts and tools running on
M can authorize private key operations with arbitrary data, as it will
only process data of the authorized form (which might be a well-formed
list of hashes with expected file name patterns and counts or might be a 
well-formed half-signed PGP request for objects of a particular range of
file sizes).

Another main security limit would be that H only signs a fixed number of
files each time the relevant boss issues a "work order" to roll a
release.  Similarly a Linux distribution would only sign a new master
index of security updates at the planned time on days when actual
security updates were added .

> It seems that H's existence is useless from a security
> standpoint and only weakens security.
> 
> H becomes an overall liability in terms of the security of the
> signing:  simply due
> to the added complexity and the creation of
> additional unnecessary process, communications, and system which is subject to
> possible compromise,  and since M wants to present a hash to H for an
> unsigned messages: there is no means for H to confirm the hash has not been
> altered from the hash or signing context that M believes it is sending to H.
>

Only under your deeply flawed assumptions.

> 
>> Obviously, such calculations are apparently not in the currently
>> shipping GPG code, but could be written by companies that need it
> 
> Companies can do as they like,  but breaking up the signing internally
> like this is not part of the PGP standard and seems to amount to
> rolling your own crypto;
> which introduces probable vulnerabilities.
 >

As someone who has truly rolled my own crypto for other tasks, there is
a great difference in the difficulty and pitfalls of defining a new
signature format, and those of just taking an existing well-defined
process and splitting it between machines .

> 
> You'd actually be better off just having both H and M sign the message,
> and require the verification process to ensure that both H and M
> signatures are good.
> 

Having M sign the preliminary data bundle with a medium security key is
a good step in the process of securely transferring that bundle to H.

The point of partial signing is to reduce the size of the data bundle
transported across the security boundary by 3 or more orders of
magnitude.  The smaller data size provides fewer places for malicious
data to hide, especially the kinds that might perform arbitrary actions
such as copying private keys or private key passwords.  The smaller 
bundle will also be easier to subject to automated (but somewhat company 
specific) well-formed-nes tests to ensure that M (or malicious code on 
M) cannot request signing of arbitrary byte sequences as often needed by
known-plaintext attacks on the cryptographic actions done on H.

For example, the H machine can run a PGP-specific test that the partial 
signature blob is correct and contains the same public key specific data 
that the local PGP configuration would insert.

But the H machine can also run a company-specific check that the partial
signature blob for the purported gpg release tarball (just an example)
specifies a byte count in the range expected of gpg release tarballs,
and request authorized human intervention if the byte count changes 
beyond that range.

A hypothetical standard tool for signing partial PGP signature blobs
can perform the first check by default and take options specifying the
second check (--file-min-size, --file-max-size etc.), letting companies 
that do this (such as, potentially, g10-code and various Linux 
distributions) just provide the authorized file names and size ranges in
a much simpler script.


> 
> And  why wouldn't they just write wrapper scripts for GPG or PGP signing and
> verification at that point?   To create signed text file for the hash
> for signing,
> 
>    #!/bin/sh
>    # ./sign.sh <file list>
>    for i in $@ ; do
>       sha256sum -- $i | gpg --clearsign username  >>  $i.signedhash
>    done
> 
>    #!/bin/sh
>    # ./verify.sh <file list>
>    fail() {
>         echo $@
>         exit 1
>     }
>    for i in $@ ; do
>       gpg -d -- ${i}.signedhash  | sha256sum -c  || fail "Failed to verify"
>    done
> 

Because that (if reimplemented by someone more competent) is just the 
"list of hashes" alternative method, but without the security that the 
machine handling the files in the file list cannot change when, how and 
what is being signed.

Besides the splitting between machines, this also lacks a script that
parses a hash list and checks that it is well-formed and contains only
specific file names in a specific order.  File sizes cannot be checked
because they are not in the standard hash list format .


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded