aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-06-25 16:13:36 +0200
committerRasmus Dahlberg <rasmus.dahlberg@kau.se>2021-06-25 16:13:36 +0200
commita1f628c445a6ac4145ea6d191e6bcd72a96d894c (patch)
tree569330d409c45cf998f311624ae4e4124637c63e /doc
parent0fb2a1055475876702a003b2fa4397595efa40de (diff)
fixed s/st/sigsum in design.md
Diffstat (limited to 'doc')
-rw-r--r--doc/design.md39
1 files changed, 22 insertions, 17 deletions
diff --git a/doc/design.md b/doc/design.md
index 2e01a34..10b598f 100644
--- a/doc/design.md
+++ b/doc/design.md
@@ -1,13 +1,14 @@
-# System Transparency Logging: Design v0
-We propose System Transparency logging. It is similar to Certificate
-Transparency, except that cryptographically signed checksums are logged as
-opposed to X.509 certificates. Publicly logging signed checksums allow anyone
-to discover which keys produced what signatures. As such, malicious and
-unintended key-usage can be _detected_. We present our design and conclude by
-providing two use-cases: binary transparency and reproducible builds.
+# Sigsum Logging Design v0
+We propose sigsum logging. It is similar to Certificate Transparency, except
+that cryptographically **sig**ned check**sum**s are logged instead of X.509
+certificates. Publicly logging _sigsums_ allow anyone to discover which
+keys produced what checksum signatures. For example, malicious and unintended
+key-usage can be _detected_. We present our design and discuss a few use-case
+scenarios like binary transparency and reproducible builds.
**Target audience.**
-You are most likely interested in transparency logs or supply-chain security.
+You are likely interested in transparent logs, public-key infrastructures,
+or supply-chain security.
**Preliminaries.**
You have basic understanding of cryptographic primitives like digital
@@ -24,8 +25,7 @@ Transparency logs make it possible to detect unwanted events. For example,
are there any (mis-)issued TLS certificates [\[CT\]](https://tools.ietf.org/html/rfc6962),
did you get a different Go module than everyone else [\[ChecksumDB\]](https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md),
or is someone running unexpected commands on your server [\[AuditLog\]](https://transparency.dev/application/reliably-log-all-actions-performed-on-your-servers/).
-A System Transparency log makes signed checksums transparent. The overall goal
-is to facilitate detection of unwanted key-usage.
+A sigsum log brings transparency to **sig**ned check**sum**s.
## Threat model and (non-)goals
We consider a powerful attacker that gained control of a target's signing and
@@ -47,17 +47,22 @@ detection would result in a significant loss of capability that is by no means
trivial to come by. Second, detection means that some part of the attacker's
malicious behavior will be disclosed publicly.
-Our goal is to facilitate _detection_ of compromised signing keys. We consider
-a signing key compromised if an end-user accepts an unwanted signature as valid.
-The solution that we propose is that signed checksums are transparency logged.
+Our goal is to facilitate _disocvery_ of signed checksums. Such discovery
+makes it possible to detect attacks on signing and release infrastructures. For
+example, the signer can detect an unwanted sigsum by inspecting the log.
+
+It is a non-goal to disclose the data that a cryptographic checksum represents
+_in the log_. A log cannot distinguish between a checksum that represents a tax
+declaration, an ISO image, or a Debian package. The type of detection that we
+support is therefore more _coarse-grained_ when compared to Certificate
+Transparency. A significant benefit is that the resulting design becomes
+simpler, generally useful, and less costly to bootstrap into a reliable
+operation.
+
For security we need a collision resistant hash function and an unforgeable
signature scheme. We also assume that at most a threshold of seemingly
independent parties are adversarial.
-It is a non-goal to disclose the data that a checksum represents. For example,
-the log cannot distinguish between a checksum that represents a tax declaration,
-an ISO image, or a Debian package. This means that the type of detection we
-support is more _coarse-grained_ when compared to Certificate Transparency.
## Design
We consider a data publisher that wants to digitally sign their data. The data