[doc/security] Add security/_index.md
Add security index page with introduction to OpenTitan's logical
security features and references to hardware primitives.
Add reference to security/_index.md to landing documentation page.
Signed-off-by: Miguel Osorio <miguelosorio@google.com>
diff --git a/doc/security/_index.md b/doc/security/_index.md
new file mode 100644
index 0000000..b8e34b2
--- /dev/null
+++ b/doc/security/_index.md
@@ -0,0 +1,110 @@
+---
+title: "OpenTitan Security Overview"
+---
+
+## Overview
+
+OpenTitan's mission is to create a trustworthy, vendor-agnostic open source silicon Root of Trust (RoT) widely adopted across the industry.
+We do this by implementing strong logical security integrity guarantees in the hardware and firmware components, and restricting licensing of the OpenTitan trademark to those implementations conforming to OpenTitan standards.
+
+## Logical Security Model
+
+The [OpenTitan Security Model][2] provides a high level framework for device provisioning and run-time operations.
+It starts by enumerating the range of logical entities supported by the architecture, and their mapping into software stages.
+Runtime isolation properties and baseline identity concepts are introduced in this document.
+
+## Functional Guarantees
+
+At the functional level OpenTitan aims to provide the following guarantees:
+
+* Silicon Owners shall be able to deploy their own Root of Trust (RoT) Public Key Infrastructure (PKI) after taking ownership of the device.
+* Silicon Creators shall endorse the authenticity of the hardware.
+ Endorsement is contingent on the silicon adhering to the physical implementation guidelines and standard requirements stipulated by the project.
+ The endorsement shall be measurable via a Transport Certificate.
+* OpenTitan shall provide full boot attestation measurements to allow Silicon Owners to verify the boot chain configuration.
+ The attestation chain shall be anchored in the Silicon Owner's RoT PKI.
+* OpenTitan shall provide a key manager implementation strongly bound to the boot chain.
+ Only a boot chain signed with the expected set of keys shall be able to unlock stored keys/secrets.
+* OpenTitan shall provide a key versioning scheme with support for key migration bound to the firmware versioning and update implementation.
+
+## Use Cases
+
+The security goals of the project are derived from a list of target use cases.
+See [OpenTitan's Use Cases][1] for more details.
+The security goals are used to define OpenTitan's threat model, as well as functional and assurance security requirements.
+Such requirements influence the system architecture, as well as the certification strategy for silicon implementations.
+
+## Security Primitives
+
+All hardware security primitives adhere to the OpenTitan [comportable][3] peripheral interface specification.
+Implementations for some of these components are available for reference and may not meet production or certification criteria yet.
+
+| Block Name | Description |
+| ---------- | ----------- |
+| TRNG Digital Wrapper | Digital wrapper for a NIST SP 800-90 compliant entropy source. <br> An additional emulated entropy source implementation will be available for FPGA functional testing. |
+| DRBG | Proposed: DRBG-HMAC-SHA-2* NIST 800-90A.rev1 compliant. |
+| [AES][8] | AES ECB/CBC/CTR 128/192/256 NIST 800-38A compliant. |
+| [HMAC-SHA-2][9] | HMAC_SHA-2 NIST FIPS 180-4 compliant supporting both HMAC and SHA modes of operation. |
+| Key Manager | Proposed: Hardware backed symmetric key generation and storage providing strong isolation properties. |
+| Crypto Co-Processor | Proposed: Public key cryptography accelerator with support for bignum operations in hardware. |
+| [Alert Handler][10] | Aggregates alert signals from other system components designated as potential security threats, converting them to processor interrupts. It also supports alert policy assignments to handle alerts completely in hardware. |
+
+
+## Features
+
+### Device Life Cycle
+
+OpenTitan supports a set of operational states configured via One Time Programmable (OTP) memory, allowing the [Silicon Creator][4] to manage the state of the device as it is being manufactured and provisioned for shipment.
+
+An additional set of life cycle states are also available to encapsulate the device ownership state.
+A device that has been personalized with a unique [Creator Identity][4] can be provisioned with [Silicon Owner][5] credentials.
+This enables the [Silicon Owner][5] to run signed code on the device.
+
+### Secure Boot
+
+OpenTitan supports a secure boot implementation anchored in the silicon mask ROM.
+The mask ROM contains a set of public keys used to verify the first boot stage stored in flash.
+Isolation between boot stages is enforced by a one way execution model where the current software stage is not allowed to call code in previous stages.
+
+Each boot stage is in charge of verifying the signature of the next stage and locking out portions of the chip that are not required by later stages.
+Once the boot flow reaches kernel execution, the implementation may opt to implement dynamic isolation between applications using the available [Physical Memory Protection][6] (PMP) unit.
+
+### A/B Firmware Updates
+
+OpenTitan supports a firmware layout with two flash partitions, supporting active and non-active instances of each software component.
+This enables a firmware update implementation in which the active partition flashes the new software into the non-active region with minimal downtime.
+Secure boot ensures the integrity and stability of the new software before marking it as active.
+
+Each boot stage is expected to try to launch the newest available version of the next boot stage upon successful signature verification.
+Newest is defined as the software with a more recent build timestamp or larger versioning value.
+
+### Strong Cryptographic Identity
+
+Each OpenTitan silicon device is personalized as part of the manufacturing process with entropy, a unique global identifier, and other values, which are the basis of the chip's cryptographic identity.
+This identity is referred to as the Creator Identity, and it is fixed throughout the lifetime of the silicon.
+
+The Creator Identity is endorsed via a Transport Creator Certificate which can be used in device authenticity attestation flows.
+
+The Creator Identity is a component of other derived identities that are generated with additional input parameters from the software running on the device, as well as other components provisioned by the Silicon Owner.
+
+### Ownership Transfer
+
+The owner of the silicon is allowed to change in a process known as Ownership Transfer.
+During this process, the existing owner shall wipe any stored secrets before relinquishing ownership of the device.
+At this point a new party can take ownership of the device and provision its own identity.
+This allows the new Silicon Owner to run its own signed code with attestation measurements anchored in the PKI of their choice.
+Attested software can then proceed to provision entropy into the key manager plus additional constants to generate hidden keys strongly bound to the software configuration.
+
+More details for this are available in the [OpenTitan Security Model][7].
+
+
+[1]: {{< relref "doc/security/use_cases" >}}
+[2]: {{< relref "doc/security/logical_security_model" >}}
+[3]: {{< relref "doc/rm/comportability_specification" >}}
+[4]: {{< relref "doc/security/logical_security_model#silicon-creator" >}}
+[5]: {{< relref "doc/security/logical_security_model#silicon-owner" >}}
+[6]: https://ibex-core.readthedocs.io/en/latest/pmp.html
+[7]: {{< relref "doc/security/logical_security_model#owner-assignment" >}}
+[8]: {{< relref "hw/ip/aes/doc" >}}
+[9]: {{< relref "hw/ip/hmac/doc" >}}
+[10]: {{< relref "hw/ip/alert_handler/doc" >}}
