docs/quorum-key-management/src/threat-model.md

# Threat Model

QKM is designed according to a high-assurance threat model which ers on the
side of making exaggerated, rather than conservative assumptions in order to
build a resilient system.

The assumption is made that attackers who target QKM are extremely
sophisticated, well funded and patient attackers, and as such, the full arsenal
of attacks is on the table. This means that the attacker can purchase and
weaponize multiple 0day vulnerabilities, execute physical attacks or deploy
moles, target different supply chains of software, firmware and hardware used,
and generally attack the system using an array of known and unknown attacks.

One of the guiding principles in the design is the elimination of Single Points
of Failure (SPOFs), and relies on a number of different control mechanisms which
help reduce risk of any one individual being able to compromise the system,
whether it's maintainers of software used in the system, the firmware that's
used, or the individuals or locations that hold secret material which is the
backbone of the system.

To achieve this, the QKM focuses on reducing the risk by:

* Only using fully open source software and firmware to allow full verification
of their security properties

* Creating custom purpose specific tooling which eliminates dependencies in
order to reduce supply chain attacks, and adds desirable security properties

* Using a fully bootstrapped and deterministically built compiler for building
all software that's used

* Building all of the software and firmware deterministically

* Using computers which either have a hard switch for disabling networking or
which had radio networking cards (bluetooth, wifi etc.) removed

* Leveraging smart cards (personal HSMs) to protect cryptographic material

* Leveraging sharding in order to physically separate cryptographic material

* Leveraging tamper evident controls for components related to the system

* Leveraging frequency blocking methods such as TEMPEST (Telecommunications Electronics Materials Protected from Emanating Spurious Transmissions) and soundproofing

## General Threat Model Assumptions

Some additional assumptions are made to help contextualize the threat model:

* All screens are visible to an adversary

* All keyboards are logging to an adversary

* Any firmware/boot-loaders not verified on every boot are compromised

* Any host OS with network access is compromised

* Any guest OS used for any purpose other than prod access is compromised

* At least one member of the Production Team is always compromised

* At least one maintainer of third party used in the system is compromised

* Physical attacks are viable and likely

* Side-channel attacks are viable and likely


## Additional Threat Model Notes

### Smart Cards

The Operator Smart Card uses the default PIN because it is meant to be something
a user "has", rather than "knows". On the other hand, the Location Smart Card
is protected by a complex PIN, which can only be decrypted using the PGP keys
stored on the Operator Smart Card. This is done in order to protect the access
to the Location key by anyone except the Operator, but also to allow for adding
controls which require more than one individual to access a Location Smart Card.
In this way, there is an additional "quorum" which needs to be achieved to
access the Location key - more on this in the [Location](locations.md) section.

The Smart Cards are used as they are an HSM (Hardware Security Module) which
provides excellent protection for the cryptographic material stored on it, and
they are portable, which makes them suitable for creating systems where the
cards are in separate physical locations, and need to be brought together in
order to re-assemble secret material.