Tkey for signing keys. Motivation: Sigsum needs long-lived signing keys,
with backup in case the device holding the signing key (and maybe the
rest of the site as well) is destroyed. Same may apply to other long
lived keys, e.g., close to the top of a cert hierarchy/delegation chain.
1. Signer app: Recieve an encrypted signing key, encrypted to the key's
unique key using some public key crypto algorithm. Decrypts the
signing key, and acts as signing oracle. Also needs a way to
advertise its own pubkey, as well as the pubkey corresponding to the
signing key.
2. Keygen app: Takes a list of public keys. Generates a new signing key,
and encrypts it to each of the public keys.
3. Export app: Takes public keys and an encrypted signing key. Decrypts
using its own unique key, and reencrypts to each of the public keys.
Also needs a way to advertise its own pubkey. (Similar role as a
yubihsm with key export enabled, but with "keywrap" done using public
keys rather than a symmetric key).
Usage scenario: Get at least three tkeys, two intended as backups, the
other(s) as signing oracles. Extract the public keys for each key and
the respective intended app (signer or exporter). Load the key-gen app
on any of the keys, and give it all those pubkeys.
Store the resulting encrypted blob reliably. Lock up the two
backup/export keys. Attach a signing key to the machine intended to do
signing, and provide the encrypted blob and the signing app on that
machine.
When any one of the keys breaks, take one of the export keys out of the
safe, and use it to reencrypt the signing key to a replacement key of
the appropriate type.
Extension 1 (technically quite easy, I think): Add a symmetric
key/passphrase, required for operation of the keys, either a single one,
or separate for each key. Would be particularly relevant for access to
the export keys, and it would also make sense to apply k-of-n secret
sharing of the secret needed to operate the export keys.
Extension 2 (hand waving): Have the signer app require a proof of
logging of the act of exporting the signing key to that particular key.
/Niels
Hi, I wrote up some notes and ideas on how to do backups of private
keys, which is needed for sigsum primary-secondary failover.
I would hope the way I propose (if it actually works) could be
implemented on a Tillitis key. I have no idea if something like that is
supported by yubico hsm, but I think Linus is investigating.
See
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/archive/20…,
all comments and feedback appreciated.
/Niels
We are happy to announce the first release of the sigsum log server
software and Ansible role collection! This means that the project is
ready for wider deployment, and that we are committed to provide
well-documented upgrade paths when releasing future versions.
For background, recall that Sigsum makes signed checksums transparent.
This makes it possible to detect malicious and unintended key-usage.
The ansible role collection aims to make it easy for organizations to
host sigsum logs on their own infrastructure, including setup of mariadb
and data replication between a log instance's primary and secondary
nodes. The v1.0.0 Ansible release makes use of the following versions:
- log-go v0.9.0
- sigsum-go v0.1.23
- Trillian v1.5.1
For more information relating to the log server architecture and how to
get started with our ansible collection, see:
https://git.glasklar.is/sigsum/admin/ansiblehttps://git.glasklar.is/sigsum/core/log-go/-/blob/main/doc/readme.md
We recommend to also take a look at the Sigsum roadmap:
https://git.glasklar.is/sigsum/project/documentation/-/blob/main/archive/20…https://git.glasklar.is/groups/sigsum/-/milestones
Of note is that the sigsum protocol is still at version 0. While we are
not expecting any major changes at this point, an upcoming release will
extend the log software with a witness cosigning protocol that is still
in-progress. Change logs and the information necessary to perform
upgrades will be provided from here on. However, it is not recommended
for end-users to fail-close on sigsum logging before protocol version 1.
Please report issues and request support on our GitLab issue tracker.
We are also available on irc.oftc.net and Matrix in room #sigsum.
More informasion can also be found on our webpage:
https://www.sigsum.org/
Cheers,
The Sigsum team
Hi,
this is a question that I hope is convered in the literature on
transparency logs, but what meaning do we assign to a single, isolated,
cosignature?
If we have a *sequence* of cosigned tree heads (signed by a particular
witness, ordered by increasing tree size), then each cosignature says that
all tree leafs in previous cosigned trees are present in later
trees. But a sigsum client only sees a single cosigned tree head, not
the sequence. In particular, consider the case of the first cosignature
of a particular witness, with no history.
So what exactly does that signature mean?
I suspect there are maybe some underlying assumptions or policys that
should be spelled out somewhere.
Is this an reasonably accurate description? When I see a leaf node
accompanied by a cosigned treehead and an inclusion proof leading up to
that head, then I expect that the witness will raise some alarm if,
sometime in the future, the log attempts to publish a tree head where
the leaf no longer is present?
In this case, a single cosignature doesn't make any claim about the
state of the log, it just states that the witness has observed this
state, and hence that the witness has the information needed to detect
future inconsistencies. More concisely: An isolated cosignature
(without history) does not make a claim about the state of the log, it
makes a claim about the state of the witness.
Does that make sense?
Regards,
/Niels
Rasmus Dahlberg <rasmus.dahlberg(a)glasklarteknik.se> writes:
>> I see one problem with this, though. The monitor can't simply use the
>> ssh-keygen command to verify the signature, since that command expects
>> to get the *message* as input, not the hash thereof. Which kind-of
>> defeats the idea of piggybacking on ssh tools.
>
> I disagree. The value of piggy-backing on SSH tooling is for the signer
> who can access their private key with good solutions that already exist.
I don't have a very strong opinion, maybe it's "only" a matter of
documentation. If we say "sigsum uses the ssh signature format", I would
expect that to mean that we use it as a black box with inputs and output
according to the spec, but that's not quite what we do.
We could say that we have
checksum = H(message)
and that the essence of the signature is to sign checksum, so that
signature can be verified given only the public key and checksum (i.e.,
without knowing message). And that we do signatures in a way that
produces an identical signature as if feeding message as the input of
ssh-keygen -Y sign --hashalg=sha256, or M = message in its spec.
>> message=SHA3(data) ; application layer
>
> Note that message must be exactly 32 bytes in Sigsum. So, you wouldn't
> be able to use SHA3 here
Side note: SHA3_256 is part of the SHA3 standard.
> I see your point if it is a desired property to verify leaf signatures
> in isolation with ssh-keygen. Would you say that the complexity is
> decreased, about the same, or increased if this change was proposed?
I think conceptual complexity would be decreased slightly, by which I
mean roughly that it will be slightly easier to document and explain.
For implementation complexity, not much difference (assuming that the
only value we see in actually using the ssh-keygen tool for handling
signatures is for the private key operations).
Regards,
/Niels
Let me start with a description of my current understanding of the
checksum field, present in the tree_leaf struct in the spec.
The submitter submits a message M to the log (M typically a hash of some
data not disclosed to the log), together with a public key and
signature.
The log first verifies the signature, and then adds a leaf to the merkle
tree. The signatures are done using ssh format, configured to use
sha256. This implies that sign and verify operations on which includes
computing SHA256(M), and we call this "checksum" and include it in the
tree_leaf struct together with the signature.
My first question: Does it matter in any way that the checksum happens
to be a value used internally in the ssh signature formatting?
If we instead publish a signature of M created using the SHA512 hash
internally, as is the ssh-keygen -Y sign default, and publish this
signature together with checksum = SHA256(M), wouldn't that work just as
well?
Next question: Do we really need to publish the checksum at all? It
serves as a unique and random-looking identifier for the message M, but
who's using this id? We have the following roles:
1. Submitter. Will collect signatures on the submitted leaf. Obviously
knows everything needed to query for the leaf hash, and will crete
the "sigsum proof package" package to distribute to sigsum verifiers.
2. Sigsum verifier (the party that gets the message M and wants to
verify that it is properly logged). The verifier needs to get (by
other means than querying the log by itself) all of
M itself
signature of M
inclusion proof for the leaf including this signature
witness signatures
all related public keys
As far as I see, signer will clearly recompute the checksum, in the
internals of the signature verification. It could also explicitly
compare the checksum it to the value stored in the leaf, but what
benefit does that give, if the signature is already verified? On the
other hand, it seems essential to verify that the signature and the
public key hash in the leaf are as expected.
I think this is the core of the question: Is there any reason for the
verifier to validate the checksum stored in the leaf, in addition
to verifying the signature? If not, what use is that field?
3. Witness. The witness doesn't have access to M, so to a witness the
checksum is just random string, there's no way to validate it. It
could possibly use it to verify the signature (not by using
ssh-keygen though, but by digging into internals if ssh signatures),
except that the witness is not expected to have access to the
submitter's public key.
4. Monitors. The purpose of a monitor is to query the log and alert
whenever an unexpected signature appears. My understanding of
monitoring is somewhat fuzzy, but I think the monitor is expected to
query for recent tree heads (relying on witness cosignatures to know
that what it gets is recent), download all (new) leaves in the tree,
and filter on one or more public key hashes of interest. For the
leaves found, it will then alert key owner on "unexpected" checksums.
However, couldn't one do without the checksums and just as well look
at unexpected signatures?
The checksum uniquely (except for hash collisions) identifies a single
message M. But the signature itself also uniquely identifies a single
message M (it seems highly unlikely to have collisions, even if we allow
the public key to vary, and in case we insist on having the same public
key, any collision represents a break of the security of the signature
algorithm).
The difference is that the checksum can be (re)computed from M only,
while computing the signature also requires the private key. That's
sonds like a big dfference, but the only roles above that are expected
to know M, are the submitter and the verifier. The submitter by
definition knows the private key. And the verifier should be provided
with the signature by other means, and just verify it.
Regards,
/Niels
Hi,
tl;dr If you are sorting email messages from this server based on email
headers, you might need to update your filters.
This list has been moved from one server to another server.
Previous List-Id header was sigsum-general.lists.sigsum.org
Current List-Id header carries more cruft but the regular expression
sigsum-general.lists.sigsum.org should still match.
Previous Subject header was pre-pended with [sigsum-general].
Current Subject header might have changes in casing.
Previous server did not DKIM-sign outgoing messages which was
problematic since the list manager rewrites parts of the message (like
Subject), rendering potential present signatures invalid.
Current server does DKIM-sign outgoing messages.
Previous list manager did not ever rewrite the From: header, making SPF
checks at the recipient's server fail.
Current server rewrites From: when needed.
Previous list manager had no web interface for managing subscriptions.
Current list manager does.
Previous list manager accepted email messages to
sigsum-general+subscribe@, sigsum-general+unsubscribe@ and
sigsum-general+help@.
Current list manager accepts messages to other addresses, see the List-*
headers of any email received on the list.
Enjoy,
Linus
Hi,
This list has now been set up. Its use is to discuss all aspects of
Sigsum.
Please note that email messages sent to this list are being archived for
anyone on the internet to read.
