NXP JCOP 2.4.2 R2
FIPS 140-2 Security Policy
Copyright NXP, 2012
Version 0.5
Page 10 of 16
NXP Public Material may be reproduced only in its original entirety (without revision)
2.2 Public keys
Key
Description / Usage
DAP-PUB
RSA 1024-bit public key used for new firmware signature verification.
DEMO-RSA-PUB
RSA 1024-bit or 2048-bit public key used by the Demo RSA service.
DEMO-ECDSA-PUB
ECDSA P-192, P-224 or P-256 public key used by the Demo ECDSA service
DEMO-ECC-CDH-PUB
EC P-192, P-224 or P-256 public key used by the Demo ECC CDH service.
Table 6 - Public Keys
3
Roles, authentication and services
3.1 Roles
Table 7 lists all operator roles supported by the module. This Module does not support a maintenance
role. The Module clears previous authentications on power cycle. The Module supports GP logical
channels, allowing multiple concurrent operators. Authentication of each operator and their access to
roles and services is as described in this section, independent of logical channel usage. Only one
operator at a time is permitted on a channel. Applet deselection (including 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. A velocity check on the Global Platform authentication
procedure is performed. Maximum PIN try limit is implemented: During CVM verification, if the CVM
verification fails and the Retry Limit has been reached, the CVM state shall transition to BLOCKED.
Role ID
Role Description
CO
Cryptographic Officer
This role is responsible for card issuance and management of card data via the Card Manager
applet. Authenticated using the SCP authentication method with SD-SENC.
USR
The role used in the demonstration applet, the User role for FIPS 140-2 purposes. Authenticated
using symmetric AES mechanism with DEMO-AUTH and DEMO-AUTH-KEY.
Table 7 - Roles description
3.2 Secure Channel Protocol (SCP) Authentication
The GlobalPlatform Secure Channel Protocol authentication method is performed when the EXTERNAL
AUTHENTICATE service is invoked after successful execution of the INITIALIZE UPDATE command. These
two commands operate as described next.
The SD-KENC and SD-KMAC keys are used along with other information 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 SD- keys may be 2-Key TDES (SCP01/02) or AES-128 (SCP03). Note that the only use of the any of
the SD- keys for encryption is for a total of 1 block over the life of the associated SD-SENC session key.
The Module's designed encryption limitation using SD-SENC prevents the meet-in-the-middle attack
described in [SP800-131A]. In accordance with [SP800-131A], the Module's 2-Key TDES security strength
is 112 bits. Based on this strength (expressed in scientific notation format in parentheses):
The probability that a random attempt at authentication will succeed is 1/2^64 (5.42E-20) for
SCP01/02; 1/2^128 for SCP03 (2.94E-39).
Based on the maximum count value of the failed authentication blocking mechanism, the
probability that a random attempt will succeed over a one minute period is 255/2^64 (1.38E-17) for
SCP01/02; 255/2^128 for SCP03 (7.49E-37).