aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/design.md44
1 files changed, 22 insertions, 22 deletions
diff --git a/doc/design.md b/doc/design.md
index da1bcf2..e2c0f8d 100644
--- a/doc/design.md
+++ b/doc/design.md
@@ -147,41 +147,41 @@ to extend and/or modify. The last part contains documentation TODOs.
We consider a powerful attacker that gained control of a claimant's signing and
release infrastructure. This covers a weaker form of attacker that is able to
sign data and distribute it to a subset of isolated users. For example, this is
-essentially what the FBI requested from Apple in the San Bernardino case [\[FBI-Apple\]](https://www.eff.org/cases/apple-challenges-fbi-all-writs-act-order).
+essentially what the FBI requested from Apple in the San Bernardino case
+ [\[FBI-Apple\]](https://www.eff.org/cases/apple-challenges-fbi-all-writs-act-order).
The fact that signing keys and related infrastructure components get
-compromised should not be controversial these days [\[SolarWinds\]](https://www.zdnet.com/article/third-malware-strain-discovered-in-solarwinds-supply-chain-attack/).
+compromised should not be controversial these days
+ [\[SolarWinds\]](https://www.zdnet.com/article/third-malware-strain-discovered-in-solarwinds-supply-chain-attack/).
The attacker can also gain control of the transparent log's signing key and
infrastructure. This covers a weaker form of attacker that is able to sign log
data and distribute it to a subset of isolated users. For example, this could
have been the case when a remote code execution was found for a Certificate
-Transparency Log [\[DigiCert\]](https://groups.google.com/a/chromium.org/g/ct-policy/c/aKNbZuJzwfM).
-
-Any attacker that is able to position itself to control these components will
-likely be _risk-averse_. This is at minimum due to two factors. First,
-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.
-
-Following from our introductory goal we want to facilitate _disocvery_ of sigsum
-statements. Such discovery makes it possible to detect attacks on a claimant's
-signing and release infrastructure. For example, a claimant can detect an
-unwanted sigsum by inspecting the log. It could be the result of a compromised
+Transparency Log
+ [\[DigiCert\]](https://groups.google.com/a/chromium.org/g/ct-policy/c/aKNbZuJzwfM).
+
+Following from our introductory goal we want to facilitate _discovery_ of signed
+checksums. This makes it possible to detect attacks on a claimant's signing and
+release infrastructure. For example, a claimant can detect an unwanted checksum
+signature by inspecting the log. It could be the result of a compromised
signing key. The opposite direction is also possible. Anyone may detect that a
repository is not serving data and/or proofs of public logging.
+For security we need a collision resistant hash function and an unforgeable
+signature scheme. We also assume that at most a threshold of independent
+parties stop following protocol to protect against a malicious log that attempts
+[split-view](https://datatracker.ietf.org/doc/html/draft-ietf-trans-gossip-05)
+or
+[slow-down](https://git.sigsum.org/sigsum/tree/archive/2021-08-24-checkpoint-timestamp)
+attacks. This gives us a _trust-but-verify_ relationship towards the log.
+
It is a non-goal to disclose the data that a cryptographic checksum represents
-_in the log_. It is also a non-goal to allow richer metadata that is
-use-case specific. The type of detection that a sigsum log supports is
-therefore more _coarse-grained_ when compared to Certificate Transparency. A
+_in the log_. It is also a non-goal to allow richer metadata that is use-case
+specific. The type of detection that a sigsum log supports _in isolation_ is
+therefore more coarse-grained when compared to Certificate Transparency. A
significant benefit is that the resulting design becomes simpler, general, and
less costly to bootstrap into a reliable log ecosystem.
-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 to protect against split-views
-[\[Gossip\]]().
-
## 3 - Design
We consider a _claimant_ that claims to distribute the _right_ opaque data with
cryptographic hash X. A claimant may add additional falsifiable claims.