From 16041237842bc729782acb828abd795b6f5935d4 Mon Sep 17 00:00:00 2001 From: Rasmus Dahlberg Date: Sat, 2 Oct 2021 00:04:16 +0200 Subject: updated threat model - Minor rephrasing and white-space changes to make raw text nicer. - Avoid using sigsum as "signed checksum" in text. Not helpful. - Removed paragraph about risk-averse attacker. It is not needed to make our points right now. In a future revision, we should re-add this and explain why it is interesting. It would also be a good idea to then cite the two papers that z4lem mentioned a while back, see archive. - Clarified that we need a threshold of witnesses that follow the cosigning protocol for security. It is a start on addressing rohonk's comment about which parties may (not) follow protocol and why. - Emphasized that sigsum logging is only more course-grained than CT if the data is actually lost. Hence, more course-grained _in isolation_. - Added links to slow-down and split-view attacks. --- doc/design.md | 44 ++++++++++++++++++++++---------------------- 1 file changed, 22 insertions(+), 22 deletions(-) (limited to 'doc/design.md') 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. -- cgit v1.2.3