Security considerations

17. Security considerations

The substrate defines mechanisms, not meaning, so its security properties are narrow and precise. Each layer has its own security section — SSP/1’s is §42, SOP/1’s is §23 — and neither restates what is here.

Every property below holds for both layers because both are built from the same five mechanisms. That is the point of the part: a property argued once cannot be weaker in one layer than in the other.

17.1. What canonicity buys

Canonical low-S signatures and public-key encoding canonicity are mandatory because record identity is derived from signed bytes (one hash), not because non-canonical encodings are untidy.

A malleated copy of a genuine record — same key, same payload, valid signature, different bytes — hashes to a different identifier. It therefore survives deduplication and is applied twice. Where the identifier is an idempotency key, as event_id is, that is a correctness failure reachable by an attacker who forges nothing.

Two consequences follow, and both are load-bearing:

• A verifier MUST reject a non-canonical encoding rather than normalise it. Normalising would make two distinct received byte strings agree on one identifier, which is the same defect approached from the other side: a record the sender did not send would acquire a valid identity.
• A key presented in any encoding other than the pinned one is rejected rather than converted. Conversion would let one key yield two site_ids, and a node’s identifier is the thing every policy decision is keyed on.

What canonicity does not buy. It does not authenticate the signer, bound replay across contexts, or make a signature reproducible. It makes one record have one identity, and nothing more.

17.2. There is no suite agility, and that is the security property

Exactly one signature suite is admissible. An implementation that meets an unrecognised alg fails closed.

Algorithm agility is usually argued as resilience: if a suite falls, negotiate another. In a specification with one suite and no negotiation there is nothing to strip, nothing to downgrade, and no cross-suite substitution to check for. A second mandatory-to-implement suite would add a downgrade surface immediately in exchange for resilience that is only realised if the first suite falls.

The cost is real and is accepted: replacing the suite is a revision of the specification, not a configuration change, and every deployed verifier must be updated before any signer may move. That is a migration problem rather than a protocol problem, and it is the cheaper of the two.

What this does not buy. It does not make ES256 sound. If P-256 or SHA-256 falls, the specification is broken and must be revised; nothing in the substrate degrades gracefully instead.

17.3. Deterministic nonces, and why signatures are not reproducible

RFC 6979 deterministic nonces are normative for software signers, because an ECDSA nonce reused across two signatures discloses the private key, and a nonce derived from a weak random source is the most common way that happens in practice.

A secure element cannot be held to the rule: it generates the nonce under its own certification and exposes no interface to supply one. Requiring reproducible signing would therefore require the root key to live in software, which inverts the gradient the specification is trying to establish.

The consequence is stated here so no part has to rediscover it: two signatures over identical payloads by the same key may differ in bytes, and are both valid. A verifier MUST NOT treat signature bytes as a payload identifier, and any construction needing a stable identifier hashes the payload rather than the signature.

17.4. Chained records detect a fork; they do not prevent one

The chained-record schema gives an authority’s statements a monotonic generation and a predecessor hash. Two records at the same generation with different content, both validly signed by the same authority, are a portable proof that the authority equivocated — checkable by any third party, with no trusted log.

Detection is not prevention. Nothing in the substrate stops an authority from producing the second record; the schema only ensures that doing so leaves evidence anyone can verify. A deployment that needs prevention needs a mechanism the substrate does not supply.

Two further limits:

• Detection requires a verifier that has seen both records. An authority that partitions its audience and shows each side one branch is not detected by either until the branches meet.
• A cold verifier replays the chain from genesis, because the schema carries no checkpoint. That is a cost, not a hole, but it is a cost that grows without bound.

17.5. What padding does not hide

Padmé bounds the information a ciphertext’s length leaks. It does not hide transfer timing, peer relationships, object reuse, access frequency, or the number of objects. An observer who can watch traffic learns most of what it wants from those, and padding is not a defence against it.

Padding is also not confidentiality: it is applied to material that is already encrypted, and it changes what an observer infers rather than what an observer can read.

17.6. The failure mode this part exists to prevent

A layer that restates a substrate rule creates two copies of it, and a rule with two copies can be amended in one. The specification would then admit two canonical encodings, or two signature profiles, and every property argued above would hold in one layer and not the other — silently, because both layers would still read as correct on their own.

That is why the substrate states that a layer page references a mechanism and does not restate it, and why the rule is worth enforcing even where restating would be convenient.