[doc] Add reference security/use_cases
This commit adds reference use cases for:
* Platform Integrity Module: Titan datacenter use case.
* Security Key: FIDO2 on USB 1.1 use case.
Closes issue lowrisc/opentitan#1119
Signed-off-by: Miguel Osorio <miguelosorio@google.com>
diff --git a/doc/security/use_cases/index.md b/doc/security/use_cases/index.md
new file mode 100644
index 0000000..8ae0086
--- /dev/null
+++ b/doc/security/use_cases/index.md
@@ -0,0 +1,185 @@
+---
+title: "OpenTitan Use Cases"
+---
+
+
+## Overview
+
+OpenTitan's mission is to raise the security bar industry wide by implementing a transparent, logically secure hardware root of trust with wide application.
+
+This document describes some of those use cases for OpenTitan.
+These range from data center integrations, to embedded security applications such as security keys and smart cards.
+References to relevant specifications and certification targets are noted where use cases are backed by industry standards.
+
+
+## Platform Integrity Module
+
+An OpenTitan IC used as a Platform Integrity Module interposes between a platform's boot flash and its main boot devices such as the Baseboard Management Controller (BMC), the Platform Controller Hub (PCH) and the CPU.
+
+<img src="use_cases_fig1.svg" alt="Fig1" style="width: 300px;"/>
+
+Figure 1: Platform Integrity Module
+
+
+The Platform Integrity Module use case implements the following security properties:
+
+* Measure integrity of first boot firmware stages before bringing the boot devices out of reset accessing boot flash via SPI or similar interface.
+* Monitor resets and heartbeat of downstream boot devices.
+ Monitoring tasks are handled by OpenTitan as Interrupt Service Routines (ISRs), and are not expected to operate under real time constraints.
+* Enforce runtime boot device access policies, and manage A/B firmware updates for software stored in boot flash.
+ The OpenTitan to boot device interface is implemented on SPI or a similar interface.
+* Provides root key store and attestation flows as part of the platform integrity secure boot implementation.
+
+### Minimum Crypto Algorithm Requirements
+
+The current target for all crypto is at least 128-bit security strength.
+This is subject to change based on the implementation timeline of any given instantiation of OpenTitan.
+It is expected that a future implementation may be required to target a minimum of 192-bit or 256-bit security strength.
+
+* TRNG: Entropy source for chip identity generation and KDF operations.
+ In both cases, raw entropy is processed by a pseudorandom function before any key generation is done.
+* Hash Algorithms:
+ * SHA256: An approved hash algorithm with approximately the same security strength as its strongest asymmetric algorithm.
+* Asymmetric Key Algorithms:
+ * RSA-3072-bit: Secure boot signature verification.
+ * ECDSA P-256: Signature and verification for identity and attestation keys.
+* Symmetric Key Algorithms:
+ * HMAC-SHA256: NIST FIPS 180-4 compliant. Used in integrity measurements for storage and in transit data as well as secure boot.
+ * AES: AES-CTR NIST 800-38A. Used to wrap keys and encrypt data stored in internal flash.
+
+
+### Provisioning Requirements
+
+Provisioning an OpenTitan device is performed in two steps:
+
+* Device Personalization: The device is initialized with a unique cryptographic identity endorsed by a Transit PKI which is only used to support initial Ownership Transfer.
+* Ownership Transfer: Ownership is assigned to a user that has the ability to run software on the device.
+ As Silicon Owner, the user can generate a cryptographic identity strongly associated to the hardware and the software version running on the device.
+
+OpenTitan used as a Platform Integrity Module has the following provisioning requirements:
+
+* Unique Global Identifier: Non-Cryptographic big integer value (up to 256b) used to facilitate tracking of the devices throughout their life cycle.
+ The identifier is stored in One Time Programmable (OTP) storage during manufacturing.
+* Hardware Cryptographic Identity: Symmetric and asymmetric keys associated with the hardware, used to attest the authenticity of the chip and also as a component of the Owner Cryptographic Identity.
+ These keys are generated inside the device by the secure manufacturing process.
+* Hardware Transport Certificate: Used to endorse the asymmetric hardware identity with a transit PKI trusted by the Silicon Owner at Ownership Transfer time.
+* Factory Firmware: Baseline image with support for firmware update and Ownership Transfer.
+ Firmware update may be actuated by writing an OpenTitan update payload to boot flash.
+ Upon reset, OpenTitan scans the boot flash device for valid updates.
+ The factory image may not be owned by the Silicon Owner and its main purpose is to assist Ownership Transfer.
+* Owner Cryptographic Identity: The Silicon Owner is required to generate an identity as part of the Ownership transfer flow.
+ Owner identities are bound to the Hardware Identity and the software version running on the device.
+ Owner identities are used in Silicon Ownership attestation flows and as a root component of Application keys.
+* Application Keys: Keys bound to the owner identity and the application version running on the device.
+ Application keys are provisioned in most cases when the application runs for the first time.
+ The purpose of each key is configured at the application layer and enforced by the kernel.
+
+### Performance Requirements
+
+Performance requirements are derived from integration-specific requirements.
+The following performance requirements are presented for illustration purposes:
+
+* Boot Time: Maximum time allowed to get to device kernel serving state from cold reset.
+* Resume Time: Maximum time allowed to get to device kernel serving state from sleep.
+* External Flash Verification Time: Maximum time allowed for verification of external flash as part of platform boot verified boot implementation.
+ Defined in milliseconds for a given flash partition size.
+
+### Packaging Constraints
+
+* Non-HDI packaging is required.
+* (Proposed) Device packaging QR code with device ID linkable to manufacturing data.
+
+### Additional Requirements
+
+#### Memory Requirements
+
+* At least 512KB of flash storage with 2 partitions, 4KB page size, 100K endurance cycles.
+ 1MB flash would be ideal to allow for future code size growth.
+* At least 16KB of isolated flash storage for manufacturing and device life cycle operations.
+* At least 8KB of OTP for manufacturing and device life cycle operations.
+* At least 64KB of SRAM. 128KB would be ideal for future growth.
+
+#### External Peripherals
+
+The following list of peripheral requirements is speculative at the moment and subject to change based on platform integration requirements:
+
+* SPI Host/Device:
+ * Dual support. Quad support needs to be evaluated.
+ * Required features for EEPROM mode:
+ - Passthrough boot flash interface with support for EEPROM command handling/filtering.
+ - Access to on-die ram and flash memory regions.
+ - Mailbox interface with support for custom opcode commands.
+* eSPI: Enhanced Serial Peripheral (eSPI) which enables asynchronous processing of boot flash commands issued by a boot device supporting the eSPI protocol and serviced by OpenTitan.
+* UART: Debug console interface. May be disabled by production firmware.
+* GPIO: Reset control and monitoring. Status signals.
+* I2C interface compatible with SMBus interfaces.
+
+## Universal 2nd-Factor Security Key
+
+When used as a security key, OpenTitan implements the Universal 2nd Factor (U2F) authentication standard, using a Universal Serial Bus (USB) 1.1 interface to communicate with host devices.
+U2F requires the implementation of a challenge-response authentication protocol based on public key cryptography.
+The security key is provisioned with a unique identity in the form of an asymmetric key, which may be self-endorsed by a certificate issued at manufacturing time.
+
+When used as a security key, OpenTitan shall meet the FIDO Authenticator security goals and measures described in the [FIDO Security Reference v1.2][1] specification.
+See [Universal 2nd Factor (U2F) Overview v1.2][2] for more details on the functional requirements of this use case.
+
+### Certification Requirements
+
+* [BSI-PP-CC-0096-V3-2018][3] FIDO Universal Second Factor (U2F) Authenticator.
+ The minimum assurance level for this Protection Profile (PP) is EAL4 augmented.
+ This PP supports composite certification on top of the Security IC Platform Protection Profile with Augmentation Packages, BSI-CC-PP-0084-2014 (referred to as PP84).
+* [FIPS 140-2 L1 + L3 physical][4] certification is required for some use cases.
+
+### Minimum Crypto Algorithm Requirements
+
+The current target for all crypto is at least 128-bit security strength.
+This is subject to change based on the implementation timeline of any given instantiation of OpenTitan.
+It is expected that a future implementation may be required to target a minimum of 192-bit or 256-bit security strength.
+
+* TRNG:
+ * Entropy source for ECDSA keypair generation (seed and nonce).
+ * (optional) Symmetric MAC key generation.
+* Asymmetric Key Algorithms:
+ * ECDSA: Signature and verification on NIST P-256 curve for identity and attestation keys.
+ * RSA-3072-bit: Secure boot signature verification. Used to verify the signature of the device's firmware.
+* Symmetric Key Algorithms:
+ * AES-CTR:
+ - (optional) Used to wrap a user private key in a key handle. Implementation dependent.
+ * HMAC-SHA256:
+ - For application key handle generation.
+* Hash Algorithms:
+ * SHA-256:
+ - Code and hardware measurements used in internal secure boot implementation.
+ - (optional) For key handle generation. Implementation dependent.
+ - (optional) Attestation cert generation, if generated on the fly.
+
+
+### Provisioning Requirements
+
+OpenTitan used as a security key has the following provisioning requirements:
+
+* Unique Global Identifier: Non-Cryptographic big integer value (up to 256b) used to facilitate tracking of the devices throughout their life cycle.
+ The identifier is stored in One Time Programmable (OTP) storage during manufacturing.
+* Attestation Key: Unique cryptographic identity used for attestation purposes.
+* Self-Signed Attestation Certificate: Self signed certificate and extracted at manufacturing time for registration purposes.
+ U2F backend servers can whitelist the list of certificates reported by the secure key manufacturer, and use them to perform authenticity checks as part of the registration flow.
+* Factory Firmware: Baseline image with support for firmware update via USB, and the USB HID U2F command spec.
+
+### Additional Requirements
+
+* Physical Presence GPIO: U2F requires physical user presence checks for registration and authentication flows.
+ This is implemented either via a push button or capacitive touch sensor connected to an input GPIO pin.
+ * At least 2 PWM peripherals can facilitate implementation of capacitive touch sensor IO operations.
+* Status LEDs GPIO: The security key may use LEDs to provide feedback to the user.
+ This requires up to 4 additional output GPIO pins.
+* USB HID U2F Stack: The security key communicates with host devices via a USB HID protocol.
+ OpenTitan shall meet the USB 1.1 connectivity and protocol requirements to interface with the host.
+
+### Relevant specs
+
+https://fidoalliance.org/specifications/download/
+
+[1]: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-security-ref-v1.2-ps-20170411.html
+[2]: https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html
+[3]: https://www.commoncriteriaportal.org/files/ppfiles/pp0096V3b_pdf.pdf
+[4]: https://en.wikipedia.org/wiki/FIPS_140-2#Security_levels
