Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Understanding ISO/IEC 11889-1:2016 (CAN/CSA-ISO/IEC 11889-1-16) – Trusted Platform Module Architecture
A Technical Overview of the TPM 2.0 Architectural Specification for Secure Hardware-Based Computing
ISO/IEC 11889-1:2016, adopted in Canada as CAN/CSA-ISO/IEC 11889-1-16, is the foundational architecture specification for Trusted Platform Module (TPM) 2.0 secure cryptoprocessors. Developed jointly by ISO and IEC, this standard defines the core architectural concepts, structures, and interfaces that enable hardware-rooted trust for computing systems. This article provides a detailed examination of its scope, technical requirements, implementation highlights, and compliance considerations.
Scope of ISO/IEC 11889-1:2016
The standard covers the architectural specification of a Trusted Platform Module (TPM) that provides a hardware-based root of trust for computing platforms. It defines TPM 2.0 as an evolution from TPM 1.2, offering enhanced cryptographic flexibility, more robust authorization mechanisms, and support for a wider range of use cases including platform integrity attestation, key management, and secure boot. Key scope elements include:
- Logical and physical architectural components of the TPM
- Data structures (e.g., capabilities, hierarchies, policies)
- Command and response structure for communication between host and TPM
- Authorization, session, and audit frameworks
- Key and credential management concepts
Tip: ISO/IEC 11889-1:2016 is part of a multi-part standard set. Part 2 covers structures, Part 3 covers commands, and Part 4 defines the TPM profile. Part 1 provides the essential conceptual foundation for understanding the other parts.
Technical Requirements of the TPM Architecture
ISO/IEC 11889-1:2016 specifies the architectural requirements that a TPM must satisfy. These requirements are organized around the following key areas:
Hierarchies
The TPM architecture defines multiple hierarchies to isolate different trust domains: Platform, Storage, Endorsement, and Null (for transient data). Each hierarchy has its own authorization policies and persistent storage.
Keys and Credentials
The standard defines several key types including Signing Keys, Storage Keys, Attestation Identity Keys (AKs), and Endorsement Keys (EKs). Keys are associated with specific hierarchies and access policies. The TPM provides cryptographic operations such as signing, encryption, and key derivation without exposing private key material to the host.
Platform Configuration Registers (PCRs)
PCRs store integrity measurements (hashes) and support extend operations. The architecture specifies a minimum of 24 PCR banks, each capable of holding a hash (SHA-1, SHA-256, etc.). These registers enable boot integrity attestation and sealing of keys to specific configurations.
Authorization and Policies
The standard introduces Enhanced Authorization (EA), which uses policy sessions to combine multiple conditions (e.g., password, PCR values, command locality) into a flexible access control framework. This replaces the rigid authorization model of TPM 1.2.
| Architectural Component | Description | Function |
|---|---|---|
| Non-Volatile Memory (NV) | Persistent storage for hierarchies, keys, and data blobs | Provides secure, tamper-resistant storage internal to the TPM chip |
| Platform Configuration Registers (PCRs) | Memory slots that store integrity measurement digests | Enable boot attestation and sealing of secrets |
| Attestation Identity Keys (AKs) | Derived from the Endorsement Key to support privacy-preserving attestation | Sign PCRs and other attestation data without revealing the EK identity |
| Enhanced Authorization policies | Composable access policies using boolean logic | Control access to keys and resources under fine-grained user or administrator rules |
| Command Ordinaries and Sessions | Structured formats for TPM command input and output | Enable interoperability and auditing of TPM interactions |
Important: Implementing TPM 2.0 according to ISO/IEC 11889-1 requires careful attention to the authorization policy framework. Misconfiguration can lead to security gaps that defeat the hardware root of trust.
Implementation Highlights and Considerations
When implementing a system that leverages ISO/IEC 11889-1:2016, developers and security engineers should focus on the following aspects:
- TPM Driver Integration: The TPM is typically accessed via the TPM Software Stack (TSS) library. The standard defines the command structures that the TSS must handle.
- Policy Design: Use the policy session commands to implement conditional access rules. For example, a key can be released only when certain PCR values are present.
- Key Hierarchy Cleanup: Ensure that storage hierarchies (Storage and Endorsement) are properly cleared during decommissioning to maintain security.
- Performance vs. Security Trade-offs: While TPM 2.0 introduces many cryptographic primitives, choosing the right combination (e.g., RSA vs. ECC) affects both security strength and speed.
- Backward Compatibility: TPM 2.0 is not directly compatible with TPM 1.2. Migration of keys and policies must be planned carefully.
Best Practice: Use the TPM’s built-in Certified Migratable Key (CMK) mechanism to safely transfer keys between TPMs under domain administrator control.
Risk: Failing to protect the TPM’s persistent storage hierarchy with a strong authorization policy may allow an attacker to extract sensitive key material, especially during physical attacks such as SPI bus probing.
Compliance and Certification Notes
Compliance with ISO/IEC 11889-1:2016 as adopted by CAN/CSA is an integral part of security certifications such as Common Criteria (ISO/IEC 15408) and FIPS 140-2/140-3. Key compliance points include:
- Conformance Testing: Vendors must validate that their TPM implementation adheres to the architectural requirements, command set, and data structures defined in Part 1, along with the relevant parts 2-4.
- Interoperability: The TPM Command Interoperability Profile (TCI) ensures that different vendors’ TPMs can be managed by a common TSS and operating system.
- Security Assurance: The standard supports evaluatation against protection profiles (e.g., TPM2.0 PPs) for use in government and enterprise security architectures.
- Adoption Notes for Canada: CAN/CSA-ISO/IEC 11889-1-16 is identical to the ISO/IEC version except for Canadian foreword and bilingual presentation. No additional technical deviations exist.
Note: The TPM 2.0 architecture is designed to be platform-independent—compatible with x86, ARM, and RISC-V systems—making it a universal trust anchor for modern security frameworks.
Frequently Asked Questions
Q: What is the main difference between TPM 1.2 and TPM 2.0 architecture as defined in ISO/IEC 11889-1?
A: TPM 2.0 introduces flexible authorization policies (Enhanced Authorization), support for multiple algorithm suites (e.g., SHA-256, ECC), and a hierarchical key structure that decouples ownership from platform access. TPM 1.2 used a rigid fixed authorization and only RSA/SHA-1 algorithms.
A: TPM 2.0 introduces flexible authorization policies (Enhanced Authorization), support for multiple algorithm suites (e.g., SHA-256, ECC), and a hierarchical key structure that decouples ownership from platform access. TPM 1.2 used a rigid fixed authorization and only RSA/SHA-1 algorithms.
Q: Does CAN/CSA-ISO/IEC 11889-1-16 differ from the original ISO/IEC 11889-1:2016?
A: The Canadian adoption is technically identical to the international standard. Only minor editorial changes (Canadian bilingual title, foreword) were made. All technical requirements, structures, and interfaces remain the same.
A: The Canadian adoption is technically identical to the international standard. Only minor editorial changes (Canadian bilingual title, foreword) were made. All technical requirements, structures, and interfaces remain the same.
Q: Which part of ISO/IEC 11889 should I start with if I am implementing a TPM-based system?
A: Begin with Part 1 to understand the architectural model, then move to Part 2 (structures) and Part 3 (commands). Part 4 (support library and concurrency) is needed for driver-level implementation.
A: Begin with Part 1 to understand the architectural model, then move to Part 2 (structures) and Part 3 (commands). Part 4 (support library and concurrency) is needed for driver-level implementation.
Q: Are there mandatory cryptographic primitives in ISO/IEC 11889-1?
A: The standard mandates support for specific cryptographic algorithms (e.g., RSA, AES, SHA-1/SHA-256) but also allows manufacturer-defined extensions. At least one symmetric and one asymmetric algorithm must be implemented to qualify as a TPM 2.0 device.
A: The standard mandates support for specific cryptographic algorithms (e.g., RSA, AES, SHA-1/SHA-256) but also allows manufacturer-defined extensions. At least one symmetric and one asymmetric algorithm must be implemented to qualify as a TPM 2.0 device.
Article prepared for technical reference use. Last updated: January 2026. Compliance status reflects CAN/CSA-ISO/IEC 11889-1-16 as of 2026.