140 SP 3187
140 SP 3187
140 SP 3187
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
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
The physical cryptographic boundary of the Module is the outer boundary of the chip
packaging.
Figure 4 shows a logical diagram of the Module:
Crypto
Host I nter face P r ocessor Code
SP I Bus Accelerator
(TIS Emulation)
Vol ati l e
GPIO Peripherals
Data
Physical Security 2
EMI/E MC 3
Self Tests 2
Design Assurance 2
Properties Description
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)
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
Properties Description
Self tests SHS / HMAC / AES / DRBG / KDF / RSA / ECDH / ECDSA
and f irmware integrity test
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
Generation of RSA Keys RSAKG 2048 Key Pair FIPS 186 -4 2591
Generation
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.
SHS Hash using SHA -1, SHA N/A Message FIPS 180 -4 3890
SHA2-256 and SHA2 -384 Digest
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
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.
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.
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.
Logical Physical
Description
Interface Ports
Control Input Control Input commands issued to the chip SPI Bus
Interf ace PP pin
Platform Reset
Power
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
Table 8. Roles
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.
4.2 Services
Table 9 lists all Module services, the affected CSPs, and the associated roles:
Self Tests The Module runs power -on self None CO,
tests automatically when powered OU,
on and on demand. DUP
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
TPM Sti r Used to add entropy to the random DRBG seeds CO,
Random bit generator OU
SHA-1, SHA2-256 , SHA2-384 FIPS 180 -4 KAT for each SHA type
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”.
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
If a conditional or power-on self test fails, the Module enters an error state where both data
output and cryptographic services are disabled.
9.2 Installation
To install the Module in the Approved Mode of operation, do the following:
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.
www.nuvoton.com