On 5/21/2025 17:09:21, Jay Acuna wrote:
On Wed, May 21, 2025 at 9:00 AM Jakob Bohm via Gnupg-users
<[email protected]> 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
_______________________________________________
Gnupg-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-users
