diff --git a/src/appendix_a.adoc b/src/appendix_a.adoc index 510d212..13d5eaf 100644 --- a/src/appendix_a.adoc +++ b/src/appendix_a.adoc @@ -10,7 +10,7 @@ VMM-managed hart f/v registers* are expected to be saved/restored by the VMM before a TEECALL, and restored (similar to v/f register management performed by the VMM for ordinary guest VMs). The TSM-driver saves OS/VMM S/HS-mode CSRs and x registers on ECALLs into the HSSA on a TEECALL (per -the RISC-V SBI <> convention). The TSM-driver initializes TSM S/HS-mode +the RISC-V SBI <> convention). The TSM-driver initializes TSM S/HS-mode CSRs from the TSSA on entry into the TSM (via TEECALL). Per-Hart TSM f/v registers* state is managed (saved/restored) by the TSM in reserved memory for the TSM (hence not shown below). diff --git a/src/attestation.adoc b/src/attestation.adoc index c17f504..3d2a466 100644 --- a/src/attestation.adoc +++ b/src/attestation.adoc @@ -170,7 +170,7 @@ The TVM measurement extension interface is exposed through the optional COVG-ABI [NOTE] ==== If an implementation uses UEFI firmware to initialize the CoVE TVM guest -environment, then refer to UEFI specification <> chapter 38 on confidential +environment, then refer to UEFI specification <> Ch.38 on confidential computing for UEFI ABI related to runtime measurement extension and event log creation. ==== @@ -187,7 +187,7 @@ In this section, we describe the high level model of remote attestation for CoVE ==== Model -The CoVE attestation model follows the IETF RATS <> Remote Attestation +The CoVE attestation model follows the IETF RATS <> Remote Attestation architecture. CoVE implementations perform the RATS Attester role, and each CoVE TCB component participates to the generation of a layered Attestation Evidence composed of TCB specific Claims. Moreover, the generated CoVE Evidence freshness @@ -197,7 +197,7 @@ Set. This is enforced by the `sbi_covg_get_evidence` intrinsic signature. In Remote Attestation, the Attester produces information about itself (Evidence) to enable a remote peer (the Relying Party) to decide whether to consider that Attester a trustworthy peer or not. -The Verifier authenticates the Evidence with Endorser provided trust anchors +The Verifier authenticates the Evidence with Endorser-provided trust anchors (Endorsements), compares it against Reference Values and appraises it via appraisal policies. It eventually creates Attestation Results to support Relying Parties in their decision process. @@ -327,10 +327,10 @@ measurement to support the CoVE layered RTMs attestation of CoVE workloads. The CoVE Attestation Evidence uses the IETF Entity Attestation Token (<>), formatted as an untagged, unprotected Concise Binary Object Representation -(<>) Web Token (<>). A CoVE EAT profile is proposed to narrow the +(<>) Web Token (<>, <>). A CoVE EAT profile is proposed to narrow the EAT specification for the CoVE use case to enable interoperability. -The UCCS (Unprotected CWT Claims Set) is composed of one EAT submodule Claims-Set +The UCCS (Unprotected CWT Claims Set) is composed of one EAT submodule Claims-Set map where the map values are attestation tokens for the TVM, TSM and Platform Claims. The TVM EAT is a CWT tagged CBOR formatted token, wrapped with a @@ -786,6 +786,16 @@ signed with the TSM attestation key. The algorithm used to sign the certificate is described by the COSE_Sign1 envelope. It is recommended to use an EdDSA scheme with SHA-512, e.g. Ed25519. +[NOTE] +==== +The COSE_Sign structure might include signatures generated with both the +Edwards-curve Digital Signature Algorithm (EdDSA) <> and the Elliptic +Curve Digital Signature Algorithm (ECDSA) <>. This allows recipients to +verify the signature associated with one algorithm or the other. More detailed +information on multiple signature evaluations can be found in IETF RFC 5752 +<>. +==== + The CBOR certificate COSE_Sign1 payload is a CWT which claim set is composed of the CoVE evidence token and 2 additional claims: diff --git a/src/bibliography.adoc b/src/bibliography.adoc index ef7525b..ffca291 100644 --- a/src/bibliography.adoc +++ b/src/bibliography.adoc @@ -1,71 +1,82 @@ [bibliography] == Bibliography -* [[[R0,0]]] RISC-V Privileged specification +* [[[PRIVISA,1]]] RISC-V Privileged specification https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf -* [[[R1,1]]] IETF RFC 9334 Remote ATtestation procedureS (RATS) Architecture +* [[[RATS,2]]] IETF RFC 9334 Remote ATtestation procedureS (RATS) Architecture https://datatracker.ietf.org/doc/rfc9334/ -* [[[DICE,2]]] TCG DICE Attestation Architecture, Version 1.00 Revision 0.23 +* [[[DICE,3]]] TCG DICE Attestation Architecture, Version 1.00 Revision 0.23 https://trustedcomputinggroup.org/resource/dice-attestation-architecture/ -* [[[R3,3]]] DMTF DSP0274 Security Protocol and Data Model (SPDM) Specification, Version 1.2.1 -https://www.dmtf.org/dsp/DSP0274 +* [[[SPDM,4]]] DMTF DSP0274 Security Protocol and Data Model (SPDM) Specification, Version 1.2.3 +https://www.dmtf.org/sites/default/files/standards/documents/DSP0274_1.2.3.pdf -* [[[R4,4]]] TCG Reference Integrity Manifest (RIM) Information Model -https://trustedcomputinggroup.org/resource/tcg-reference-integrity-manifest-rim-information-model/ - -* [[[R5,5]]] RISC-V Supervisor Binary Interface +* [[[SBI,5]]] RISC-V Supervisor Binary Interface https://github.com/riscv-non-isa/riscv-sbi-doc[riscv-non-isa/riscv-sbi-doc] -* [[[R6,6]]] RISC-V Debug Specification Standard +* [[[RVIDBG,6]]] RISC-V Debug Specification Standard https://github.com/riscv/riscv-debug-spec/blob/master/riscv-debug-stable.pdf -* [[[R7,7]]] RISC-V Zero-Trust Platform Security Model -https://docs.google.com/document/d/1TRHhsGiB5W4K8M7I4e-f40mOPErTb9sv/edit#heading=h.gjdgxs +* [[[OT,7]]] OpenTitan +https://opentitan.org/ -* [[[R8,8]]] Trusted Computing Group (TCG) Glossary, Version 1.1 Revision 1.0 +* [[[TCGG,8]]] Trusted Computing Group (TCG) Glossary, Version 1.1 Revision 1.0 https://trustedcomputinggroup.org/resource/tcg-glossary/ -* [[[R9,9]]] The RISC-V Advanced Interrupt Architecture Document v0.2.1-draft -https://github.com/riscv/riscv-aia/releases[https://github.com/riscv/riscv-aia/releases] +* [[[RVIAIA,9]]] The RISC-V Advanced Interrupt Architecture Document v0.2.1-draft +https://github.com/riscv/riscv-aia/releases[https://github.com/riscv/riscv-aia/releases -* [[[R10,10]]] The RISC-V Nested Acceleration ("NACL") extension[https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v2.0-rc8/riscv-sbi.pdf] +* [[[RVINACL,10]]] The RISC-V Nested Acceleration ("NACL") extension +https://github.com/riscv-non-isa/riscv-sbi-doc/releases/download/v2.0-rc8/riscv-sbi.pdf * [[[EAT,11]]] IETF Entity Attestation Token (EAT) https://github.com/ietf-rats-wg/eat[https://github.com/ietf-rats-wg/eat] * [[[CBOR,12]]] Concise Binary Object Representation -https://datatracker.ietf.org/doc/rfc8949/[https://datatracker.ietf.org/doc/rfc8949/] +https://datatracker.ietf.org/doc/rfc8949/[https://datatracker.ietf.org/doc/rfc8949/ * [[[CWT,13]]] CBOR Web Token -https://datatracker.ietf.org/doc/rfc8392/[https://datatracker.ietf.org/doc/rfc8392/] +https://datatracker.ietf.org/doc/rfc8392/[https://datatracker.ietf.org/doc/rfc8392/ * [[[UCCS,14]]] Unprotected CWT Claims Sets -https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/[https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/] +https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/[https://datatracker.ietf.org/doc/draft-ietf-rats-uccs/ * [[[COSE,15]]] CBOR Object Signing and Encryption -https://datatracker.ietf.org/doc/rfc9052/[https://datatracker.ietf.org/doc/rfc9052/] +https://datatracker.ietf.org/doc/rfc9052/[https://datatracker.ietf.org/doc/rfc9052/ * [[[Hash_Algorithm_Names,16]]] IANA Hash Function Textual Names -https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml[https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml] +https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml[https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml * [[[TCG_Client,17]]] TCG PC Client Platform Profile https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/ * [[[X509,18]]] X.509 Certificate Profile -https://www.rfc-editor.org/rfc/rfc5280[https://www.rfc-editor.org/rfc/rfc5280] +https://www.rfc-editor.org/rfc/rfc5280[https://www.rfc-editor.org/rfc/rfc5280 * [[[X509_DSA,19]]] X.509 Algorithms for DSA and ECDSA -https://datatracker.ietf.org/doc/rfc5758/[https://datatracker.ietf.org/doc/rfc5758/] +https://datatracker.ietf.org/doc/rfc5758/[https://datatracker.ietf.org/doc/rfc5758/ + +* [[[RVISD,20]]] RISC-V Supervisor Domain Access Protection +https://github.com/riscv/riscv-smmtt/releases/download/v1.0.4/smmtt-spec.pdf + +* [[[RVISEC,21]]] RISC-V Security Model +https://github.com/riscv-non-isa/riscv-security-model/releases/download/v1.0/riscv-platform-security-model.pdf + +* [[[RVICOVEIO,22]]] RISC-V CoVE-IO +https://github.com/riscv-non-isa/riscv-ap-tee-io/releases/download/v0.1.0/riscv-cove-io.pdf -* [[[R20,20]]] RISC-V Supervisor Domain Access Protection[https://github.com/riscv/riscv-smmtt/releases/download/v1.0.4/smmtt-spec.pdf] +* [[[UEFI, 23]]] Unified Extensible Firmware Interface (UEFI) Specification v2.11 +https://uefi.org/specs/UEFI/2.11/index.html -* [[[R21,21]]] RISC-V Platform Security Model[https://github.com/riscv-non-isa/riscv-security-model/releases/download/0.1/riscv-platform-security-model.pdf] +* [[[RFC8032,24]]] IETF RFC 8032 Edwards-Curve Digital Signature Algorithm (EdDSA) +https://datatracker.ietf.org/doc/rfc8032/ -* [[[R22,22]]] RISC-V CoVE-IO[https://github.com/riscv-non-isa/riscv-ap-tee-io/releases/download/v0.1.0/riscv-cove-io.pdf] +* [[[DSS,25]]] National Institute of Standards and Technology, "Digital Signature Standard (DSS)", FIPS 186-5, DOI 10.6028/NIST.FIPS.186-5, February 2023 +https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf -* [[[R23, 23]]] Unified Extensible Firmware Interface (UEFI) Specification v2.1[https://uefi.org/specs/UEFI/2.10/index.html] +* [[[RFC5752,26]]] IETF RFC 5752 Multiple Signatures in Cryptographic Message Syntax (CMS) +https://datatracker.ietf.org/doc/rfc5752/ bibliography::[] diff --git a/src/glossary.adoc b/src/glossary.adoc index 8756e7d..b855260 100644 --- a/src/glossary.adoc +++ b/src/glossary.adoc @@ -20,7 +20,7 @@ HW-rooted cryptographically-protected evidence. | CDI | Compound device identifier (CDI) is the value that represents the hardware, software and firmware combination measured by the TCB elements -transitively. A CDI is the output of a DICE <> and is passed to the entity +transitively. A CDI is the output of a DICE <> and is passed to the entity which is measured by the previous TCB layer. The CDI is a secret that may be certified to use for attestation protocols. @@ -30,7 +30,8 @@ performing computation in a hardware-based, attested TEE. | CoVE | Confidential VM extension (CoVE) is the set of non-ISA RISC-V ABI extensions defined in this specification that enables confidential computing on RISC-V platforms. In some deployment models, the CoVE ABI leverages the RISC-V -ISA extensions specified in the RISC-V Supervisor Domains specification <>. +ISA extensions specified in the RISC-V Supervisor Domains Access Protection +specification <>. CoVE is a Trusted Execution Environment (TEE) ABI for Application Processors (APs). A supervisor domain that provides HW-isolation for workload data assets when in use (user/supervisor code/data) and provides HW-attestable @@ -66,13 +67,13 @@ resources. | MTT | Memory Tracking Table (MTT). | Relying party | An entity that depends on the validity of information about -another entity, typically for purposes of authorization <>. +another entity, typically for purposes of authorization <>. -| RISC-V Supervisor Domains | RISC-V privileged architecture <> defines +| RISC-V Supervisor Domains | RISC-V privileged architecture <> defines the S-mode for execution of supervisor software. S-mode software may optionally enable the Hypervisor extension to host virtual machines. Typically, there is a single supervisor domain of execution with access to all physical memory. -*Supervisor Domains* <> is a RISC-V privileged architecture extension to +*Supervisor Domains* <> is a RISC-V privileged architecture extension to support physical address space (memory and devices) isolation for more than one supervisor domain. Supervisor domains enable the reduction of the supervisor Trusted Computing Base (TCB), with differential access to memory and other @@ -83,11 +84,11 @@ immutable ROM firmware and isolated compute and memory elements that form the Trusted Compute Base (TCB) of a TEE system. The RoT manages cryptographic keys and other security critical functions such as system lifecycle and debug authorization. The RoT provides trusted services to other software on the -platform such as verified boot, key provisioning, and management, security +platform such as verified boot, key provisioning and management, security lifecycle management, sealed storage, device management, crypto services, -attestation etc. The RoT may be an integrated or discrete element <>, +attestation etc. The RoT may be an integrated or discrete element e.g.<>, and may take on the role of a Device Identification Composition Engine -(DICE) as defined in <>. +(DICE) as defined in TCG DICE<>. | SVN | Security version number (SVN) is the meta-data about the Trusted Compute Base (TCB) components that conveys the security posture of the TCB. diff --git a/src/overview.adoc b/src/overview.adoc index c879974..068854f 100644 --- a/src/overview.adoc +++ b/src/overview.adoc @@ -32,7 +32,7 @@ specification. The underlying memory isolation mechanism for supervisor domains (Smmtt) is agnostic of the number of supervisor domains. On processors that do not support multiple supervisor domains where Smmtt is not mandated, a single confidential supervisor domain and a single hosting supervisor domain can be -supported using other hardware memory isolation techniques like PMP +supported using other hardware memory isolation techniques like PMP (for example <>, other deployment models are also possible). [id=dep1] @@ -92,7 +92,7 @@ hart. The TSM itself operates in HS-mode (priv=01; V=0) of the hart and enables the OS/VMM (also in HS-mode) to create TVMs, assign resources to TVMs, manage, execute and destroy a TVM - _this specification aims to describe the TEEI and TSM interfaces_. By using the Hypervisor extension of the RISC-V privileged -specification <>, this specification minimizes ISA changes to introduce +specification <>, this specification minimizes ISA changes to introduce a scalable architecture for hosting TEE workloads. More than one confidential supervisor domain may be hosted by the TSM-driver. Similarly, more than one TVM may be hosted by the host OS/VMM via confidential supervisor domains. @@ -152,7 +152,7 @@ permitted as per the active permissions enforced by the memory management unit Smmtt for CoVE). This per-hart execution context is used by the processor to enforce access-control properties on memory accessed by TEE workloads managed by the TSM. The details of the supervisor domain access protection is specified in -the Smmtt specification <>. +the Smmpt specification <>. TSM functionality should be explicitly limited to support only the security primitives to ensure that the OS/VMM and non-confidential VMs do not violate diff --git a/src/refarch.adoc b/src/refarch.adoc index 0bb812e..c363f68 100644 --- a/src/refarch.adoc +++ b/src/refarch.adoc @@ -215,7 +215,7 @@ scrubbing memory when being assigned to a TVM. === TSM initialization The CoVE architecture requires a hardware root-of-trust (RoT) for supporting -TCB measurement, reporting and storage <>. The root-of-trust for +TCB measurement, reporting and storage <>. The root-of-trust for measurement (RTM) is defined as the TCB component that performs a measurement of an entity and cryptographically signs it as attestation evidence subsequently reported to a relying party. The @@ -349,7 +349,7 @@ TSM-driver* * If trap is a synchronous trap due to TEECALL/ TEERESUME then activate confidential supervisor domain for the hart via M-mode `mmpt` CSR (See -Supervisor Domains specification <> for CSR definition) +Supervisor Domains specification <> for CSR definition) * Locate the per-hart THCS (located within TSM-driver memory data region) * Save operating VMM csr context into the THCS.hssa (Hart Supervisor State Area) fields: sstatus, stvec, scounteren, sscratch, satp (and other x @@ -387,7 +387,7 @@ any v/f register state must be restored by the caller. * TSM-driver passes TSM/TVM-specified register contents to the OS/VMM to return status from TEERET (TSM sets a0, a1 registers always - other registers may be selected by the TVM) -* Enable hosting supervisor domain on hart (via Superisor Domains <> +* Enable hosting supervisor domain on hart (via Superisor Domains <> M-mode CSR `mmpt` to disable non-TCB accesses to confidential memory.) * MRET to resume execution in OS/VMM at mepc set to THCS.hssa.pc (THCS.hssa.pc adjusted to refer to opcode after the ECALL that triggered @@ -551,7 +551,7 @@ In order to support probe-mode debugging of the TSM, the RoT must support an authorized debug of the platform. The authentication mechanism used for debug authorization is implementation-specific, but must support the security properties described in Section 3.12 of the RISC-V Debug -Support specification version 1.0.0-STABLE <>. The RoT may support +Support specification version 1.0.0-STABLE <>. The RoT may support multiple levels of debug authorization depending on access granted. For probe-based debugging of the hardware, the RoT performing debug authentication must ensure that separate attestation keys are used for TCB diff --git a/src/sbi_cove.adoc b/src/sbi_cove.adoc index 5ef3f44..2eb3dfc 100644 --- a/src/sbi_cove.adoc +++ b/src/sbi_cove.adoc @@ -198,7 +198,7 @@ Host needs access to some of the TVM CSRs and GPRs to handle TVM exits. For example, the host needs `htval` to determine the fault address, `a0`-`a7` GPRs to handle forwarded ECALLs and so on. For this purpose, the host and TSM use the Nested Acceleration (NACL) extension based shared memory interface -<>, from now on called NACL shared memory to avoid confusion with shared +<>, from now on called NACL shared memory to avoid confusion with shared memory pages between TVM and the host. The NACL shared memory interface is between TSM and the host and TSM is diff --git a/src/swlifecycle.adoc b/src/swlifecycle.adoc index e0be546..94be15f 100644 --- a/src/swlifecycle.adoc +++ b/src/swlifecycle.adoc @@ -116,7 +116,7 @@ to cause IPIs to the virtual-harts managed by the TVM OS (and verified by the TVM OS to ensure the IPIs are received by the TVM OS to invalidate the TLB lazily). -For implementations using AIA <>, this reference architecture requires +For implementations using AIA <>, this reference architecture requires use of AIA IMSIC to ensure these IPIs are delivered through the IMSIC associated with the guest TVM. Each TVM is allocated a guest interrupt file during TVM initialization. diff --git a/src/threatmodel.adoc b/src/threatmodel.adoc index 0b1dce4..6800a61 100644 --- a/src/threatmodel.adoc +++ b/src/threatmodel.adoc @@ -1,4 +1,10 @@ [[threatmodel]] + +The RISC-V Security Model <> describes the common security principles +for RISC-V platforms, and the normative requirements for security building +blocks employed in a platform. This specification describes the detailed +threat model for the RISC-V CoVE Confidential Computing use case. + === Adversary Model _Unprivileged Software Adversary_ - This includes software executing in @@ -111,8 +117,9 @@ T21: A TVM causes a denial of service on the platform. [NOTE] ==== -This threat model is not an exhaustive list and will be updated (via the RISC-V -Security Model specification <>) on a regular basis as attacks evolve. +This threat model is not an exhaustive list and will be updated (via revisions +of the RISC-V Security Model specification <>) on a regular basis as +attacks (are expected to) evolve. ==== === Scope @@ -196,12 +203,12 @@ with another TEE | Supervisor Domains | I/O Protection | DMA protection from non-TCB-admitted devices | Required | DMA access-control, e.g., IOPMP, IOMTT, IOMMU | Prevent non-TCB peripheral devices -from accessing TEE memory | See CoVE-IO <>, IOMMU, Supervisor Domains +from accessing TEE memory | See CoVE-IO <>, IOMMU, Supervisor Domains (IOMTT) | I/O Protection | Trusted I/O from devices admitted into the TCB of a TVM | -Implementation-specific | Device attestation, Link protection, IOMMU | -Admission control to bind devices to TEEs | See CoVE-IO <>, IOMMU, +Implementation-specific | Device attestation <>, Link protection, IOMMU | +Admission control to bind devices to TEEs | See CoVE-IO <>, IOMMU, Supervisor Domains (IOMTT) | Interrupts | Trusted (no spoofing/tampering/dropped) Interrupts | Required |