Introduction of Opentitan security model

Introdcution of the Opentitan security model including device life cycle, ownership, and key derivation/versioning

1. OpenTitanSecurity Model
Chia-Wei Wang
2021.10.26

2. Outline
•Overview
•Logical Security Model
•Logical Entities
•Software Stage
•Memory layout
•Device Life Cycle
•Device Provisioning
•Ownership Transfer
•Identity and Root Key
•Device Attestation
•Secure Boot
•Boot Service

3. Overview
•A trustworthy, vendor-agnostic open source silicon Root of Trust (RoT) project
•Administrated by lowRISCCommunity Interest Company (C.I.C, non-profit)
•Based on RISC-V ISA

4. Logical Entities
•Stakeholder
•Silicon Creator(e.g. Aspeed, Quanta, Supermicro, etc.)
•Silicon Owner (e.g. FB, Dell, IBM, etc.)
•Application Provider
•End User
Arch/Design Tapeout
Wafer Prod
/ Package
MfgTest
Creator
Secure Mfg
Ownership
Assign
Deploy
Functional
Stack
Deploy
APPs
Silicon Creator Silicon Owner

5. Software Stage

6. Memory Layout
Isolated

7. OpenTitanSecurity Model Specification

8. Device Life Cycle
•Device operational states supported for
•Manufacturing
•Provisioning
•Regular operation
•RMA

9. Device Life CycleDiagram
M a nufa cturing S ta te
Manufacturing State →
I dentity O wnership S ta te
Identity & Ownership State →
•Unlock token is required for
Conditional Transition
•Not require CPU intervention
•Sent via Test Access Port (TAP) interface
Unlock Tok en
Unlock Token →

10. Life Cycle State Capability
Functions DFT_EN NVM_DEBUG_EN HW_DEBUG_EN CPU_EN
RAW Y
TEST_LOCKED
TEST_UNLOCKED Y Y Y Y
DEV Y Y
PROD Y
PROD_END Y
RMA Y Y Y Y
SCRAP
INVALID
DFT: Design For Test
NVM: Non-Volatile Memory

11. Device Provisioning
•Device personalization
•Initialization of cryptographic secret for creator and device
•Occurs at manufacturing phase
•Device owner personalization
•Initialization of cryptographic secret for next owner

12. Device Personalization

13. Device Owner Personalization
•ATE at manufacturing
•x86/AMD server at post-manufacturing (preferred)

14. Ownership Transfer
•Owner keys provisioned
•CODE_SIGN
•UNLOCK
•NEXT_OWNER
•CODE_SIGN
•Verify signed owner BL0 bootloader
•RSA-3072 public key with exponent 3 or F4
•UNLOCK
•Verify signed command for UNLOCKED_OWNERSHIP state transition
•ECC NIST-P256 public key
•NEXT_OWNER
•Verify signed manifest with new owner keys included
•ECC NIST-P256 public key

15. Ownership Transfer Flow
Kernel
Signing
Authority
ROM_EXT
1. Request signature for OWNERSHIP_UNLOCK command
4. Request signature for next owner’s manifest
2. (OWNERSHIP_UNLOCK_CMD)
UNLOCK
5. (NEXT_OWNER_MANIFEST)
NEXT_OWNER
3. Request UNLOCKED_OWNERSHIP state transition with (OWNERSHIP_UNLOCK)
UNLOCK
6.Request new manifest installation with (NEXT_OWNER_MANIFEST)
NEXT_OWNER
7. New owner key provisioning
K: Pre-provisioned Device Integrity Secret
Kn= MAC(K, "OwnerSlot" | slot | id | prev_owner_digest)
OpenTitan

16. Identities and Root Keys
•Terminology
•Device Identifier
•Non-cryptographic, per-device data
•Creator/Owner Public and Private Key
•Asymmetric key-pair authenticated by CA and verified through PKI chain
•Creator/Owner Identity
•Asymmetric key-pair derived for the attestationto the authenticity of the combination of
HW and SW configuration
•xxxKey
•Symmetric key for key derivation and SW use
•KM_DERIVE
•Key Manager one-way function to derive a new symmetric key

17. Identity Flow

18. Identity Flow –ROM
Name Encoding Description
RootKey OTP Provisioned at manufacturing time by the Silicon Creator
DiversificationKey Flash Provisioned at manufacturing time by the Silicon Creator
HealthStateMeasurementRegister
Comprise the following measurements:
•Device life cycle state
•Debug mode state
•ROM Hash
DeviceIdentifier OTP
256 bits information including
•128 bits HW information
•128 bits Stock Keeping Unit (SKU) device information
HardwareRevisionSecretGate Provisioned before tape out
ROMExtSecurityDescriptorRegister
One of the following options:
•Hash of the ROM extension
•Software binding tag stored in the ROM_EXT manifest

19. Identity Flow –ROMExtension
Name EncodingDescription
SoftwareBinding RegisterSoftware binding value configured during secure boot.
OwnerRootSecret Flash Provisioned at ownership transfer. Hidden from SW (ROM/ROM_EXT optional)
IdentityDiversifactionConstantGate Constant with acceptable entropy provisioned in gates

20. Identity Flow –BL0 Bootloader
Name EncodingDescription
SoftwareBinding RegisterSoftware binding value configured during secure boot.
OwnerRootIdentityKey Gate Constant with acceptable entropy provisioned in gates

21. Identity Flow –Kernel
Name EncodingDescription
KeyVersion RegisterKey version which pass version comparison criteria during secure boot
KeyID RegisterKey identifier
SoftwareExportConstant Gate Constant with acceptable entropy provisioned in gates
Salt RegisterSalt input controlled by SW
•VersionedKey
•Final output to wrap secret
•Isolation enforced by SW

22. Key Versioning
•The mechanism by which software implements key rotation
•Triggered by security update
•Require at least 8 32-bits version comparators with lockable control

23. Device Attestation
•Provide signed evidence about the device state
•Is it secure booted?
•Is it debug enabled?
•Rooted in two asymmetric keys
•Creator Identity
•Owner Identity
•Two attestation mechanisms supported
•Creator Based Attestation
•Owned Device Attestation

24. Creator Based Attestation
•Attest the authenticity of HW, ROM/ROM_EXT configuration, and Creator Identity
•Creator Identity Certificate
•X.509 format
•Extensions for compatibility with Open DICE profile
•Extensions for device identifiable information
Seq. No.Name Encoding Description
0 Operational ModeINTEGER Operational modeof the device
1 Device IdentifierOCTET STR Device Identifier
2 HASH Type OCTET STR HASH type used in measurements
3 ROM Hash OCTET STR ROM contents hash
4 ROM EXT Hash OCTET STR ROM EXT contents hash. Includes code manifest
5 Code Descriptor OCTET STR ROM/ROM_EXT versioning information

25. Owned Device Attestation
•Attest ownership of the device, BL0 configuration, and Owner Identity
•Owner Identity Certificate
•X.509 format
•Extensions for compatibility with Open DICE profile
•Extensions for BL0 information
Seq. No.Name Encoding Description
0 Code Descriptor OCTET STR BL0 version and key manager software binding tag information

26. Attestation Chain
•Creator Identity
•Generated at manufacturing time
•Endorsed by Creator PKI
•Owner Identity
•Generated at ownership transfer
•Endorsed by Creator Identity or
Owner PKI

27. Secure Boot
Isolated
Verify with
Silicon Creator
CA Public Key
Verify with
Silicon Owner
CA Public Key

28. Boot Service
Kernel
ROM_EXT
Scratch
Reg
Retention
SRAM
1. Write BOOT_SERVICE_REQUEST
2. Enqueue boot_requeststructure
3. Trigger system reset
4. Check reset cause
5. Parse boot_requestand serve
Command Description Recall
UNLOCK_OWNERSHIP Relinquish ownership of the device pg. 15
TRANSFER_OWNERSHIP Initiate processing of an ownership transfer blob pg. 15
REFRESH_ATTESTATIONCauses the ROM_EXT to regenerate the attestation chain pg. 16
UPDATE_FIRMWARE Instructs the active ROM_EXT to begin the firmware update process

29. Discussion
•Can ROM_EXT stay alive after its boot stage
•No, ROM_EXT serves only at AC-on and reset with BOOT_SERVICE_REQUEST
•Difference between Creator/Owner CA keys and identity keys
•CA keys: used for identity keys endorsement and secure boot
•Identity keys: used only for attestation
•Key versioning use case
•No idea now

30. Thank You

31. Manufacturing State 1/3
Name EncodingDescription
RAW OTP
This is the default state of the OTP.
During this state, no functions other than transition to TEST_UNLOCKED0 are available.
The token authorizing the transition from RAW to TEST_UNLOCKED0 is a value that is secret global to all devices. This is known as
the RAW_UNLOCK token.
TEST_LOCKED{N} OTP
TEST_LOCKED{N} states have identical functionality to RAW state and serve as a way for the Silicon Creator to protect devicesin
transit.
It is not possible to provision OTP root secrets during this state. This is enforced by hardware and is implementation defined.
To progress from a TEST_LOCKED state to another TEST_UNLOCKED state, a TEST_UNLOCK token is required.
TEST_UNLOCKED{N}OTP
Transition from RAW state using OTP write.
This state is used formanufacturing and production testing.
During this state:
•CPU execution is enabled
•NVM backdoor functions are enabled
•Debug functions are enabled
•DFT functions are enabled
Note: during this state it is not possible to provision specific OTP root secrets. This will be enforced by hardware.
It is expected that during TEST_UNLOCKED0 the TEST_UNLOCK and TEST_EXIT tokens will be provisioned into OTP.
Once provisioned, these tokens are no longer readable by software.
Ba ck
Back

32. Manufacturing State 2/3
Name EncodingDescription
PROD OTP
Transition from TEST_UNLOCKED state via OTP write. This is a mutually exclusive state to DEV and PROD_END.
To enter this state, a TEST_EXIT token is required.
This state is used both for provisioning and mission mode.
During this state:
•CPU execution is enabled
•NVM backdoor functions are disabled
•Debug functions are disabled
•DFT functions are disabled
PROD_END OTP
This state is identical in functionality to PROD, except the device is never allowed to transition to RMA state.
To enter this state, a TEST_EXIT token is required.
DEV OTP
Transition from TEST_UNLOCKED state via OTP write. This is a mutually exclusive state to PROD and PROD_END.
To enter this state, a TEST_EXIT token is required.
This state is used for developing provisioning and mission mode software.
During this state
•CPU execution is enabled
•NVM backdoor functions are disabled
•Debug functions are enabled
•DFT functions are disabled
Ba ck
Back

33. Manufacturing State 3/3
Name EncodingDescription
RMA OTP
Transition from TEST_UNLOCKED / PROD / DEV via OTP write. It is not possible to reach this state from PROD_END.
When transitioning from PROD or DEV, an RMA_UNLOCK token is required.
When transitioning from TEST_UNLOCKED, no RMA_UNLOCK token is required.
A hardware-backed mechanism will erase all owner flash content before RMA transition is allowed. This includes the isolation owner
flash partitions as well as any owner code. Once erasure is confirmed and verified, RMA transition will proceed.
During this state
•CPU execution is enabled
•NVM backdoor is enabled
•Debug functions are enabled
•DFT functions are enabled
SCRAP OTP
Transition from any manufacturing state via OTP write.
During SCRAP state the device is completely dead. All functions, including CPU execution are disabled.
No owner consent is required to transition to SCRAP.
Note also, SCRAP is meant as an EOL manufacturing state. Transition to this state is always purposeful and persistent, it is NOTpart
of the device’s native security countermeasure to transition to this state.
INVALID OTP
Invalid is any combination of OTP values that do not fall in the categories above. It is the “default” state of life cycle when no other
conditions match.
Functionally, INVALID is identical to SCRAP in that no functions are allowed and no transitions are allowed.
A user is not able to explicitly transition into INVALID (unlike SCRAP), instead, INVALID is meant to cover in-field corruptions, failures
or active attacks.
Ba ck
Back

34. Identity & Ownership State
Name EncodingDescription
BLANK OTP Initial identity and ownership state. There is no hardware identity or ownership provisioned
CREATOR
PERSONALIZED
OTP
The hardware relevant information has been provisioned. This includes:
•RMA_UNLOCK Token
•Creator Root Key
•Creator Diversification Key
Once the identity state advances to CREATOR_PERSONALIZED, creator provisioned secrets (see Identity flow) are
no longer accessible to software and are directly consumed by hardware.
UNLOCKED_OWNERSHIP
Isolated
Flash
This state represents a device which contains a Creator Identity but does not yet have a Silicon Owner
provisioned.
Since this state is software managed, software is free to define a different state.
LOCKED_OWNERSHIP
Isolated
Flash
This state represents a device which contains both a Creator Identity and a Silicon Owner.
A device in the LOCKED_OWNERSHIP state can transition back to UNLOCKED_OWNERSHIP when it is explicitly
unbound. The unbinding process is described separately.
Since this state is software managed, software is free to define a different state.
EOL
Isolated
Flash
This state represents a device that has reached its identity EOL.
Since this state is software managed, software is free to define a different state.
Ba ck
Back

35. Unlock Token
Token StorageDevice Unique? Usage
RAW_UNLOCK RTL No From RAW->TEST_UNLOCKED0
TEST_UNLOCK OTP Silicon creator choice From TEST_LOCKED{N} to TEST_UNLOCKED{N}
TEST_EXIT OTP Silicon creator choice From any TEST_UNLOCKED state to DEV, PROD_END or PROD
RMA_UNLOCK OTP Yes From PROD/DEV to RMA
Ba ck
Back