©NUVOTON TECHNOLOGY CORP.– NON-PROPRIETARY SECURITY POLICY –MAY BE RE-DISTRIBUTED FREELY IN ITS COMPLETE,UNEDITED FORM
Nuvoton Technology Corporation
NPCT7xx TPM 2.0 rev 1.38
FIPS 140-2 Security Policy
Revision 1.0.11
NPCT7xx TPM 2.0 rev 1.38 2 FIPS 140-2 Security Policy
Revision Record
Revision Date Comments
1.0.0 August 15, 2018 First version.
1.0.1 August 28, 2018 Updates following review feedback.
1.0.2 December 9, 2018 Updates following review feedback.
1.0.3 January 6, 2019 Updates following review feedback.
1.0.4 March 5, 2019 Final version for publication.
1.0.5 April 21, 2020 Added a new FW version and updated SP800-56A
revision to 3.
1.0.6 January 6, 2021 Removed FW version 7.2.1.0, changed KDFa to
KBKDF, changed AKWH to KTS, added KDA to
Table 4.
1.0.7 February 11, 2021 Added RSA encrypt/decrypt to Table 12.
1.0.8 March 22, 2021 Updated ECDAA description in Table 6.
1.0.9 April 13, 2021 Removed MGF1 from Table 6.
1.0.10 May 20, 2021 Renamed the function name ECDH to KAS-SSC.
Renamed the function name KTS to KTS-AES.
Renamed the function name RSAES to KTS-RSA.
1.0.11 May 9, 2023 Updated SP800-56B reference to SP800-56B Rev. 2.
Split KTS-RSA to approved and non-approved
algorithms (RSAES_OAEP/RSAES-PKCS1-v1_5).
Updated guidelines in Section 9.1.
NPCT7xx TPM 2.0 rev 1.38 3 FIPS 140-2 Security Policy
Table of Contents
1. MODULE DESCRIPTION...................................................................................................... 5
1.1 GENERAL DESCRIPTION ............................................................................................................... 5
1.2 APPROVED MODES .................................................................................................................... 8
1.2.1 Approved Mode 1........................................................................................................ 8
1.2.2 Approved Mode 2........................................................................................................ 9
2. CRYPTOGRAPHIC FUNCTIONS AND CRITICAL SECURITY PARAMETERS (CSPS).................... 10
2.1 SUPPORTED CRYPTOGRAPHIC FUNCTIONS..................................................................................... 10
2.2 NON-APPROVED BUT ALLOWED ALGORITHMS............................................................................... 12
2.3 NON-APPROVED ALGORITHMS................................................................................................... 12
3. PORTS AND INTERFACES.................................................................................................. 13
4. ROLES, AUTHENTICATION AND SERVICES......................................................................... 14
4.1 AUTHENTICATION .................................................................................................................... 15
4.1.1 Dictionary Attack (DA) Protection............................................................................. 15
4.1.2 Authorization Strength.............................................................................................. 15
Password and HMAC Authorization Strength..................................................................... 15
Policy Authorization Strength............................................................................................. 15
4.1.3 Authorization Token Value Selection........................................................................ 16
4.2 SERVICES................................................................................................................................ 16
5. KEY AND CSP MANAGEMENT .......................................................................................... 19
6. SELF TESTS ...................................................................................................................... 22
6.1 POWER-ON SELF TESTS ............................................................................................................ 22
6.2 CONDITIONAL SELF TESTS.......................................................................................................... 23
7. PHYSICAL SECURITY......................................................................................................... 24
8. ELECTROMAGNETIC INTERFERENCE AND COMPATIBILITY (EMI/EMC) .............................. 25
9. CRYPTO-OFFICER GUIDANCE............................................................................................ 26
9.1 MODES OF OPERATION............................................................................................................. 26
9.2 INSTALLATION ......................................................................................................................... 26
9.3 OBJECT AUTHORIZATION........................................................................................................... 26
9.4 OBJECT DUPLICATION............................................................................................................... 26
9.5 OBJECT IMPORT....................................................................................................................... 27
10. OBJECT USER GUIDANCE ................................................................................................. 28
11. DUPLICATE GUIDANCE..................................................................................................... 29
12. ACRONYMS..................................................................................................................... 30
13. REFERENCES.................................................................................................................... 31
NPCT7xx TPM 2.0 rev 1.38 4 FIPS 140-2 Security Policy
Figures
Figure 1. LAG019 in QFN32 Package ......................................................................................5
Figure 2. LAG019 in UQFN16 Package....................................................................................5
Figure 3. LAG019 in TSSOP28 Package..................................................................................6
Figure 4. TPM 2.0 Logical Block Diagram.................................................................................6
Tables
Table 1. Security Levels............................................................................................................7
Table 2. Approved Mode 1........................................................................................................8
Table 3. Approved Mode 2........................................................................................................9
Table 4. Cryptographic Functions...........................................................................................10
Table 5. Non-Approved but Allowed Algorithms .....................................................................12
Table 6. Non-Approved Algorithms.........................................................................................12
Table 7. Ports and Interfaces..................................................................................................13
Table 8. Roles.........................................................................................................................14
Table 9. Module Services .......................................................................................................16
Table 10. Cryptographic Keys.................................................................................................19
Table 11. Power-On Self Tests (POST)..................................................................................22
Table 12. Conditional Self Tests.............................................................................................23
NPCT7xx TPM 2.0 rev 1.38 5 FIPS 140-2 Security Policy
1. Module Description
1.1 General Description
The Nuvoton Trusted Platform Module (“Module”) is a hardware cryptographic module that
implements advanced cryptographic algorithms, including symmetric and asymmetric
cryptography, as well as key generation and random number generation.
The Module is a single-chip module that provides cryptographic services utilized by external
applications. The Module meets the requirements of FIPS Pub 140-2.
The Module meets commercial-grade specifications for power, temperature, reliability, shock,
and vibrations, and includes chip packaging to meet the physical security requirements at
Physical Security Level 3.
The FIPS 140-2 conformance testing was performed on the following configurations of the
Nuvoton NPCT7xx TPM 2.0:
• Firmware version: 7.2.2.0
• Hardware version 1: LAG019 in TSSOP28 package
• Hardware version 2: LAG019 in QFN32 package
• Hardware version 3: LAG019 in UQFN16 package
The TPM2.0 packages are shown below.
Figure 1. LAG019 in QFN32 Package
Figure 2. LAG019 in UQFN16 Package
NPCT7xx TPM 2.0 rev 1.38 6 FIPS 140-2 Security Policy
Figure 3. LAG019 in TSSOP28 Package
The physical cryptographic boundary of the Module is the outer boundary of the chip
packaging.
Figure 4 shows a logical diagram of the Module:
Figure 4. TPM 2.0 Logical Block Diagram
RNG
Power
Management
NON-VOLATILE
Data
Processor
Crypto
Accelerator
Code
GPIO Peripherals
Volatile
Data
Host Interface
(TIS Emulation)
SPI Bus
GPI0
Physical Presence
NPCT7xx TPM 2.0 rev 1.38 7 FIPS 140-2 Security Policy
The Module was tested to meet overall Security Level 2 of the FIPS PUB 140-2 standard. The
Security Level for each section of FIPS PUB 140-2 is specified in Table 1.
Table 1. Security Levels
FIPS 140-2 Section Security Level
Cryptographic Module Specification 2
Cryptographic Module Ports and Interfaces 2
Roles, Services and Authentication 2
Finite State Model 2
Physical Security 3
Operational Environment N/A
Cryptographic Key Management 2
EMI/EMC 3
Self Tests 2
Design Assurance 2
Mitigation of Other Attacks N/A
NPCT7xx TPM 2.0 rev 1.38 8 FIPS 140-2 Security Policy
1.2 Approved Modes
For some TPM host platforms, it might take too much time to execute all self tests during
power up. Therefore, the TPM supports the following two Approved modes.
1.2.1 Approved Mode 1
This mode is the default mode when the TPM powers up.
Table 2. Approved Mode 1
Properties Description
Definition Transient mode
Configuration This mode is the default mode when the TPM powers up. It
assumes a list of basic algorithms that is going to be used
for basic TPM commands. The algorithms are: SHA1,
SHA256, SHA384, HMAC, KBKDF, KDFe and AES. These
algorithms are tested in _TPM_Init. Thus all the algorithms
from this list are tested before the first command is
executed.
Services available All services that do not use asymmetric cryptography (RSA,
ECDSA, ECDH)
Algorithms used SHS / HMAC / AES / DRBG / KDF
CSPs used Only asymmetric CSPs cannot be used (RSA and ECC keys)
Self tests SHS / HMAC / AES / DRBG / KDF and firmware integrity test
NPCT7xx TPM 2.0 rev 1.38 9 FIPS 140-2 Security Policy
1.2.2 Approved Mode 2
This mode is the Approved mode of operation when all CSPs are accessible.
Table 3. Approved Mode 2
Properties Description
Definition Full Approved mode of operation
Configuration There are three ways to move to Mode 2:
1. TPM2_SelfTest(fullTest = YES) command.
2. TPM2_SelfTest(fullTest = NO) command. If the
firmware is in Mode 1, the command returns
TPM_RC_TESTING. Immediately after that, the
firmware runs a self test equivalent to
TPM2_SelfTest(fullTest = YES). If a command is
received before the TPM has completed self test
execution, the TPM will first complete SelfTest and
then execute the command.
3. Command that requires Mode 2 (all commands not
listed in PTP section 5.5.1.6, Self Test and Early
Platform Initialization).
Incremental ST does not move to Mode 2 even if all
the algorithm testing is completed using this
command.
Services available All services
Algorithms used All supported algorithms
CSPs used All CSPs
Self tests SHS / HMAC / AES / DRBG / KDF / RSA / ECDH / ECDSA
and firmware integrity test
NPCT7xx TPM 2.0 rev 1.38 10 FIPS 140-2 Security Policy
2. Cryptographic Functions and Critical Security Parameters (CSPs)
2.1 Supported Cryptographic Functions
The Module’s cryptographic functions are outlined in Table 4.
Table 4. Cryptographic Functions
Function Function
Name
Key
Size
in Bits
Use Standard CLV
AES Encryption and
Decryption using OFB, CFB
and CTR modes
AES 128 256 Data
Encryption
and
Decryption
FIPS 197,
SP800-38A
5390
RSA Signature Generation
and Verification using
RSASSA-PKCS1-v1_5 and
RSASSA-PSS modes
RSASA 2048 Digital
Signature
FIPS 186-4,
PKCS#1 v2.1
2883
RSA Decryption Operation
Primitive
RSADP 2048 Key
Transport
Primitive
SP800-56B
Rev. 2
1856
RSA Encryption and
Decryption using
RSAES_OAEP mode
KTS-RSA 2048 Key
Transport
SP800-56B
Rev. 2,
PKCS#1 v2.1
Vendor
Affirmed
Generation of RSA Keys RSAKG 2048 Key Pair
Generation
FIPS 186-4 2883
Generation of symmetric
keys and seeds when
generating private keys for
asymmetric key algorithms
CKG1 128
256
Key
Generation
SP800-133 Vendor
Affirmed
ECDSA Signature Generation
and Verification using P-256
and P-384 curves
ECDSA 256
384
Digital
Signatures
FIPS 186-4 1425
Generation of ECDSA Keys ECCKG 256
384
Key Pair
Generation
FIPS 186-4 1425
1 The resulting symmetric key or generated seed is an unmodified output from the DRBG.
NPCT7xx TPM 2.0 rev 1.38 11 FIPS 140-2 Security Policy
Function Function
Name
Key
Size
in Bits
Use Standard CLV
ECC Key Agreement using
Full Unified and One Pass
DH schemes
KAS-SSC 256
384
Key
Agreement
SP800-56A
Rev. 3
Vendor
Affirmed
HMAC HASH Message
Authentication Code using
SHA-1, SHA2-256 and
SHA2-384
HMAC 160
256
384
Keyed
Message
Digest
FIPS 198-1 3572
SHS Hash using SHA-1,
SHA2-256 and SHA2-384
SHA N/A Message
Digest
FIPS 180-4 4325
Deterministic Random Bit
Generation (DRBG)
CTR_DRBG AES-2562
DRBG 256 DRBG SP800-90A 2088
Key Derivation Function
(KDF) using Counter mode
with HMAC3
KBKDF 160
256
Key
Derivation
SP800-108 200
AES Key Wrapping with
HMAC
KTS-AES 128
256
Key
Wrapping
SP800-38F 5390,
3572
One-step Key derivation KDA N/A Key
Derivation
SP800-56C
Rev. 1
Vendor
Affirmed
Note: There are some algorithm modes that were tested but not implemented by the module.
Only the algorithms, modes, and key sizes that are implemented by the module are
shown in this table.
2 The derivation function is not used during instantiation of the CTR_DRBG.
3 For algorithms TPM_ALG_KEYEDHASH and TPM_ALG_SYMCIPHER in [1], part 2.
NPCT7xx TPM 2.0 rev 1.38 12 FIPS 140-2 Security Policy
2.2 Non-Approved but Allowed Algorithms
Table 5 summarizes TPM 2.0 functions that are not approved but allowed.
Table 5. Non-Approved but Allowed Algorithms
Function Function
Name
Key Size
in Bits
Use
NDRNG (entropy source) NDRBG4
N/A Entropy source for the DRBG
2.3 Non-Approved Algorithms
Table 6 summarizes TPM 2.0-specified algorithm functions that do not meet the FIPS 140-2
cryptographic requirements. Usage of these algorithms in a TPM application is limited to non-
cryptographic functions. The module will enter Non-Approved mode upon any cryptographic
use of any of these algorithms.
Table 6. Non-Approved Algorithms
Function Description
SHA-1 Used for digital signature verification (legacy) and any non-digital
signature application.
Not used for digital signature generation.
RSA Not permitted for digital signature generation, key agreement and key
transport schemes with key size = 1024. Usage of 1024 bit keys
considered equivalent to plaintext or obfuscation versus cryptography.
XOR XOR obfuscation used as a hash-based stream cipher.
ECDAA A signature scheme based on ECC that provides anonymous signatures
or pseudonymous signatures. Not used for cryptography. Usage
considered plaintext or obfuscation.
EC Schnorr Used for signing and verifying signatures that are non-FIPS compliant.
Not used for cryptography. Usage considered plaintext or obfuscation.
KTS-RSA RSA Encryption and Decryption using RSAES-PKCS1-v1_5 mode
4 The estimated amount of entropy provided by the NDRNG is 376.32624 bits.
NPCT7xx TPM 2.0 rev 1.38 13 FIPS 140-2 Security Policy
3. Ports and Interfaces
The ports of the Module are:
• SPI Bus
• PP (Physical Presence) Pin
• Platform Reset
• Power
The logical interfaces and the mapping of the logical interfaces to the physical ports of the
Module are described in the table below.
Table 7. Ports and Interfaces
Logical
Interface
Description
Physical
Ports
Control Input
Interface
Control Input commands issued to the chip SPI Bus
PP pin
Platform Reset
Power
Status Output
Interface
Status data output by the chip SPI Bus
Data Input
Interface
Data provided to the chip as part of the
data processing commands
SPI Bus
PP pin
Platform Reset
Data Output
Interface
Data output by the chip a part of the data
processing commands
SPI Bus
PP pin
Platform Reset
Power Interface Power interface of the chip Platform Reset
Power
The Module does not include a maintenance interface.
NPCT7xx TPM 2.0 rev 1.38 14 FIPS 140-2 Security Policy
4. Roles, Authentication and Services
The three operation roles implemented by the Module are summarized in the table below.
Table 8. Roles
Role Acronym High Level Description
Crypto-Officer CO Also known as “Object Administrator”; installs and
configures the Module, controls certification, changes
authorization
Object User5
OU Uses the object to executes services
Duplicate6
DUP Duplicates an object (if object duplication is allowed)
The Module provides three authorization types to identify the role: Password, HMAC and
Policy.
Password Authorization - A plaintext password value presented to authorize an action or
identify a role. A plaintext password may be only appropriate for cases in which the path
between the caller and the TPM is trusted or when the password is well known.
HMAC Authorization – Proving the knowledge of a shared secret via challenge-response
HMAC protocol to authorize an action or identify a role. HMAC key is the shared secret.
Policy Authorization – Also known as “Enhanced Authorization”, allows entity-creators or
administrators to require specific tests or actions to be performed as authorization method or
identity proof. The specific policy is encapsulated in a digest value that is associated with an
entity. An entity has a policy that defines the conditions for use of an entity. A policy may be
arbitrarily complex. However, the policy is expressed as one (statistically unique) digest called
the authPolicy.
Both HMAC and Policy authorizations include rolling nonce values as part of the protocol, as
a challenge and to prevent a replay-attack.
Note: For commands that require Platform Authorization and commands that require a
hierarchy authorization, it is possible to require an additional out-of-band authorization.
This may use a dedicated pin in the TPM – also known as “Physical Presence” (PP).
The TPM maintains a table of the commands that require that PP be asserted to
authorize command execution. Only certain commands may be included in this table.
5 For the context of FIPS 140-2, the Object User is mapped to the User role.
6 For the context of FIPS 140-2, the Duplicate User is mapped to the Crypto-Officer role.
NPCT7xx TPM 2.0 rev 1.38 15 FIPS 140-2 Security Policy
4.1 Authentication
4.1.1 Dictionary Attack (DA) Protection
The TPM incorporates mechanisms that provide protection against guessing or exhaustive
searches of authorization values stored within the TPM.
The DA protection logic is triggered when the rate of authorization failures is too high. If this
occurs, the TPM enters Lockout mode preventing any operation that requires use of a DA
protected object. Depending on the settings of the configurable parameters, the TPM can
“self-heal” after a specified amount of time or be programmatically reset using proof of
knowledge of an authorization value or satisfaction of a policy (i.e., using lockoutAuth).
While authorization values that are expected to be high-entropy values will not need DA
protection, lockoutAuth is always DA-protected even though it may have high-entropy.
4.1.2 Authorization Strength
The Module authenticates operator actions using authorization tokens. Consider most
conservative TPM command throughput on the bus and command execution duration, would
allow 1,000 commands per second or 60,000 attempts per minute.
Password and HMAC Authorization Strength
When a high-entropy authorization token is used (where DA protection may be disabled), each
value, statistically, has the same probability to be chosen. For worst case scenario, assume
SHA-1 output values size (160 bit array), producing 2160 different possible values.
Probability for randomly successful attempt is 2-160, assuming 60,000 trials per minute would
produce probability for success in one minute: 2-160×60,000 = 4.1×10-44<10-5.
If a lower entropy authorization token is used (e.g., memorized PIN or password), a
combination of password size (i.e., determines size of entropy) and DA protection setting
should be selected to meet the FIPS requirements. The requirement of an eight-character
password string with TCG’s default DA settings7 (maxTries = 3; recoveryTime = 1,000
seconds) would produce the necessary strength. For the worst case, assume an eight-digit
PIN, allowing 108 different possible values with equal probability. The TCG default DA
settings listed above would allow three trials before lockout (for duration of over a minute).
The probability for a randomly successful attempt is 10-8, assuming 3 trials would produce the
probability for success in less than one minute: 10-8×3 = 3×10-8<10-5.
Policy Authorization Strength
Since policy authorization is expressed as (statistically unique) digest, for worst case
scenario, assume SHA-1 output values size (160 bit array), producing 2160 different possible
values.
7 See [1] part 1
NPCT7xx TPM 2.0 rev 1.38 16 FIPS 140-2 Security Policy
Probability for randomly successful attempt is 2-160, assuming 60,000 trials per minute would
produce probability for success in one minute: 2-160×60,000 = 4.1×10-44<10-5.
4.1.3 Authorization Token Value Selection
TPM permits the creation of objects with NULL authorization (empty buffer). However, to meet
the Authorization Strength listed in Section 4.1.2, roles should not use NULL authorization
values for CSPs.
The TPM Crypto-Officer’s role is to set proper authorization values for the Storage and
Endorsement hierarchies (if there is no OS managing these authorization values for the user).
4.2 Services
Table 9 lists all Module services, the affected CSPs, and the associated roles:
Table 9. Module Services
Service Description CSP Role
Get Status The Module implements a Get
Status commands that returns the
status of the Module, including
success or failure of self tests.
Note: This service (e.g.,
TPM2_GetCapability) does not require
authentication
None CO,
OU,
DUP
Self Tests The Module runs power-on self
tests automatically when powered
on and on demand.
Note: This service (e.g.,
TPM2_Selftest) does not require
authentication
None CO,
OU,
DUP
Encrypt Used to encrypt data Encryption keys,
Public storage keys,
Platform keys
CO,
OU,
DUP
Decrypt Used to decrypt data Encryption keys,
Private storage keys,
Endorsement keys,
Platform keys
CO,
OU
NPCT7xx TPM 2.0 rev 1.38 17 FIPS 140-2 Security Policy
Service Description CSP Role
Zeroize Used to zeroize (irreversibly
destroy) Module's cryptographic
keys and CSPs
Encryption keys,
Public verification keys,
Public storage keys,
Private storage keys,
Identity keys,
HMAC keys,
Endorsement keys,
Platform keys,
DRBG seed,
DRBG Entropy Input,
DRBG “V”,
DRBG Key
CO
MAC,
MAC Verify
Used to calculate and verify MAC
for data
HMAC keys CO,
OU
Key
Generate
Used to generate keys Encryption keys,
Public verification keys,
Public storage keys,
Private storage keys,
Identity keys,
Ephemeral keys,
HMAC keys,
Endorsement keys,
Platform keys,
DRBG seed,
DRBG Entropy Input,
DRBG “V”,
DRBG Key
CO,
OU
RSA Verify Used to verify data using RSA Public verification keys,
Platform keys,
Firmware Update key
CO,
OU
RSA Sign Used to sign data using RSA Identity keys,
Platform keys
CO,
OU
ECDSA
Verify
Used to verify data using ECDSA Public verification keys,
Platform keys
CO,
OU
ECDSA Sign Used to sign data using ECDSA Identity keys,
Platform keys
CO,
OU
NPCT7xx TPM 2.0 rev 1.38 18 FIPS 140-2 Security Policy
Service Description CSP Role
Key Import Used to import keys Encryption keys,
Public verification keys,
Public storage keys,
Private storage keys,
Identity keys,
HMAC keys,
Platform keys
CO
Key
Duplicate
Used to export keys Encryption keys,
Public storage keys,
Private storage keys,
Ephemeral keys,
HMAC keys,
Platform keys
CO,
DUP
Key
Agreement
Used to derive a key Ephemeral Keys,
Endorsement keys,
Platform keys
CO,
OU
TPM Identity Used to authenticate TPM Identity
to other parties
Identity keys CO,
OU
TPM
Endorsement
Used to prove to other parties that
TPM is a genuine TPM
Endorsement keys CO,
OU
TPM Get
Random
Used to generate random data
Note: This service does not require
authentication.
DRBG seed,
DRBG Entropy Input,
DRBG “V”,
DRBG Key
CO,
OU
TPM Stir
Random
Used to add entropy to the random
bit generator
Note: This service does not require
authentication.
DRBG seed,
DRBG Entropy Input,
DRBG “V”,
DRBG Key
CO,
OU
Install
Module
Installs Module HMAC keys,
Platform keys
CO
Firmware
Update
Updates Module’s firmware.
Requires Platform Authorization.
Firmware Update key CO
NPCT7xx TPM 2.0 rev 1.38 19 FIPS 140-2 Security Policy
5. Key and CSP Management
Table 10 specifies each cryptographic key or CSP utilized by the Module.
For access type description, the following acronyms are used:
W - Write; the CSP is updated/written by the TPM
E - Execute; the CSP is used by the TPM for execution
TPM commands that have CSP as input/output parameters shall use parameter encryption.
Table 10. Cryptographic Keys
Key or
CSP
Func. Usage Service - Access
Encryption
keys
AES
KTS-AES
KBKDF
DRBG
CKG
Used to:
- Wrap keys: for import/duplication,
for wrapping keys stored outside
the TPM and for session keys
(audit or parameter encryption)
- Encrypt/decrypt input/output
parameters
- Decrypt credentials
Keys generated using DRBG,
derived using KBKDF or securely
transported using public/private
storage keys.
Encrypt - E
Decrypt - E
Zeroize - W
Key Import - E, W
Key Generate - W
Key Duplicate - E
Public
verification
keys
RSASA
RSAKG
ECDSA
ECCKG
DRBG
Used to verify signatures on data, as
service for external application, or
as part of Authorization Policy
verification.
Keys may be generated in the TPM
(as part of Identity key generation)
or loaded from external source.
Zeroize - W
Key Generate - W
RSA Verify - E
ECDSA Verify - E
Key Import - W
Public
storage keys
KTS-RSA
RSAKG
KBKDF
DRBG
Used to transport keys generated
externally or generated by TPM.
Keys may be generated in the TPM
(as part of Private storage key
generation) or imported from
external source.
Encrypt - E
Zeroize - W
Key Generate - W
Key Import - W
Key Duplicate - E
Private
storage keys
KTS-RSA
RSAKG
KBKDF
KTS-AES
DRBG
Used to transport keys generated
externally or generated by TPM.
Keys may be generated in the TPM
(stored encapsulated or wrapped
outside the TPM) or imported from
external source.
Decrypt - E
Zeroize - W
Key Generate - W
Key Import - E, W
Key Duplicate - E
NPCT7xx TPM 2.0 rev 1.38 20 FIPS 140-2 Security Policy
Key or
CSP
Func. Usage Service - Access
Identity keys RSASA
RSAKG
ECDSAEC
CKG
KBKDF
KTS-AES
DRBG
Authorization tokens used to prove
TPM identity to other parties.
Used to sign information generated
or controlled by the TPM.
Keys may be generated in the TPM
(stored encapsulated or wrapped
outside the TPM) or imported from
external source.
Zeroize - W
Key Generate - W
RSA Sign - E
ECDSA Sign - E
Key Import - W
TPM Identity - E
Ephemeral
keys
KAS-SSC
ECCKG
KBKDF
KTS-AES
DRBG
Used to exchange secrets to
establish a symmetric key, using
One-Pass Diffie-Hellman.
Used for:
- Encryption of authorization session
salt
- Secret sharing for duplication
- Secret sharing for credentials
Keys may be generated in the TPM
(stored encapsulated or wrapped
outside the TPM) or imported from
external source.
Key Generate - W
Key Duplicate - E
Key Agreement - E
HMAC keys HMAC
KTS-AES
DRBG
CKG
Used to calculate and verify MAC
codes for data.
Used for:
- Ensuring association of credential
with a loaded object
- Access or usage authorization
- Symmetric signing
- Audit
Keys may be generated in the TPM
(stored encapsulated or wrapped
outside the TPM) or imported from
external source.
Zeroize - W
MAC, MAC Verify - E
Key Generate - W
Key Import - W
Key Duplicate - E
Install Module - W, E
Endorsement
keys
KTS-RSA
RSAKG
KAS-SSC
ECCKG
KBKDF
DRBG
Authorization tokens used to prove
to the external parties that TPM is a
genuine TPM.
Keys may be generated in the TPM
or installed during TPM
manufacturing.
Decrypt - E
Zeroize - W
Key Generate - W
Key Agreement - E
TPM Endorsement - E
NPCT7xx TPM 2.0 rev 1.38 21 FIPS 140-2 Security Policy
Key or
CSP
Func. Usage Service - Access
Platform keys AES
KTS-RSA
RSASA
RSAKG
KAS-SSC
ECDSA
ECCKG
KBKDF
DRBG
Keys used by the Platform Firmware. Encrypt - E
Decrypt - E
Zeroize - W
Key Generate - W
RSA Verify - E
RSA Sign - E
ECDSA Verify - E
ECDSA Sign - E
Key Import - E
Key Duplicate - E
Key Agreement - E
Install Module - W, E
Firmware
Update key
RSASA Used to verify signature on firmware
updates.
Key installed at the module
manufacturing.
RSA Verify - E
Firmware update - E
DRBG seed DRBG
NDRBG
Used to seed the DRBG, generated
by the NDRBG.
Zeroize - W
Key Generate - E
TPM Get Random - E
TPM Stir Random - W
DRBG
Entropy Input
DRBG
NDRNG
Used as Entropy input for the
DRBG’s seeds, generated by the
NDRBG.
Zeroize - W
Key Generate - E
TPM Get Random - E
TPM Stir Random - W
DRBG “V” DRBG CTR_DRBG’s internal state that is
updated each time another block
length number of bits of output are
produced.
Zeroize - W
Key Generate - E
DRBG Key DRBG CTR_DRBG’s Key. Zeroize - W
Key Generate - E
NPCT7xx TPM 2.0 rev 1.38 22 FIPS 140-2 Security Policy
6. Self Tests
6.1 Power-On Self Tests
The Module implements the following tests during power-on:
Table 11. Power-On Self Tests (POST)
Cryptography Function Test Type
Firmware integrity MAC using a 128-bit error detection code
HMAC FIPS 198-1 KAT using SHA2-384
SHA-1, SHA2-256, SHA2-384 FIPS 180-4 KAT for each SHA type
AES Encryption / Decryption FIPS 197 KAT from SP800-38A
KBKDF SP800-108 KAT
KDFe8
(for KAS-SSC) SP800-56A Rev. 3 KAT
DRBG SP800-90A DRBG Health Tests (DRBG
Generate, Reseed and Instantiate)
8 SP800-56A rev. 3, section 6.2.2.2. The KDF used is the “One-Step Key Derivation” according to SP800-56C
Rev. 1, section 4.
NPCT7xx TPM 2.0 rev 1.38 23 FIPS 140-2 Security Policy
6.2 Conditional Self Tests
The Module implements the following conditional tests:
Table 12. Conditional Self Tests
Cryptography
Function
Condition Test Type
POST POST All tests listed in Table 11
ECDSA
sign / verify
TPM2_SelfTest(fullTest =
YES) in transition to
Approved Mode 2
FIPS 186-4 KAT
KAS-SSC TPM2_SelfTest(fullTest =
YES) in transition to
Approved Mode 2
SP800-56A Rev. 3 KAT
RSA
sign / verify
TPM2_SelfTest(fullTest =
YES) in transition to
Approved Mode 2
PKCS#1v2.1, FIPS 186-4 KAT
RSA
Encrypt /
Decrypt
TPM2_SelfTest(fullTest =
YES) in transition to
Approved Mode 2
PKCS#1 v2.1, SP800-56B
RSA key
generation
Key Generation Conditional pair-wise consistency
check for RSA public-private key
pairs each time an RSA key pair is
generated, using FIPS 186-4
ECC key
generation
Key Generation Conditional pair-wise consistency
check for ECDSA public-private key
pairs each time an ECDSA key pair
is generated, using FIPS 186-4
Firmware Load
Test
Field Upgrade Firmware update test during the
firmware update. The digital
signature is verified on the
firmware image using an RSA
(SHA2-256) algorithm, utilizing a
2048-bit Firmware Update key
DRBG New bits are generated Continuous Self Test
NDRNG New bits are generated Continuous Self Test
If a conditional or power-on self test fails, the Module enters an error state where both data
output and cryptographic services are disabled.
NPCT7xx TPM 2.0 rev 1.38 24 FIPS 140-2 Security Policy
7. Physical Security
The TPM is implemented as a single integrated circuit (IC) device that attaches to standard
system PCBs. It is manufactured using de-facto standard integrated circuit manufacturing
technologies, producing a device that meets all commercial-grade power, temperature,
reliability, shock and vibration specifications.
The TPM IC physical package provides hardness, opacity and tamper-evidence protection
conforming to FIPS 140-2 Physical Security Level 3. The TPM achieves this level of protection
by implementing an enclosure that is both hard and opaque, as shown in the figures in Section 1.
This type of IC package ensures that any physical tampering will always result in scratches,
chipping or other visible damage on the enclosure.
Before the TPM is integrated into a target application system, it must be checked visually for
tampering. After it is integrated, typically through soldering onto a PCB, it can be inspected for
tampering by opening the application system enclosure and examining the TPM.
Module hardness testing was only performed at ambient room temperature; no assurance is
provided for Level 3 hardness conformance at any other temperature.
NPCT7xx TPM 2.0 rev 1.38 25 FIPS 140-2 Security Policy
8. Electromagnetic Interference and Compatibility (EMI/EMC)
The Module complies with the EMI/EMC requirements specified in Title 47, Code of Federal
Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class B.
NPCT7xx TPM 2.0 rev 1.38 26 FIPS 140-2 Security Policy
9. Crypto-Officer Guidance
9.1 Modes of Operation
The TPM has three modes of operation:
1. Approved Mode 1: Described in Section 1.2.1
2. Approved Mode 2: Described in Section 1.2.2
3. Non-Approved Mode: This mode is entered once one of the functions listed in Table 6
is used as cryptographic function. Before entering this mode, all CSPs must be
zeroized.
For FIPS Compliant mode, (Approved Mode 1 and Approved Mode 2):
• Do not use functions listed in Table 6 as cryptographic functions
• Do not use a key with NULL padding scheme
9.2 Installation
To install the Module in the Approved Mode of operation, do the following:
• The Module must be controlled physically during the installation.
• The Module must be connected on the PCB as described in the Module technical
specifications. The connection must ensures one-to-one binding with the platform.
• The platform on which Module is installed should include BIOS and OS that initialize
and control TPM hierarchies and set hierarchy’s authorization value and policy. If the
platform does not have such BIOS and OS, the crypto-officer shall install software to
manage TPM hierarchies and set the hierarchy’s authorization and policy.
9.3 Object Authorization
On object creation or changing object authorization, a password of at least eight characters
shall be used. In addition, configure the module to enforce, at a minimum, a DA Setting policy
where “maxTries” >=3 and “recoveryTime” >= 1,000.
9.4 Object Duplication
The TPM2_Duplicate command allows sending objects to/from the NULL hierarchy, which
sends it off-chip unprotected. This is not allowed in FIPS 140-2.
The command has an attribute, “encryptedDuplication”, which should always be SET in order
to be compliant with FIPS 140-2. This requires an inner symmetric wrapping prior to the
object receiving symmetric encryption to go off-chip. This also prevents the new parent from
being TPM_RH_NULL (see [1], part 2).
When Object is created, set the attribute “encryptedDuplication” in the object.
NPCT7xx TPM 2.0 rev 1.38 27 FIPS 140-2 Security Policy
9.5 Object Import
The TPM2_Import command allows importing objects from external modules. Import to the
TPM only CSPs coming from FIPS-compliant modules in FIPS Compliant mode.
NPCT7xx TPM 2.0 rev 1.38 28 FIPS 140-2 Security Policy
10. Object User Guidance
The Object User shall follow the guidance in Sections 9.1, 9.3 and 9.5.
NPCT7xx TPM 2.0 rev 1.38 29 FIPS 140-2 Security Policy
11. Duplicate Guidance
The Duplicate role shall follow the guidance in Section 9.4.
NPCT7xx TPM 2.0 rev 1.38 30 FIPS 140-2 Security Policy
12. Acronyms
AES Advanced Encryption Standard
CPU Central Processing Unit
CSP Critical Security Parameter
DA Dictionary Attack
DRBG Deterministic Random Bit Generator
ECC Elliptic Curve Cryptography
EMC Electro-Magnetic Compatibility
EMI Electro-Magnetic Interference
FIPS Federal Information Processing Standard
GPIO General-Purpose Input Output bus
HMAC Hash-based Message Authentication Code
I2C Inter-Integrated Circuit bus
LPC Low Pin Count bus
OTP One-Time Programmable Memory
PCB Printed Circuit Board
RAM Random Access Memory
RSA Rivest-Shamir-Adleman
SHS Secure Hash Standard
SP Special Publication
SPI Serial Peripheral Interface bus
TCG Trusted Computing Group
TIS TPM Interface Specification
TPM Trusted Platform Module
NPCT7xx TPM 2.0 rev 1.38 31 FIPS 140-2 Security Policy
13. References
[1] TCG Trusted Platform Module Library Specification Family 2.0 Revision 1.38
https://www.trustedcomputinggroup.org/tpm-library-specification
[2] TCG PC Client Specific Platform TPM Profile (PTP) Specification for TPM Family 2.0
Revision 01.03 v22
https://trustedcomputinggroup.org/pc-client-platform-tpm-profile-ptp-specification
[3] FIPS 140-2
http://csrc.nist.gov/groups/STM/cmvp/standards.html#02
Nuvoton provides comprehensive service and support.
For product information and technical assistance, contact the nearest Nuvoton center.
Important Notice
Nuvoton products are not designed, intended, authorized or warranted for use as components in systems or equipment intended for surgical
implantation, atomic energy control instruments, airplane or spaceship instruments, transportation instruments, traffic signal instruments,
combustion control instruments, or for other applications intended to support or sustain life. Furthermore, Nuvoton products are not intended
for applications wherein failure of Nuvoton products could result or lead to a situation wherein personal injury, death or severe property or
environmental damage could occur.
Nuvoton customers using or selling these products for use in such applications do so at their own risk and agree to fully indemnify Nuvoton
for any damages resulting from such improper use or sales.
CONTACT INFORMATION
For Nuvoton Sales Offices in your region, visit us at:
https://www.nuvoton.com/buy/worldwide-sales-offices/
For Cloud Computing Product Line information, contact:
CloudComputing@nuvoton.com
Please note that all data and specifications are subject to change without notice.
All trademarks of products and companies mentioned in this document belong to their respective owners.
© 2023 Nuvoton Technology Corporation. All rights reserved
www.nuvoton.com