NPCT7xx TPM 2.

0
FIPS 140-2 Security Policy

Revision 1.1.0

©NUVOTON TECHNOLOGY CORP. – NON-PROPRIETARY SECURITY POLICY – MAY BE RE-DISTRIBUTED FREELY IN ITS COMPLETE, UNEDITED FORM
Revision Record

Revision Date Comments

1.0.7 May 16, 2018 First version for publication

1.0.8 February 20, 2019 Updated FW version (7.2.0.2)
1.0.9 March 26, 2019 Added both 7.2.0.1 and 7.2.0.2 FW versions
1.1.0 July 20, 2020 Updated SP800-56A revision to 3

NPCT7xx TPM 2.0 2 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 ............................................................................ 11
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
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 3 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 .....................................................................11
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 4 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 2.
The FIPS 140-2 conformance testing was performed on the following configurations of the
Nuvoton NPCT7xx TPM 2.0:
 Firmware version: 7.2.0.1, 7.2.0.2
 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 5 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:

P ower NON-VOL ATI L E

RNG
Managem ent Data

Crypto
Host I nter face P r ocessor Code
SP I Bus Accelerator
(TIS Emulation)

Vol ati l e
GPIO Peripherals
Data

P hysi c al P resence GPI0

Figure 4. TPM 2.0 Logical Block Diagram

NPCT7xx TPM 2.0 6 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 Securit y Level

Cryptographic Module Specif ication 2

Cryptographic Module Ports and Interf aces 2

Roles, Services and Authentication 2

Finite State Model 2

Physical Security 2

Operational Environment N/A

Cryptographic Key Management 2

EMI/E MC 3

Self Tests 2

Design Assurance 2

Mitigation of Other Attacks N/A

NPCT7xx TPM 2.0 7 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

Def inition Transient mode

Conf iguration This mode is the def ault mode when the TPM powers up. It
assumes a list of basic algorithms that is going to be used
f or basic TPM commands. The algorithms are: SHA1,
SHA256, SHA384, HMAC, KDFa, KDFe and AES. Th ese
algorithms are tested in _TPM_Init . Thus all the algorithms
f rom this list are tested bef ore the f irst command is
executed.

Services available All se rvices that do not use asymmetric cryptography (RSA,
ECDSA, ECDH)

Algorithms used SHS / HMAC / AES / DRBG / KDF

CSPs used Only asymmetric CSPs ca nnot be used (RSA and ECC keys)

Self tests SHS / HMAC / AES / DRBG / KDF and f irmware integrity test

NPCT7xx TPM 2.0 8 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

Def inition Full Approved mode of operation

Conf iguration There are three ways to move to Mode 2:

1. TPM2_Self Test(f ullTest = YES) command .
2. TPM2_Self Test(f ullTest = NO) command. If the
f irmware is in Mode 1, the command returns
TPM_RC_TEST ING. I mmediately af ter that , the
f irmware runs a self test equivalent to
TPM2_Self Test(f ullTest = YES). If a c ommand is
rece ived before the TPM has completed self test
execution, the TPM wi ll f irst complete Self Test 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 Initializatio n).

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 f irmware integrity test

NPCT7xx TPM 2.0 9 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 Key Use Standard CLV

Name Size
in Bits
AES Encryption and AES 128 256 Data FIPS 197, 4746
Decryption using OFB, CFB Encryption SP800 -38A
and CTR modes and
Decryption

RSA Signature Generation RSASA 2048 Digital FIPS 186 -4, 2591
and Verif ication using Signature PKCS#1 v2.1
RSASSA -PKCS1 -v1_5 and
RSASSA -PSS modes

RSA Decryption Operation RSADP 2048 Key SP800 -56B 1845

Primiti ve Transport
Primiti ve

RSA Encryption and RSAES 2048 Key SP800 -56B, Vendor

Decryption using RSAES - Transport PKCS#1 v2.1 Aff irmed
PKCS1 -v1_5 and
RSAES_OAEP modes

Generation of RSA Keys RSAKG 2048 Key Pair FIPS 186 -4 2591
Generation

Generation of symmetric CKG 1 128 Key SP800 -133 Vendor

keys and seeds when 256 Generation Aff irmed
generating private keys f or
asymmetric key algorithms

ECDSA Signature Generation ECDSA 256 Digital FIPS 186 -4 1183

and Verif ication using P -256 384 Signatures
and P-384 curves

Generation of ECDSA Keys ECCKG 256 Key Pair FIPS 186 -4 1183
384 Generation

1
The resulting symmetric key or generated seed is an unmodified output from the DRBG.

NPCT7xx TPM 2.0 10 FIPS 140-2 Security Policy

 Function Function Key Use Standard CLV
Name Size
in Bits
ECC Key Agreement using ECDH 256 Key SP800 -56A Vendor
Full Unif ied and One Pass 384 Agreement rev. 3 Aff irmed
DH schemes

H MAC HASH Message H MAC 160 Keyed FIPS 198 -1 3161

Authentication Code using 256 Message
SHA-1, SHA 2-256 and 384 Digest
SHA2-384

SHS Hash using SHA -1, SHA N/A Message FIPS 180 -4 3890
SHA2-256 and SHA2 -384 Digest

Deterministic Random Bit DRBG 256 DRBG SP800 -90A 1628

Generation (DRBG)
SHA2-256 based

Key Derivation Fun ction KDFa 160 256 Key SP800 -108 150
(KDF) using Counter mode Derivation
with H MAC

AES Key W rapping with AKW H 128 Key SP800 -38F 4746,
H MAC 256 W rapping 3161

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 Key Size Use

Name in Bits

NDRNG (entropy source) NDRBG N/A Entropy source f or the DRBG

NPCT7xx TPM 2.0 11 FIPS 140-2 Security Policy

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 f or digital signature verif ication (legacy) and any non -digital
signature application.
Not used for digital signature generation.

RSA Not permitted f or digital signature generation, key agreement and key
transport schemes with key size = 1024. Usage of 1024 bit keys
considered equivalent to plaintext or obf uscation v ersus cryptography.

XOR XOR obf uscation used as a hash -based stream cipher.

MGF1 RSAES_OAEP mask generation function equivalent to plaintext or

obf uscation versus cryptography.

ECDAA Used f or object creation and approved actions on keys that are non-
FIPS compliant. Not used f or cryptography. Usage considered plaintext
or obf uscation.

EC Schnorr Used f or signing and verif ying signatures that are non -FIPS compliant.
Not used for cryptography. Usage considered plaintext or obf uscation.

NPCT7xx TPM 2.0 12 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 Physical
Description
Interface Ports

Control Input Control Input commands issued to the chip SPI Bus
Interf ace PP pin
Platform Reset
Power

Status Output Status data output by the chip SPI Bus

Interf ace

Data Input Data provided to the chip as part of the SPI Bus
Interf ace data processing commands PP pin
Platform Reset

Data Output Data output by the chip a part of the data SPI Bus
Interf ace processing commands PP pin
Platform Reset

Power Interf ace Power interf ace of the chip Platform Reset
Power

The Module does not include a maintenance interface.

NPCT7xx TPM 2.0 13 FIPS 140-2 Security Policy

4. Roles, Authentication and Services
The two operation roles implemented by the Module are summarized in the table below.

Table 8. Roles

Role Ac ronym High Level Description

Crypto -Off icer CO Also known as “Object Administrator”; installs and

conf igures the Module , controls certif ication, chang es
authorization

Object User OU Uses the object to e xecutes services

Duplicate 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.

NPCT7xx TPM 2.0 14 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 settings (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 2 160 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.

NPCT7xx TPM 2.0 15 FIPS 140-2 Security Policy

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 None CO,

Status commands that returns the OU,
status of the Module, including DUP
success or f ailure of s elf tests.

Note: This service (e.g.,

TPM2_GetCapability) does not require
authentication

Self Tests The Module runs power -on self None CO,
tests automatically when powered OU,
on and on demand. DUP

Note: This service (e.g.,

TPM2_Selftest) does not require
authentication

Encrypt Used to encrypt data Encryption keys , CO,

Public storage keys , OU,
Platform keys DUP

Decrypt Used to decrypt data Encryptio n keys, CO,

Private storage keys, OU
Endorsement keys,
Platform keys

NPCT7xx TPM 2.0 16 FIPS 140-2 Security Policy

 Service Description CSP Role

Zeroize Used to zeroize (irreversibly Encryption keys, CO

destroy) Module's cryptographic Public verif ication keys,
keys and CSPs Public storage keys,
Private storage keys,
Identity keys,
H MAC keys,
DRBG seeds,
Endorsement keys,
Platform keys

MAC, Used to calculate and verif y MAC H MAC keys CO,

MAC Verif y f or data OU

Key Used to generate keys Encryption keys, CO,

Generate Public verif ication keys, OU
Public storage keys,
Private storage keys,
Identity keys,
Ephemeral keys,
H MAC keys,
DRBG seeds,
Endorsement keys ,
Platform keys

RSA Verif y Used to verif y data using RSA Public verif ication keys , CO,
Platform keys, OU
Firm ware Update key

RSA Sign Used to sign data using RSA Identity keys , CO,
Platform keys OU

ECDSA Used to verif y data using ECDSA Public verif ication keys , CO,
Verif y Platform keys OU

ECDSA Sign Used to sign data using ECDSA Identity keys , CO,
Platform keys OU

Key Import Used to import keys Encryption keys, CO

Public verif ication keys,
Public storage keys,
Private storage keys ,
Identity keys ,
H MAC keys,
Platform keys

NPCT7xx TPM 2.0 17 FIPS 140-2 Security Policy

 Service Description CSP Role

Key Used to export keys Encryption keys, CO,

Duplicate Public storage keys , DUP
Private storage keys ,
Ephemeral keys,
H MAC keys,
Platform keys

Key Used to derive a key Ephemeral Keys, CO,

Agreement Endorsement keys, OU
Platform keys

TPM Identity Used to authenticate TPM Identity Identity keys CO,

to other parties OU

TPM Used to prove to other parties that Endorsement keys CO,

Endorsement TPM i s a genuine TPM OU

TPM Get Used to generate random data DRBG seeds CO,

Random OU
Note: This service does not require
authentication .

TPM Sti r Used to add entropy to the random DRBG seeds CO,
Random bit generator OU

Note: This service does not require

authentication .

Install Installs Module H MAC keys, CO

Module Platform keys

Firm ware Updates Module’s f irmware. Firm ware Update key CO

Update Requires Platf orm Authorization.

NPCT7xx TPM 2.0 18 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 o r Func. Usage Service - Access

CSP
Encryption AES Used to : Encrypt - E
keys AKW H - W rap keys: f or import/duplication, for Decrypt - E
KDFa wrapping keys stored outside the TPM Zeroize - W
DRBG and for session keys (audit or Key Import - E, W
CKG parameter encryption) Key Gen erate - W
- Encrypt/decrypt input/output Key Duplicate - E
parameters
- Decrypt credentials
Keys generated using DRBG, derived
using KDFa or securely transported
using public/private storage keys.
Public RSASA Used to verif y signatures on data , as Zeroize - W
verif ication RSAKG service f or external application, or as Key Gen erate - W
keys ECDSA part of Authorization Policy verif ication. RSA Verif y - E
ECCKG Keys may be generated in the TPM (as ECDSA Verif y - E
DRBG part of Identity key generation) or Key Import - W
loaded f rom external source.
Public RSAES Used to transport keys generated Encrypt - E
storage keys RSAKG externally or generated by TPM. Zeroize - W
KDFa Keys may be generated in the TPM (as Key Gen erate - W
DRBG part of Private storage key generation) Key Import - W
or imported f rom external source. Key Duplicate - E

Private RSAES Used to transport keys generated Decrypt - E

storage keys RSAKG externally or generated by TPM. Zeroize - W
KDFa Keys may be generated in the TPM Key Gen erate - W
AKW H (stored encapsulated or wrapped Key Import - E, W
DRBG outside the TPM) or imported f rom Key Duplicate - E
external source.

NPCT7xx TPM 2.0 19 FIPS 140-2 Security Policy

 Key o r Func. Usage Service - Access
CSP
Identity keys RSASA Authorization tokens used to prove Zeroize - W
RSAKG TPM identity to other parties . Key Gen erate - W
ECDSA Used to sign information generated or RSA Sign - E
ECCKG controlled by the TPM. ECDSA Sign - E
KDFa Keys may be generated in the TPM Key Import - W
AKW H (stored encapsulated or wrapped TPM Identity - E
DRBG outside the TPM) or imported f rom
external source.
Ephemeral ECDH Used to exchange secrets to establish Key Generate - W
keys ECCKG a symmetric key , using One-Pass Key Duplicate - E
KDFa Diff ie -Hellman . Key Agreement - E
AKW H Used f or:
DRBG - Encryption of authorization session
salt
- Secret sharing f or duplication
- Secret sharing f or credentials
Keys may be generated in the TPM
(stored encapsulated or wrapped
outside the TPM) or imported f rom
external source.
H MAC keys H MAC Used to calculate and verif y MAC codes Zeroize - W
AKW H f or data . MAC, MAC Ver if y - E
DRBG Used f or: Key Gen erate - W
CKG - Ensuring associat ion of credential Key Import - W
with a loaded object Key Duplicate - E
- Access or usage authorization Install Module - W , E
- Symmetric s igning
- Audit
Keys may be generated in the TPM
(stored encapsulated or wrapped
outside the TPM) or imported f rom
external source.
DRBG seeds DRBG Used to seed the DRBG , generated by Zeroize - W
NDRBG the NDRBG. Key Gen erate - E
TPM Get Random - E
TPM Sti r Random - W

Endorsement RSAES Authorization tokens used to prove to Decrypt - E

keys RSAKG the external parties that TPM is a Zeroize - W
ECDH genuine TPM. Key Generate - W
ECCKG Keys may be generated in the TPM or Key Agreement - E
KDFa installed during TPM manuf acturing. TPM Endorsement - E
DRBG

NPCT7xx TPM 2.0 20 FIPS 140-2 Security Policy

 Key o r Func. Usage Service - Access
CSP
Platform keys AES Keys used by the Platform Firmwa re . Encrypt - E
RSAES Decrypt - E
RSASA Zeroize - W
RSAKG Key Gen erate - W
ECDH RSA Verif y - E
ECDSA RSA Sign - E
ECCKG ECDSA Verif y - E
KDFa ECDSA Sign - E
DRBG Key Import - E
Key Duplicate - E
Key Agreement - E
Install Module - W , E
Firm ware RSASA Used to verif y signature on f irmware RSA Verif y - E
Update key updates. Firm ware update - E
Key installed at the module
manuf acturing .

NPCT7xx TPM 2.0 21 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 T est T ype

Firm ware integrity MAC using a 128 -bit error detection code

H MAC 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 f rom SP800 -38A

KDFa SP800 -108 KAT

KDFe 2 (f or ECDH) SP800 -56A rev. 3 KAT

DRBG SP800 -90A KAT (DRBG Generate, Reseed and

Instantiate )

2
SP800-56A rev. 3, section 6.2.2.2. The KDF used is the “One-Step Key Derivation” according to SP800-56C,
section 4”.

NPCT7xx TPM 2.0 22 FIPS 140-2 Security Policy

6.2 Conditional Self Tests
The Module implements the following conditional tests:

Table 12. Conditional Self Tests

Cryptography Condition T est T ype

Function
POST POST All tests listed in Table 11

ECDSA TPM2_Self Test(f ullTest = FIPS 186 -4 KAT

sign / verif y YES) in transition to
Approved Mode 2

ECDH TPM2_Self Test(f ullTest = SP800 -56A rev. 3 KAT

YES) in transition to
Approved Mode 2

RSA TPM2_Self Test(f ullTest = PKCS#1v2.1, FIPS 186 -4 KAT

sign / verif y YES) in transition to
Approved Mode 2

RSA key Key Generation Conditional pair -wise consistency

generation check f or RSA public -private key
pairs each time an RSA key pair is
generated, using FIPS 186 -4

ECC key Key Generation Conditional pair -wise consistency

generation check f or ECDSA public -private key
pairs each time an ECDSA key pair
is generated, using FIPS 186 -4

Firm ware Load Field Upgrade Firm ware update test during the
Test f irmware update. The digital
signature is verif ied on t he
f irmware 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 23 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 2. 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.

NPCT7xx TPM 2.0 24 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 25 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.

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, either use a high entropy authorization
value (> 160 bit random number) or enable DA protection in the object attributes when
created.

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 section 13.1 in reference [1]).
When Object is created, set the attribute “encryptedDuplication” in the object.

NPCT7xx TPM 2.0 26 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 27 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 28 FIPS 140-2 Security Policy

11. Duplicate Guidance
The Duplicate role shall follow the guidance in section 9.4.

NPCT7xx TPM 2.0 29 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 30 FIPS 140-2 Security Policy

13. References
[1] TCG Trusted Platform Module Library Specification Family 2.0 Revision 1.16
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

NPCT7xx TPM 2.0 31 FIPS 140-2 Security Policy

 Nuvoton provides comprehensive service and support.
For product information and technical assistance, contact the nearest Nuvoton center.

Headquarters Nuvoton Technology Nuvoton Technology (Shanghai)

Corporation America Ltd.
No. 4, Creation Rd. 3
Science-Based Industrial Park 2727 North First Street 27F, 2299 Yan An W. Rd.
Hsinchu, Taiwan, R.O.C San Jose, CA 95134, U.S.A. Shanghai, 200336 China
TEL: 886-3-5770066 TEL: 1-408-9436666 TEL: 86-21-62365999
FAX: 886-3-5665577 FAX: 1-408-5441798 FAX: 86-21-62365998
http://www.nuvoton.com.tw (Ch.)
http://www.nuvoton.com (Eng.)

Taipei Office Winbond Electronics Nuvoton Technology (H.K.) Ltd.

Corporation Japan
1F, No.192, Jingye 1st Rd Unit 9-15, 22F, Millennium City 2
Zhongshan District, Taipei, 104 NO. 2 Ueno-Bldg., 7-18, 3-chome 378 Kwun Tong Rd
Taiwan, R.O.C. Shinyokohama Kohoku-ku Kowloon, Hong Kong
TEL: 886-2-2658-8066 Yokohama, 222-0033 TEL: 852-27513100
FAX: 886-2-8751-3579 TEL: 81-45-4781881 FAX: 852-27552064
FAX: 81-45-4781800

For Advanced PC Product Line information contact: APC.Support@nuvoton.com

© 2020 Nuvoton Technology Corporation. All rights reserved

www.nuvoton.com