Ref: SP_HiCOS_PKI_V2_on_V8.1 Version 1.3 Revision Date: May 23, 2019
© Chunghwa Telecom Co., Ltd. and IDEMIA All rights reserved.
This document may be freely reproduced and distributed whole and intact including this copyright notice.
HiCOS PKI Applet V2.0 on
IDEMIA ID-One Cosmo V8.1-R2
FIPS 140-2 Non-Proprietary Security Policy
May 23, 2019
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 2 of 18
1. Introduction..................................................................................................................................................... 5
1.1 Functional Overview ........................................................................................................................................ 5
1.2 Versions, Configurations and Modes of operation.............................................................................................. 5
1.3 Hardware and Physical Cryptographic Boundary ................................................................................................ 6
1.4 Firmware and Logical Cryptographic Boundary .................................................................................................. 7
2. Cryptographic Functionality.......................................................................................................................... 9
2.1 Critical Security Parameters and Public Keys.................................................................................................... 11
3. Roles, Authentication and Services ........................................................................................................... 12
3.1 GP Secure Channel Protocol Authentication Method 03 ................................................................................... 12
3.2 PKI Applet Symmetric Key Authentication Method........................................................................................... 13
3.3 PKI Applet Secret Value Authentication Method .............................................................................................. 13
3.4 Services ........................................................................................................................................................ 13
4. Self – tests..................................................................................................................................................... 17
4.1 Power - On Self - tests.................................................................................................................................... 17
4.2 Conditional self - tests.................................................................................................................................... 17
5. Physical Security Policy............................................................................................................................... 18
6. Operational Environment............................................................................................................................. 18
7. Electromagnetic interference and compatibility (EMI/EMC) .................................................................... 18
8. Mitigation of Other Attacks Policy.............................................................................................................. 18
9. Security Rules and Guidance...................................................................................................................... 18
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 3 of 18
References
Reference Full Specification Name
[ISO 7816] ISO/IEC 7816‐1: 2011 Identification cards ‐‐ Integrated circuit(s) cards with contacts ‐‐ Part 1:
Physical characteristics
ISO/IEC 7816‐2:2007 Identification cards ‐‐ Integrated circuit cards ‐‐ Part 2: Cards with contacts ‐‐
Dimensions and location of the contacts
ISO/IEC 7816‐3:2006 Identification cards ‐‐ Integrated circuit cards ‐‐ Part 3: Cards with contacts ‐‐ Electrical
interface and transmission protocols
ISO/IEC 7816‐4:2013 Identification cards ‐‐ Integrated circuit cards ‐‐ Part 4: Organization, security and
commands for interchange
ISO/IEC 7816‐5:2004 Identification cards ‐‐ Integrated circuit cards ‐‐ Part 5: Registration of application
providers
ISO/IEC 7816‐6:2004 Identification cards ‐‐ Integrated circuit cards ‐‐ Part 6: Interindustry data elements for
interchange
ISO/IEC 7816‐8:2004 Identification cards ‐‐ Integrated circuit cards ‐‐ Part 8: Commands for security
operations
ISO/IEC 7816‐9:2004 Identification cards ‐‐ Integrated circuit cards ‐‐ Part 9: Commands for card
management
ISO/IEC 7816‐11:2004 Identification cards ‐‐ Integrated circuit cards ‐‐ Part 11: Personal verification
through biometric methods
ISO/IEC 24787: 2010 Information technology ‐‐ Identification cards ‐‐ On‐card biometric comparison
[JavaCard] Java Card 3.0.4 Classic ‐ Runtime Environment (JCRE) Specifications
Java Card 3.0.4 Classic ‐ Virtual Machine (JCVM) Specifications
Java Card 3.0.4 Classic ‐ Application Programming Interface (API)
Published by Sun Microsystems, May 2011
[GlobalPlatform] GlobalPlatform Card Specification 2.2.1 ‐ January 2011,
GlobalPlatform Card Specification – Amendment E – Security Upgrade for card content management –
Public Release November 2011 v1.0
GlobalPlatform Card Basic ID Configuration ‐ Version 1.0 ‐ December 2011
GlobalPlatform Card Technology Card Specification – ISO Framework Version 0.9.0.18 Public Review July
2013
GlobalPlatform Consortium: http://www.globalplatform.org
[PKCS#1] PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, June 14, 2002
[ANS X9.31] American Bankers Association, Digital Signatures Using Reversible Public Key Cryptography for the Financial
Services Industry (rDSA), ANSI X9.31‐1998 ‐ Appendix A.2.4.
[FIPS140‐2] NIST, Security Requirements for Cryptographic Modules, May 25, 2001
[IG] NIST, Implementation Guidance for FIPS PUB 140‐2 and the Cryptographic Module Validation Program,
last updated 07 May 2019.
[FIPS113] NIST, Computer Data Authentication, FIPS Publication 113, 30 May 1985.
[FIPS197] NIST, Advanced Encryption Standard (AES), FIPS Publication 197, November 26, 2001.
[FIPS 186‐4] NIST, Digital Signature Standard (DSS), FIPS Publication 186‐4, July, 2013
[FIPS 180‐4] NIST, Secure Hash Standard, FIPS Publication 180‐4, March 2012
[SP800‐38F] NIST, Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping, December 2012
[SP 800‐56A] NIST Special Publication 800‐56A, Recommendation for Pair‐Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography, March 2007
[SP 800‐67] NIST Special Publication 800‐67, Recommendation for the Triple Data Encryption Algorithm (TDEA)
Block Cipher, Revision 2, July 2017
[SP800‐108] NIST, Recommendation for Key Derivation Using Pseudorandom Functions (Revised), October 2009
[SP800‐131A] Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key
Lengths, Revision 1, November 2015
Table 1 – References
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 4 of 18
Acronyms and definitions
Acronym Definition
AIS 31 A German acronym referring to standard for functionality and evaluation of random number
generation
ADF Application Dedicated File
APDU Application Protocol Data Unit, see [ISO 7816]
API Application Programming Interface
CHV Card Holder Verification
CM Card Manager, see [GlobalPlatform]
CRT Chinese Remainder Theorem
CSP Critical Security Parameter, see [FIPS 140‐2]
DAP Data Authentication Pattern, see [GlobalPlatform]
DPA Differential Power Analysis
EAC Extended Access Control
GP Global Platform
IC Integrated Circuit
ISD Issuer Security Domain, see [GlobalPlatform]
KAT Known Answer Test
NVM Non‐Volatile Memory (e.g. EEPROM, Flash)
OP Open Platform (predecessor to Global Platform)
PCT Pairwise Consistency Test
PKI Public Key Infrastructure
SAC Supplemental Access Control
SCP Secure Channel Protocol, see [GlobalPlatform]
STD Standard, as in Standard (non‐CRT) RSA
SPA Simple Power Analysis
TPDU Transport Protocol Data Unit, see [ISO 7816]
Table 2 – Acronyms and Definitions
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 5 of 18
1. Introduction
This document defines the Security Policy for the Chunghwa Telecom Co., Ltd. HiCOS PKI Applet v2.0 on
IDEMIA ID-One Cosmo v8.1-R2 cryptographic module. The module, a single chip embodiment validated to FIPS
140-2 Overall Security Level 2, is the combination of the HiCOS PKI Applet (denoted PKI Applet below) running
on and bound to the Oberthur Cosmo v8.1 platform, Cert. #2986 module.
The platform provides an operational environment for the PKI Applet. The cryptographic algorithms, the
random number generators, the asymmetric key generation, and the self-tests are implemented by the
platform except pairwise consistency tests. The key storage and the card lifecycle are managed by platform.
The code for this functionality is contained in the platform ROM. However, the factory configuration of the
module constrains the module to the set of services provided by the platform’s Card Manager (implementing a
standard set of GlobalPlatform services) and the PKI Applet. As such, some functionality and options present
on the platform are not usable on this module such as the PIV applet which is deactivated in this module.
Unusable functionality is not discussed further in this document.
1.1 Functional Overview
The PKI Applet is a Javacard applet that provides security for stored user data and credentials and an easy to
use interface to PKI services (e.g., for strong authentication, encryption and digital signatures).
The FIPS 140‐2 security levels for the module are as follows:
Security Requirement Security Level
Cryptographic Module Specification 2
Cryptographic Module Ports and Interfaces 2
Roles, Services, and Authentication 3
Finite State Model 2
Physical Security 4
Operational Environment N/A
Cryptographic Key Management 2
EMI/EMC 3
Self-Tests 2
Design Assurance 3
Mitigation of other attacks 2
Table 3 – Security Level of Requirements
1.2 Versions, Configurations and Modes of operation
Hardware version: ‘30’
Firmware version: ‘5F02’-‘090191’ and HiCOS PKI Applet V2.0 ‘03020206’
The module is available in three (3) communication package configurations:
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 6 of 18
• Contact Only (Contactless ports disabled)
• Contactless Only (Contact ports disabled)
• Dual Interface (Contactless and contact ports enabled)
The module is always in the Approved mode. The explicit indicator of the Approved mode of operation is
obtained by use of the Module Info (Unauthenticated) and the PKI Applet Info (Unauthenticated) services,
specifically the commands and tags shown next.
Command and associated elements Expected Response
GET DATA (tag ‘DF52’) with Card Manager selected (Value of FIPS Mode data objects
(tag ‘05’)
‘01’
GET DATA (tag ‘0105’) with PKI Applet selected ‘03020206’
GET DATA (tag ‘FE00’) to retrieve the value of FIPS mode data of the applet ‘01’ (in FIPS mode)
Table 4- Approved Mode Indicator
1.3 Hardware and Physical Cryptographic Boundary
The module is designed to be embedded into a plastic card body, with a contact plate and/or contactless
antenna connections, or in a USB token or other standard IC packaging, such as SOIC, QFN or MicroSD.
The physical form of the module is depicted in Figure 1. The cryptographic boundary of the module is the
surface and edges of the die and associated bond pads, shown as circles in the figure.
Figure 1 –Physical Form
The contactless ports (if supported) of the module require connection to an antenna. The module relies on
[ISO7816] and [ISO14443] card readers and antenna connections as input/output devices.
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 7 of 18
Port Description Logical Interface Type
VCC, GND ISO 7816: Supply voltage Power (not available in contactless‐only configurations)
RST ISO 7816: Reset Control in (not available in contactless‐only configurations)
CLK ISO 7816: Clock Control in (not available in contactless‐only configurations)
I/O ISO 7816: Input/ Output Control in, Data in, Data out, Status out (not available in
contactless‐only configurations)
LA, LB ISO 14443: Antenna Power, Control in, Data in, Data out, Status out
(Not available in Contact‐only configurations)
Table 5 – Ports and Interfaces
1.4 Firmware and Logical Cryptographic Boundary
Figure 2 depicts the module operational environment.
Figure 2 ‐ Module Block Diagram
(Cryptographic Boundary Outlined in Red)
Hardware
Power Mgmt
Clock
Mgmt
Sensors
Reset Mgmt
RAM
MMU
CPU
Triple-DES
Engine
ECC Engine
True (HW)
RNG
CRC
Timers
ISO 7816
(UART)
ISO 14443
(RF)
Vcc, GND
CLK
RST
I/O (Contact)
LA/LB (RF)
Firmware Platform
Global Platform OS
JavaCard API
Global Platform API
CHT HiCOS PKI Applet
Issuer Security
Domain (Card
Manager)
NVM
ROM
AES Engine
IDEMIA API
RSA Engine
Biometric/OCC API
Security Domain
Verifier
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 8 of 18
Section 3 describes applet functionality in greater detail. The Java Card and Global Platform APIs are internal
interfaces available only to applets. Only applet services are available at the card edge (the interfaces that
cross the cryptographic boundary). In the figure above, the Security Domain Verifier prevents loading an
unauthorized (unsigned) code package into the module and does not provide separate services.
All code is executed from ROM and NVM.
The chip family provides accelerators for AES, Triple‐DES, RSA, ECC, CRC and an AIS‐31 P2 class tested NDRNG
also named True (HW) RNG. The communications options for contact and contactless configurations are
present in the physical circuitry of all members of the processor family but are selectively enabled during
module manufacturing.
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 9 of 18
2. Cryptographic Functionality
The module implements the Approved and Non-Approved but Allowed cryptographic functions implemented
by Cert. #2986 module and listed in Table 6 and Table 7 below:
CAVP # Algorithm Standard Mode /
Method
Strength Use
AES
Cert. # 4107
AES [FIPS 197],
[SP800‐38A]
CBC, ECB 128
192
256
Data Encryption/
Decryption
AES
Cert. #4108
CMAC [SP800‐38B] CMAC 128
192
256
Message
Authentication;
SP 800‐108 KDF
(Uses AES Cert.
#4107)
AES
Cert. #4109
Key Wrap [SP800‐38F] KW 128
192
256
This algorithm is
only used for the
self-test
CKG
Vendor Affirmed
Key
generation
[SP800-133]
[IG D.12]
SP800-133
section 6.1 and
7.4
N/A Asymmetric key
generation and
symmetric key
derivation
CVL
Cert. #921
RSADP [SP 800‐56B] RSA key
decryption
primitive
RSA 2048
Key
Key decryption
CVL
Cert. #953
ECC CDH [SP 800‐56A] ECC CDH
Primitive
P‐224
P‐256
P‐384
P‐521
Shared Secret
Computation
CVL
Cert. #954
RSASP1 [FIPS 186]
[SP 800‐56B]
RSA signature
generation
primitive
RSA 2048 Signature
generation primitive
(off card hash).
DRBG
Cert. #1234
DRBG [SP 800‐90A] CTR 128 Deterministic
Random Bit
Generation
ECDSA
Cert. #933
ECDSA [FIPS 186‐4] P‐224
P‐256
P‐384
P‐521
Digital Signature
Generation,
Verification and ECC
Key
Generation.
KBKDF
Cert. #106
KBKDF [SP 800‐108] AES CMAC 128
192
256
Deriving keys from
existing keys,
(AES Cert. #4108)
KTS
Cert. # 4107
Cert. # 4108
AES+AES
CMAC
combination
[SP800‐38F] AES/CMAC 128
192
256
SP 800‐38F §3.1 ¶3
Key transport
(Uses AES Cert.
#4107 and #4108)
RSA
Cert. #2252
RSA [FIPS 186‐4] PKCS1_V1_5
PSS
RSA 2048 This algorithm is
only used for the
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 10 of 18
CAVP # Algorithm Standard Mode /
Method
Strength Use
KeyGen self-test
RSA
Cert. #2253
RSA CRT [FIPS 186‐4] PKCS1_V1_5
PSS KeyGen
RSA 2048 RSA key generation,
digital signature
generation and
verification.
SHA-3
Cert. #6
SHA-3 [FIPS 202]
SHA3-224
SHA3-256
SHA3-384
SHA3-512
This algorithm is
only used for the
self-test
SHS
Cert. #3379
SHS [FIPS 180‐4] SHA‐256 Message Digest
SHS
Cert. #3380
SHS [FIPS 180‐4] SHA‐384
SHA‐512
Message Digest
Triple‐DES
Cert. #22451
3DES [SP 800‐67] TCBC, TECB 3‐Key Data Encryption/
Decryption
Table 6 – Approved Cryptographic Functions
The CAVP certificates associated with Cert. #2986 module include other algorithms, modes, and curves or key
sizes that have been CAVP validated but are not available in this module. Only the algorithms, modes, and
curves or key sizes shown in Table 6 are available in this module.
Algorithm Description
NDRNG NDRNG used to seed the FIPS approved DRBG. The NDRNG provides a minimum of 264 bits of
entropy as seeding material to the approved DRBG.
Table 7 – Non -Approved but Allowed Cryptographic Functions
1
See security rule in section 9
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 11 of 18
2.1 Critical Security Parameters and Public Keys
All CSPs used by the module are described in this section. All usage of these CSPs by the module is described in
the services detailed in Section 3. In the tables below, the OS prefix denotes operating system, the SD prefix
denotes the Global Platform Security Domain, and the PKI prefix denotes a PKI Application CSP.
All CSPs, (keys and PINs) except OS‐MKEK are store encrypted by OS‐MKEK with a corresponding checksum.
CSP Description / Usage
OS-DRBG-SEED Entropy input provided by the NDRNG, used to seed the Approved DRBG.
OS-DRBG-STATE The current AES‐128 CTR_DRBG state.
OS-MKEK Triple‐DES (3‐Key) Key Encryption Key used for encrypted storage of CSPs.
SD-KENC AES (128-bit, 192-bit, 256-bit) Master key used to generate SD‐SENC.
SD-KMAC AES (128-bit, 192-bit, 256-bit) Master key used to generate SD‐SMAC.
SD-KDEK AES (128-bit, 192-bit, 256-bit) Sensitive data decryption key used to decrypt CSPs.
SD-SENC
AES (128-bit, 192-bit, 256-bit) Session encryption key used to encrypt / decrypt secure
channel data.
SD-SMAC
AES (128-bit, 192-bit, 256-bit) Session MAC key used to verify inbound secure channel data
integrity.
SD-SRMAC
AES (128-bit, 192-bit, 256-bit) Session MAC key used to generate response secure channel
data MAC.
Table 8 – OS Critical Security Parameters
CSP Description / Usage
PKI-KXAUTH Triple‐DES (3‐Key) or AES (128-bit, 192-bit, 256-bit) PKI applet External Authentication key.
PKI-KIAUTH Triple‐DES (3‐Key) or AES (128-bit, 192-bit, 256-bit) PKI applet Internal Authentication key.
PKI-KRSA-PRI RSA (2048-bit) PKI applet signature generation private keys.
PKI-KECC-PRI
ECC (P‐224, P‐256, P‐384, P-521) PKI applet ECDSA signature generation private keys and ECC
CDH private keys.
PKI-AUTH
10-byte authentication datum, with 2 instances used for card holder PIN verification and pin
unblocking.
Shared-
Secret
Shared Secret generated with ECC CDH, the shared secret is not used by the module
Table 9 – PKI Applet Critical Security Parameters
Public Keys Description / Usage
DAP-PUB RSA 2048 new firmware signature verification key.
PKI-KRSA-PUB
RSA (2048-bit) public keys held in the module for retrieval by external users through the PKI
applet.
PKI-KECC-PUB
ECC (P‐224, P‐256, P‐384, P‐521) public keys held in the module for retrieval by external users
through the PKI applet. These are used for ECDSA and ECC CDH.
Table 10 – Public Keys
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 12 of 18
3. Roles, Authentication and Services
The module:
• Does not support a maintenance role.
• Clears previous authentications on power cycle.
• Supports Global Platform SCP logical channels, allowing concurrent operators in a limited fashion.
• Implements security conditions which must be satisfied to access specific features, not necessarily as a
separate role.
Authentication of each operator and their access to roles and services is as described below. Only one operator
at a time is permitted on a channel. Applet de-selection (including ISD/Card Manager), card reset or power
down terminates the current authentication; re-authentication is required after any of these events for access
to authenticated services. Authentication data is encrypted during entry (by SD-KDEK), and is only accessible by
authenticated services.
Table 12 lists all operator roles supported by the module.
Role ID Role Description
CO Cryptographic Officer - role that manages module configuration, including issuance and
management of module data via the ISD. Authenticated as described in GP Secure Channel
Protocol Authentication 03 below.
AA Application Administrator - a role that manages PKI application-related content and configuration.
Authenticated using the GP Secure Channel Protocol 03 Authentication method or PKI Applet
Symmetric Key Authentication method.
User Card Holder – The human user of the module authenticated by PKI Applet Secret Value
Authentication method.
Table 11 – Roles Supported by the Module
3.1 GP Secure Channel Protocol Authentication Method 03
The GP Secure Channel Protocol Authentication method is provided by the GP Secure Channel service, the PKI
Applet Secure Channel service. These services each invoke the same underlying library calls, but from the Card
Manager and PKI Applet, respectively.
The SD-KENC and SD‐KMAC keys are used to derive the SD‐SENC and SD‐SMAC keys, respectively. The SD‐SENC
key is used to create a cryptogram; the external entity participating in the mutual authentication also creates
this cryptogram. Each participant compares the received cryptogram to the calculated cryptogram and if this
succeeds, the two participants are mutually authenticated (the external entity is authenticated to the module
in the CO role).
The probability that a random attempt will succeed using this authentication method is:
• 1/2^128 = 2.9E‐39 (for any of AES‐128/192/256 SD‐KENC/SD‐SENC, assuming a 128‐bit block)
The module enforces a “slowdown mechanism” that increases the response time between two authentications
attempts following a failed authentication, such that no more than 9 attempts are possible in a one minute
period. The probability that a random attempt will succeed over a one minute interval is:
• 9 /2^128 = 2.6E‐38 (for any of AES‐128/192/256 SD‐KENC/SD‐SENC, assuming a 128‐bit block)
GP Secure Channel Protocol establishment provides mutual authentication service as well as establishment of
a secure channel to protect confidentiality and integrity of the transmitted data.
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 13 of 18
3.2 PKI Applet Symmetric Key Authentication Method
The PKI Applet Symmetric Key Authentication method is provided by the PKI Applet Entity authentication with
symmetric key service. The external entity obtains a 16-byte challenge from the module, encrypts the challenge
and sends the cryptogram to the module. The module decrypts the cryptogram, and the external entity is
authenticated if the decrypted value matches the challenge. This method is used by the PKI Applet
Authentication and Administrator Authentication services. The strength of authentication using this method is
dependent on the algorithm, key size and challenge size used: the minimum strength key used for this method
is 3-Key Triple-DES, using 8 bytes (a single Triple - DES block).
The probability that a random attempt will succeed using this authentication method is:
• 1/2^64 = 5.4E-20
The maximum number of consecutive failed authentication attempts is 5, so the probability that a random
attempt will succeed over a one minute interval is:
• 5/2^64 = 2.7E-19
3.3 PKI Applet Secret Value Authentication Method
The PKI Applet Secret Value Authentication method is provided by the PKI Applet Entity authentication with
password service. The external entity submits an identifier and corresponding secret value. The module
compares all 10 bytes to the appropriate stored reference instance (e.g., Cardholder PIN). The enforcement of
minimum number of characters before padding is not the same as a fixed minimum length for the secret. For
example, a minimum of 6 characters means secrets can be created from 6 to 10 characters, determined by the
user.
The worst case scenario permitted by the module is a minimum length of 6 characters allowing only numeric
ASCII characters. The character space for the first 6 bytes in this scenario is 10 (the values ‘30’ through ‘39’ are
permitted) and in the last 4 characters is 11 (the values ‘30’ through ‘39’ and ‘FF’ are permitted). The
probability that a random attempt will succeed using this authentication method is:
• 1/(10^6 *11^4) = 6.3E-11
The applet implements a failed attempt counter, blocking after 3 failed attempts. The probability that a
random attempt will succeed over a one minute interval is:
• 3/(10^6 * 11^4) = 2.0E-10
3.4 Services
All services implemented by the module are listed in the tables below.
Service Description
Card Manager
Context Select an application or manage logical channels.
Module Info (Unauthenticated) Read unprivileged data objects, e.g. module configuration or status information.
Module Reset Power cycle or reset the module. Includes Power‐On Self‐Test.
PKI Applet
PKI Applet Info (Unauthenticated) Read unprivileged PKI applet data objects.
Module authentication with
symmetric key
Authenticate the module to the terminal
Get public key (Unauthenticated) Retrieve a specified public key which is not protected with access control right.
Table 12 – Unauthenticated Services
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 14 of 18
Service Description CO AA User
Platform
GP Secure Channel Establish and use a Global Platform secure communications
channel.
X
Lifecycle Modify the card or applet life cycle status. X
Manage Content Load and install application packages and associated keys
and data.
X
Module Info (Authenticated) Read module configuration or status information (privileged
data objects).
X
PKI Applet
PKI Applet GP Secure Channel Establish and use a PKI Applet GP secure communications
channel.
X X
PKI Applet preparation Manage PKI applet authentication data and PKI Applet
lifecycle.
X
Entity authentication with
symmetric key
Authenticate AA role to the module. X
Entity authentication with
password
Authenticate User role to the module (PIN verification). X
Change PIN Allows the User to change their PIN. X
Unblock PIN Mechanism to reset the retry counter when the card is
blocked after too many failed PIN verify attempts.
X
File Content Manage Read or update binary data stored in the applets ISO 7816
file system.
X X
Generate asymmetric key pair Generate an RSA or EC key pair. X X
Get public key (Authenticated) Retrieve a specified public key protected with access
control right
X X
Digital Signature Sign provided data with the specified key. X X
Shared Secret computation Generate a shared secret with ECC CDH algorithm X X
Key Management Update PKI applet keys. X
Table 13 – Authenticated Services
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 15 of 18
Service
CSP PK
OS‐DRBG‐SEED
OS‐DRBG‐STATE
OS‐MKEK
SD‐KENC
SD‐KMAC
SD‐KDEK
SD‐SENC
SD‐SMAC
SD‐SRMAC
PKI-KXAUTH
PKI-KIAUTH
PKI-KRSA-PRI
PKI-KECC-PRI
PKI-AUTH
SHARED-SECRET
DAP_PUB
PKI-KECC-PUB
PKI-KRSA-PUB
Unauthenticated Services
Context -- -- -- -- -- -- E’ E’ E’ -- -- -- -- -- -- -- -- --
Module Info (Unauthenticated) -- -- -- -- -- -- E’ E’ E’ -- -- -- -- -- -- -- -- --
Module Reset
G
E
S
Z
G
S
Z
-- -- -- -- Z Z Z Z Z -- -- -- Z -- -- --
PKI Applet Info
(Unauthenticated)
-- -- -- -- -- -- E’ E’ -- -- -- -- -- -- -- -- -- --
Module authentication with
symmetric key
-- -- -- -- -- -- E’ E’ -- -- E’ -- -- -- -- -- -- --
Get public key
(Unauthenticated)
-- -- E -- -- -- -- E’ E’ -- -- -- -- -- -- -- O O
Platform Services
GP Secure Channel -- E E E E E
G
E
G
E
G
E
-- -- -- -- -- -- -- -- --
Lifecycle Z Z Z Z Z Z E E E Z Z Z Z Z -- Z Z Z
Manage Content -- -- -- IS IS IS E E E -- -- -- -- -- --
-- --
--
Module Info (Authenticated) -- -- -- -- -- -- E E E -- -- -- -- -- -- -- -- --
PKI Applet Services
PKI Applet GP Secure Channel --
E
S
E E E --
G
E
G
E
G -- -- -- -- -- -- -- -- --
PKI Applet preparation -- -- E -- -- E E E -- IS IS -- -- IS -- -- -- --
Entity authentication with
symmetric key
-- -- E -- -- -- E E -- E -- -- -- -- -- -- -- --
Entity authentication with
password
-- -- -- -- -- -- E E -- -- -- -- -- E -- -- -- --
Change PIN -- -- -- -- -- -- E E -- -- -- -- -- IS -- -- -- --
Unblock PIN -- -- -- -- -- -- E E -- -- -- -- -- IS -- -- -- --
File Content Manage -- -- -- -- -- -- E E -- -- -- -- -- -- -- -- -- --
Generate asymmetric key pair --
E
S
E -- -- -- E E -- -- --
G
S
G
S
-- -- --
G
S
G
S
Get public key (Authenticated) -- -- E -- -- -- -- E E -- -- -- -- -- -- -- O O
Digital Signature --
E
S
E -- -- -- E E -- -- -- E E -- -- -- E E
Shared Secret computation --
E
S
E -- -- -- E E -- -- -- -- E --
G
O
-- E --
Key Management -- -- E -- -- -- E E -- IS IS IS IS -- -- -- IS IS
Table 14 – Access to CSPs and Public Keys by Service
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 16 of 18
Table 14 is organized to correspond to the set of unauthenticated services, then authenticated services.
• G = Generate: The module generates the CSP.
• I= Input: The CSP is input in the module.
• S = Store: The module stores the CSP.
• O = Output: the CSP is output from the module.
• E = Execute: The module executes using the CSP.
• E’ = Execute: The module will execute the CSP if a Secure Channel is opened.
• Z = Zeroize: The module zeroizes the CSP. For the Context service, SD session keys are destroyed on
applet deselect (channel closure)
• - - = Not accessed by the service.
Below are brief descriptions to help readers understand Table 14 – Access to CSPs and Public Keys by Service.
Explanations are provided in groups of services and/or keys (as best suited to explain the pattern of access),
describing first those aspects that have commonality across services or keys/CSPs.
Lifecycle: must be used with Secure Channel active (hence SD Session keys are ‘E’); zeroizes all keys except
session keys when Lifecycle is used for card termination.
OS-MKEK: used whenever any private or secret key is accessed, zeroized on Lifecycle card termination.
OS-DRBG CSPs: OS-DRBG-SEED is the NDRNG entropy input to the DRBG instantiation block_cipher_df at
power-on (Module Reset), zeroized after use. OS-DRBG-STATE is generated at startup (Module Reset), zeroized
at shutdown as part of Module Reset, or by LifeCycle card termination. Each ‘ES’ in the OS-DRBG-STATE column
indicates the use of the DRBG to generate keys, as the value is used and the state is updated.
Secure Channel Master Keys (SD-KENC, SD-KMAC): ‘E’ when a secure channel is initialized (GP Secure Channel,
PKI Applet Secure Channel). May be updated (‘IS’) using the Manage Content service; zeroized by Lifecycle card
termination. SD-KDEK is used to decrypt CSPs entered into the module.
Secure Channel Session Keys (SD-SENC, SD-SMAC, SD-RMAC): ‘E’ for any service that can be used with secure
channel active. ‘GE’ on GP Secure Channel, PKI Applet Secure Channel as a consequence of secure channel
initialization and usage; however, while the SD-RMAC key is generated by default, the PKI Applet Secure
Channel does not use it). ‘Z’ on Module Reset as a consequence of RAM clearing/garbage collection.
Digital Signature: uses PKI-KRSA-PRI/PKI-KRSA-PUB or PKI-KECC-PRI for digital signature (‘E’).
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 17 of 18
4. Self – tests
4.1 Power - On Self - tests
On power‐on or reset, the module performs self‐tests as described in Table 16 below. All KATs must be
completed successfully prior to any other use of cryptography by the module.
Test Target Description
CRC‐16 Compute CRC 16 from a fixed message and check the result (a critical function test).
Firmware Integrity 16 bit CRC performed over all executable code in NVM.
DRBG Performs a fixed input KAT as defined in section 11.3 of SP800-90A.
AES Self‐test of AES-128 forward cipher is performed by the SP 800‐108 self‐test. Self‐test
of AES-128 inverse cipher is performed by the SP 800‐38F self‐test.
Triple‐DES Performs separate encrypt and decrypt KATs using 3‐Key Triple‐DES in ECB mode.
SP 800‐108 KDF Performs a KAT of SP 800‐108 KDF. This self‐test is inclusive of AES-128 CMAC and AES-
128 encrypt function self‐test.
SP 800‐38F Performs a KAT of SP 800‐38F key unwrapping. This self‐test is inclusive of AES-128
decrypt function self‐test.
RSA STD Performs RSA signature verify KAT using an RSA 2048‐bit key.
RSA CRT Performs RSA CRT signature generate KAT using an RSA 2048‐bit key. This test is
inclusive of the RSADP primitive.
ECDSA Performs ECDSA signature generation and verification known answer tests using the
P‐224 curve. This self‐test is inclusive of the ECC CDH function self‐test.
SHA‐256 Performs a fixed input KAT of SHA‐256
SHA‐512 Performs a fixed input KAT of SHA‐512 (inclusive of the SHA‐384 truncated variation).
SHA-3 Performs a fixed input KAT of SHA‐3
Table 15 – Power-On Self –Test
4.2 Conditional self - tests
On every call to the DRBG or NDRNG, the module performs the AS09.42 continuous RNG test to assure that the
output is different than the previous value.
The module performs the SP 800‐90A health monitoring tests for all DRBG functions.
When an RSA or ECC key pair is generated or loaded, the module performs a pairwise consistency test.
When new firmware is loaded into the module using the Manage Content service, the module verifies the
integrity of each packet using AES CMAC.
Optionally, the firmware load process (Manage Content service) can also verify the signature of the new
firmware (applet) using the DAP-PUB public key; the signature block in this scenario is generated by an external
entity using the private key corresponding to DAP-PUB.
NOTE: If any self‐test fails, the system emits an error code (0x6FXX) and enters the SELF‐TEST ERROR state.
Security Policy for HiCOS PKI Applet v2.0 on IDEMIA ID-One Cosmo v8.1-R2
Page 18 of 18
5. Physical Security Policy
The module is a single‐chip implementation that meets commercial‐grade specifications for power,
temperature, reliability, and shock/vibrations.
The module is intended to be mounted in additional packaging; physical inspection of the die is typically not
practical after packaging.
Module hardness testing was performed at the following temperatures:
• Nominal temperature: 20°C
• Low temperature: ‐40°C
• High temperature: 120°C
6. Operational Environment
The module is designated as a limited operational environment under the FIPS 140‐2 definitions. The module
includes a firmware load as part of the Manage Content service to support necessary updates. New firmware
versions within the scope of this validation must be validated through the FIPS 140‐2 CMVP. Any other
firmware loaded into this module is out of the scope of this validation and requires a separate FIPS 140‐2
validation.
7. Electromagnetic interference and compatibility (EMI/EMC)
The module conforms to the EMI/EMC requirements specified by part 47 Code of Federal Regulations, Part 15,
Subpart B, Unintentional Radiators, Digital Devices, Class B.
8. Mitigation of Other Attacks Policy
The module implements defenses against:
• Light attacks
• Invasive fault attacks
• Side‐channel attacks: SPA/DPA; Timing analysis;
• Electromagnetic attacks
• Differential fault analysis (DFA)
• Card tearing attacks
9. Security Rules and Guidance
The module implementation also enforces the following security rules:
• No additional interface or service is implemented by the module which would provide access to CSPs.
• Data output is inhibited during key generation, self-tests, zeroization, and error states.
• There are no restrictions on which keys or CSPs are zeroized by the comprehensive zeroization mechanism.
• The module does not support manual key entry, output plaintext CSPs or output intermediate key values.
• Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of
the module.
The user shall enforce the following security rule:
• The same Triple-DES 3 keys shall not be used to encrypt/decrypt more than 216
64-bit blocks.