[spec] Add threat model documentation

docs/src/SUMMARY.md

@@ -10,6 +10,7 @@
 # Specification
 
 * [Introduction](./specification/README.md)
+* [Threat Model](./specification/threat_model.md)
 * [Firmware Resiliency](./specification/firmware_resiliency.md)
 * [Middleware](./specification/middleware/README.md)
   * [MCTP](./specification/middleware/mctp.md)

docs/src/specification/README.md

@@ -86,9 +86,6 @@ management protocols.
 - **NIST SP 800-90A**: Recommendation for Random Number Generation
 - **NIST SP 800-108**: Recommendation for Key Derivation Functions
 
-## Threat Model
-
-
 ## High Level Architecture
 
 The OpenPRoT architecture is designed to be a flexible and extensible platform

docs/src/specification/threat_model.md

@@ -0,0 +1,58 @@
+# Threat Model
+
+## Assets
+
+-   Integrity and authenticity of OpenPRoT firmware
+-   Integrity and authorization of cryptographic operations
+-   Integrity of anti-rollback counters
+-   Integrity and confidentiality of symmetric keys managed by OpenPRoT
+-   Integrity and confidentiality of private asymmetric keys
+-   Integrity of boot measurements
+-   Integrity and authenticity of firmware update payloads
+-   Integrity and authenticity of OpenPRoT policies
+
+## Attacker Profile
+
+The attack profile definition is based on the JIL Application of Attack
+Potential to Smartcards and Similar Devices Specification version 3.2.1.
+
+-   **Type of access**: physical, remote
+-   **Attacker Proficiency Levels**: expert, proficient, laymen
+-   **Knowledge of the TOE**: public (open source), critical for signing keys
+-   **Equipment**: none, standard, specialized, bespoke
+
+### Attacks within Scope
+
+See the JIL specification for examples of attacks.
+
+-   Physical attacks
+-   Perturbation attacks
+-   Side-channel attacks
+-   Exploitation of test features
+-   Attacks on RNG
+-   Software attacks
+-   Application isolation
+
+## Threat Modeling
+
+To provide a transparent view of the security posture for a given OpenPRoT +
+hardware implementation, integrators are required to perform a threat modeling
+analysis. This analysis must evaluate the specific implementation against the
+assets and attacker profile defined in this document.
+
+The results of this analysis must be documented in table format, with the
+following columns:
+
+-   **Threat ID**: Unique identifier which can be referenced in documentation and
+    security audits
+-   **Threat Description**: Definition of the attack profile and potential attack.
+-   **Target Assets**: List of impacted assets
+-   **Mitigation(s)**: List of countermeasures implemented in hardware and/or
+    software to mitigate the potential attack
+-   **Verification**: Results of verification plan used to gain confidence in the
+    mitigation strategy.
+
+Integrators should use the JIL specification as a guideline to identify relevant
+attacks and must detail the specific mitigation strategies implemented in their
+design. The table must be populated for the target hardware implementation to
+allow for a comprehensive security review.