| Standard | FIPS 140-3 |
|---|---|
| Overall level | 3 |
| Module type | Hardware |
| Embodiment | Single Chip |
| Status | Active |
| Sunset date | 10/2/2030 |
| Caveat | None |
| Vendor | Giesecke+Devrient ePayments GmbH |
flowchart LR
%% Deterministic review-risk graph for Sm@rtCafé Expert 8.1
%% Review prompts and evidence gaps, NOT vulnerability findings.
subgraph CMVP["CMVP-disclosed clues"]
C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>UPDATE<br/>Recovery</i>"]
C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i>"]
C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</i>"]
end
subgraph Inference["Derived inference"]
I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
end
subgraph Risk["Reviewer question"]
R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
end
subgraph Evidence["Evidence needed to close"]
E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
end
C2 --> I2 --> R2 --> E2
C3 --> I3 --> R3 --> E3
C6 --> I6 --> R6 --> E6
classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
class C2,C3,C6 clue;
class I2,I3,I6 infer;
class R2,R3,R6 risk;
class E2,E3,E6 evidence;flowchart LR
%% Deterministic clue tier for Sm@rtCafé Expert 8.1
%% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
subgraph CMVP["CMVP-disclosed clues (deterministic)"]
C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>UPDATE<br/>Recovery</i><br/>src: text:keyword"]
C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i><br/>src: text:keyword"]
C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>application</i><br/>src: text:keyword"]
end
classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
class C2,C3,C6 clueLow;Giesecke+Devrient ePayments GmbH Sm@rtCafe Expert 8.1 Document Version: 1.3 Date: 09/16/2025 Giesecke+Devrient ePayments GmbH Public Material
| # | Section | Page |
|---|
Giesecke+Devrient ePayments GmbH Public Material
| Item | Page |
|---|---|
| Table 1: Security Levels | 5 |
| Table 2: Tested Module Identification – Hardware | 8 |
| Table 3: Modes List and Description | 8 |
| Table 4 – ATR Structure | 9 |
| Table 5: Approved Algorithms | 10 |
| Table 6: Vendor-Affirmed Algorithms | 10 |
| Table 7: Non-Approved, Allowed Algorithms | 10 |
| Table 8: Security Function Implementations | 14 |
| Table 9: Entropy Certificates | 16 |
| Table 10: Entropy Sources | 16 |
| Table 11: Ports and Interfaces | 17 |
| Table 12: Authentication Methods | 19 |
| Table 13: Roles | 21 |
| Table 14: Approved Services | 27 |
| Table 15: Mechanisms and Actions Required | 31 |
| Table 16: EFP/EFT Information | 31 |
| Table 17: Hardness Testing Temperatures | 32 |
| Table 18: Storage Areas | 33 |
| Table 19: SSP Input-Output Methods | 33 |
| Table 20: SSP Zeroization Methods | 34 |
| Table 21: SSP Table 1 | 36 |
| Table 22: SSP Table 2 | 39 |
| Table 23: Pre-Operational Self-Tests | 41 |
| Table 24: Conditional Self-Tests | 45 |
| Table 25: Pre-Operational Periodic Information | 46 |
| Table 26: Conditional Periodic Information | 52 |
| Table 27: Error States | 53 |
| Table 28 – Attack List | 56 |
| Table 29 – References | 58 |
| Table 30 – Acronyms and Definitions | 60 |
| Figure 1 – G+D’s PD6 (PHS2.2) module: black encapsulation (left); lead frame (right) | 6 |
| Figure 2 - Module Block Diagram | 7 |
the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for an overall Security Level 3 module.
The FIPS 140-3 security levels for the Module are as follows from Table 1: Section Title Security Level
1 General 3
2 Cryptographic module specification 3
3 Cryptographic module interfaces 3
4 Roles, services, and authentication 3
5 Software/Firmware security 3
6 Operational environment N/A
7 Physical security 3
8 Non-invasive security N/A
9 Sensitive security parameter management 3
10 Self-tests 3
11 Life-cycle assurance 3
12 Mitigation of other attacks 3
Overall Level 3 Table 1: Security Levels Giesecke+Devrient ePayments GmbH Public Material
Purpose and Use: The Module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated applications for authorized condition access, like secure ID applications (PIV Card), the Module is intended to be used in a wide range of different end-user environments. Module Type: Hardware Module Embodiment: SingleChip Module Characteristics: Cryptographic Boundary: The physical form of the Module is depicted in Figure 1. The cryptographic boundary is designed to be embedded into plastic card bodies, with a contact plate and contactless antenna connections. The cryptographic boundary is the surface and edges of the packages as shown in the Figures. The contactless ports of the module require connection to an antenna. The module relies on [ISO7816] and [ISO14443] card readers as input/output devices. Figure 1
System Applications Layer Java Applications Layer Card Manager Demonstration Applet Firmware Platform G+D API GlobalPlatform API JavaCard API JCP OS Hardware Power RAM AES/DES CRC Vcc, Mgmt Engine GND Clock MPU RSA/ECC Timers CLK Mgmt Engine CPU Sensors NVM HW RNG ISO 7816 (Entropy) (UART) I/O (Contact) ROM Reset ISO 14443 RST LA/LB (RF) Mgmt (RF) Figure 2 - Module Block Diagram The JavaCard, GlobalPlatform and G+D APIs are internal interfaces available only to applets and security domains (i.e., Card Manager). Only applet services are available at the card edge (the interfaces that cross the cryptographic boundary).
The HW version and the OS version can be retrieved by a GET DATA command: GET DATA: 00 CA 52 C0 will return the response data field containing the HW-Version: 02 00 42.1 GET DATA: 00 CA DF E3 will return the response data field containing the OS-Version in tag 85: B3 E8 CE 6A.2 The Version of the loaded applet can be retrieved by a GET STATUS command with the AID of the applet: GET STATUS: 80 F2 20 00 0D 4F 0L <AID> 00 will return response data containing the AID followed by 2 version bytes. The demonstration applet AID is 31 42 33 34 35 AA FF CA FE FF AA, and the version is 0x0100. This response value of Get Data is mapped to the Hardware Version in Table
Tested Module Identification
There are no components that are excluded from the cryptographic boundary.
Modes List and Description: Mode Description Type Status Indicator Name Approved The module is set to Approved The explicit indicator of Approved Mode approved mode at mode is given in the ATR: the value manufacturing and is always 0x46 ('F') in Historical Byte 10 in the Approved mode indicates the Approved mode (See table below) Table 3: Modes List and Description The ATR has the following structure: *interface bytes historical bytes 3B DF 97 80 31 FE 45 00 ⏟
⏟ 31 4D 31 ⏟ 03 ⏟ 𝑋𝑋 𝑋𝑋 ⏟ 𝑋𝑋 ⏟ "𝑆𝐶𝐸 8.1−" "F" "1𝑀1" 𝐿𝑖𝑓𝑒 9000 𝑜𝑟 𝐶𝑅𝐶 𝐹𝐼𝑃𝑆 𝑉𝑎𝑟𝑖𝑎𝑛𝑡 𝑐𝑦𝑐𝑙𝑒𝑒 𝑒𝑟𝑟𝑜𝑟 𝑐𝑜𝑑𝑒 𝑎𝑝𝑝𝑟𝑜𝑣𝑒𝑑 𝑠𝑡𝑎𝑡𝑒 𝑖𝑓 𝑠𝑒𝑙𝑓 𝑡𝑒𝑠𝑡 𝑚𝑜𝑑𝑒 𝑒𝑟𝑟𝑜𝑟 𝑜𝑐𝑐𝑢𝑟𝑠 Giesecke+Devrient ePayments GmbH Public Material
Approved Algorithms: The Module implements the FIPS Approved cryptographic algorithms listed in the table below. Algorithm CAVP Cert Properties Reference AES-CBC A5371 - SP 800-38A AES-CFB128 A5371 - SP 800-38A AES-CMAC A5372 - SP 800-38B AES-CTR A5371 - SP 800-38A AES-ECB A5371 - SP 800-38A AES-KW A5384 - SP 800-38F AES-KWP A5384 - SP 800-38F Counter DRBG A5383 - SP 800-90A Rev. ECDSA KeyGen (FIPS186-5) A5375 - FIPS 186-5 ECDSA KeyVer (FIPS186-5) A5375 - FIPS 186-5 ECDSA SigGen (FIPS186-5) A5375 - FIPS 186-5 ECDSA SigVer (FIPS186-4) A5375 - FIPS 186-4 ECDSA SigVer (FIPS186-5) A5375 - FIPS 186-5 HMAC-SHA2-224 A5376 - FIPS 198-1 HMAC-SHA2-256 A5376 - FIPS 198-1 HMAC-SHA2-384 A5376 - FIPS 198-1 HMAC-SHA2-512 A5376 - FIPS 198-1 KAS-ECC Sp800-56Ar3 A5378 - SP 800-56A Rev. KAS-ECC-SSC Sp800-56Ar3 A5379 - SP 800-56A Rev. KDF SP800-108 A5377 - SP 800-108 Rev. RSA Decryption Primitive Sp800-56Br2 A5374 - SP 800-56B Rev. (CVL) 2 RSA KeyGen (FIPS186-5) A5373 - FIPS 186-5 RSA SigGen (FIPS186-5) A5374 - FIPS 186-5 RSA Signature Primitive (CVL) A5374 - FIPS 186-4 RSA SigVer (FIPS186-4) A5374 - FIPS 186-4 RSA SigVer (FIPS186-5) A5374 - FIPS 186-5 SHA-1 A5380 - FIPS 180-4 SHA2-224 A5380 - FIPS 180-4 SHA2-224 A5381 - FIPS 180-4 SHA2-256 A5380 - FIPS 180-4 SHA2-256 A5381 - FIPS 180-4 SHA2-384 A5380 - FIPS 180-4 SHA2-384 A5381 - FIPS 180-4 SHA2-512 A5380 - FIPS 180-4 SHA2-512 A5381 - FIPS 180-4 Giesecke+Devrient ePayments GmbH Public Material
Algorithm CAVP Cert Properties Reference SHA3-224 A5382 - FIPS 202 SHA3-256 A5382 - FIPS 202 SHA3-384 A5382 - FIPS 202 SHA3-512 A5382 - FIPS 202 Table 5: Approved Algorithms Vendor-Affirmed Algorithms: The Module implements the FIPS Vendor Affirmed cryptographic algorithms listed. Name Properties Implementation Reference CKG Key N/A SP800-133rev2 Sections 4 example 1 and Type:Asymmetric IG D.H Table 6: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: The Module implements the FIPS Non-Approved, but Allowed cryptographic algorithms listed. Name Properties Implementation Reference KAS-ECC-SSC brainpoolP224r1: kasssc IG C.A, D.F Scenario #3 brainpoolP256r1: brainpoolP384r1: brainpoolP512r1: brainpoolP256t1: brainpoolP384t1: brainpoolP512t1: Table 7: Non-Approved, Allowed Algorithms Non-Approved, Allowed Algorithms with No Security Claimed: The Module does not implement the FIPS Non-Approved, Allowed cryptographic Algorithms with No Security Claimed. N/A for this module. Non-Approved, Not Allowed Algorithms: The Module does not implement the FIPS Non-Approved, Not Allowed cryptographic algorithms listed. N/A for this module. Giesecke+Devrient ePayments GmbH Public Material
The following table shows the Security Function Implementations that the module implements: Name Type Description Properties Algorithms ecckeygen AsymKeyPair-KeyGen Asymmetric Key-Pair ECDSA KeyGen Generation (FIPS186-5): (A5375) Counter DRBG: (A5383) CKG: () Key Type: Asymmetric rsakeygen AsymKeyPair-KeyGen Asymmetric Key-Pair RSA KeyGen (FIPS186Generation 5): (A5373) Counter DRBG: (A5383) CKG: () Key Type: Asymmetric eckeyval AsymKeyPair-KeyVer Public key validation ECDSA KeyGen (FIPS186-5): (A5375) ECDSA KeyVer (FIPS186-5): (A5375) aesenc BC-UnAuth Block Cipher AES-CBC: (A5371) AES-ECB: (A5371) AES-CTR: (A5371) AES-CFB128: (A5371) aesdec BC-UnAuth Block Cipher AES-CBC: (A5371) AES-ECB: (A5371) AES-CTR: (A5371) AES-CFB128: (A5371) ecsiggen DigSig-SigGen Digital Signature ECDSA SigGen Generation (FIPS186-5): (A5375) Counter DRBG: (A5383) SHA2-224: (A5380) SHA2-256: (A5380) Giesecke+Devrient ePayments GmbH Public Material
Name Type Description Properties Algorithms SHA2-384: (A5380) SHA2-512: (A5380) ecsiggencomp DigSig-SigGen Digital Signature ECDSA SigGen Generation Component (FIPS186-5): (A5375) Counter DRBG: (A5383) SHA2-224: (A5380) SHA2-256: (A5380) SHA2-384: (A5380) SHA2-512: (A5380) rsasiggen DigSig-SigGen Digital Signature RSA SigGen (FIPS186Generation 5): (A5374) Counter DRBG: (A5383) SHA2-224: (A5380) SHA2-256: (A5380) SHA2-384: (A5380) SHA2-512: (A5380) SHA3-224: (A5382) SHA3-256: (A5382) SHA3-384: (A5382) SHA3-512: (A5382) rsasp1 DigSig-SigGen Digital Signature RSA Signature Generation Component Primitive: (A5374) Counter DRBG: (A5383) ecsigver DigSig-SigVer Digital Signature ECDSA SigVer Verification (FIPS186-4): (A5375) Counter DRBG: (A5383) SHA-1: (A5380) SHA2-224: (A5380) SHA2-256: (A5380) SHA2-384: (A5380) SHA2-512: (A5380) Giesecke+Devrient ePayments GmbH Public Material
Name Type Description Properties Algorithms ECDSA SigVer (FIPS186-5): (A5375) rsasigver DigSig-SigVer Digital Signature RSA SigVer (FIPS186Verification 4): (A5374) Counter DRBG: (A5383) SHA2-224: (A5380) SHA2-256: (A5380) SHA2-384: (A5380) SHA2-512: (A5380) RSA SigVer (FIPS1865): (A5374) rsadp UNK RSA Decryption RSA Decryption Component Primitive Sp800-56Br2: (A5374) drbg DRBG Random Number Counter DRBG: Generation (A5383) AES-ECB: (A5371) trng ENT-ESV Entropy Source kasecc KAS-Full Key Agreement Caveat:Key KAS-ECC Sp800establishment method 56Ar3: (A5378) provides between 128 SHA2-256: (A5381) and 192 bits of SHA2-384: (A5381) encryption strength AES-CMAC: (A5372) kasssc KAS-SSC Key Agreement Shared KAS-ECC-SSC Sp800Secret 56Ar3: (A5379) kbkdf KBKDF Key-Based Key KDF SP800-108: Derivation (A5377) AES-CMAC: (A5372) aeskw BC-Auth Key Unwrapping for AES-KW: (A5384) internal use importing AES-KWP: (A5384) keys at manufacturing aescmac MAC Message Authentication AES-CMAC: (A5372) Generation Giesecke+Devrient ePayments GmbH Public Material
Name Type Description Properties Algorithms hmac MAC Message Authentication HMAC-SHA2-224: Generation (A5376) HMAC-SHA2-256: (A5376) HMAC-SHA2-384: (A5376) HMAC-SHA2-512: (A5376) shs#1 SHA Secure Hash Standard SHA2-224: (A5380) SHA2-256: (A5380) SHA2-384: (A5380) SHA2-512: (A5380) shs#2 SHA Secure Hash Standard SHA2-224: (A5381) SHA2-256: (A5381) SHA2-384: (A5381) SHA2-512: (A5381) sha-3 SHA Secure Hash Standard SHA3-224: (A5382) SHA3-256: (A5382) SHA3-384: (A5382) SHA3-512: (A5382) scp03 KTS-Wrap Key Transport - Caveat:Key AES-CMAC: (A5372) Wrapping establishment AES-CBC: (A5371) methodology provides between 128 and 256 bits of encryption strength Table 8: Security Function Implementations Giesecke+Devrient ePayments GmbH Public Material
Giesecke+Devrient ePayments GmbH Public Material
KAS [56Ar3] - Per [IG] D.F Scenario 2 path (2), compliant key agreement scheme where testing is performed end-to-end for the shared secret computation and a KDF compliant with SP 800-56C2 with key confirmation. KAS-SSC [56Ar3] - Per [IG] D.F Scenario 2 path (2), compliant with the derivation of a shared secret Z in one or more of the key agreement schemes in Section 6 of SP 800-56Arev3.
Cert Vendor Name Number E112 STMicroelectronics Table 9: Entropy Certificates The Module uses the following entropy sources: Name Type OperationalSample Entropy Conditioning EnvironmentSize per Component Sample ESV Entropy Source Physical ST31N600 revB and revC 1 bit 0.75 N/A Table 10: Entropy Sources The entropy source provides a min-entropy of H >= 0.75. The output of the entropy source is used for the instantiation of the NIST SP800-90A compliant DRBG (#A5383). 568 bits of entropy is collected which provides 384 bits of entropy for the DRBG and 184 bits of entropy for the nonce. The 384 bits of entropy accounts for 288 bits of entropy which exceeds the 256-bits required. 184 bits of entropy for the nonce accounts for 138 bits of entropy. Giesecke+Devrient ePayments GmbH Public Material
For Key Generation methods, see Section 2.5 Algorithms and Section 2.6 Security Function Implementations above.
For Key Establishment methods, see Section 2.5 Algorithms and Section 2.6 Security Function Implementations above.
The Module’s ports and associated FIPS defined logical interface categories are listed below. Physical Logical Data That Passes Port Interface(s) VCC, GND Power ISO 7816: Supply voltage - Contact configurations only RST Control Input ISO 7816: Reset - Contact configurations only CLK Control Input Control in - Contact configurations only I/O Data Input ISO 7816: Clock - Contact configurations only Data Output Control Input Status Output LA, LB Data Input ISO 7816: Input/Output - Contact configurations only Data Output Control Input Status Output Power Table 11: Ports and Interfaces Giesecke+Devrient ePayments GmbH Public Material
Note: The module does not support Control Output. Control/data input and status/data output are separated by the command-response nature of the Module. The Module is either transmitting or receiving, but never both at once. ISO/IEC 7816-4 APDUs are used for communication over the contact-based (ISO7816) and contactless (ISO14443) interfaces. The APDU interface is used by an external Card Acceptance Device (CAD), i.e. an off card application and card reader/writer, to send commands to the Module. The APDU interface is mapped to the physical I/O port and LA/LB port. It comprises the logical interface for Data in, Control in, Data out and Status out. Data in corresponds to the data field of APDU commands received by the Module. Control in corresponds to APDU command header. Data and status output are mapped to APDU responses sent by the Module. Data out is mapped to the data field of APDU responses. The Status out is mapped to the status code, SW1 SW2 (ISO/IEC 7816 status word). The Hardware interface for contact-based, contactless, and dual-interface operations is composed of the parameters to supply the Module for start-up and for operation. The Control input for contact-based (ISO 7816-3) operation is mapped to RST (reset signal) and CLK (clock signal). The Control input (clock and reset) and the power supply for contactless (ISO 14443) operation is mapped to the coil connections LA and LB. Dual-interface controllers may be powered either by contact-based or by contactless power supply.
Method Description Security Mechanism Strength Each Attempt Strength per Minute Name AM1 Identity Based Secure Channel The probability that a The module enforces a maximum Authentication: The CO Protocol random attempt will of fifteen (15) consecutive failed role manages module Authentication Method succeed using this SCP authentication attempts. The content and configuration, See Section 4.1.1 authentication method is: probability that a random attempt Giesecke+Devrient ePayments GmbH Public Material
Method Description Security Mechanism Strength Each Attempt Strength per Minute Name including issuance and Secure Channel 1/2^128 = 2.9E-39 (for any will succeed over a one-minute management of module Protocol of AES-128/192/256 SD- interval is: 15/2^128 = 4.4E-38 (for data via the ISD.. Authentication Method KENC/SD-SENC, assuming any of AES-128/192/256 SDa 128-bit block) KENC/SD-SENC, assuming a 128bit block AM2 Identity Based Demonstration Applet The probability that a The module enforces a maximum Authentication: The User Authentication Method random attempt will of three (4) consecutive failed role is for use in See section 4.1.2 succeed using this authentication attempts. The Demonstration applet. Demonstration Applet authentication method is: probability that a random attempt Authentication Method: 1/256^8 = 5.4E-20 will succeed over a one minute interval is: 4/256^8. Table 12: Authentication Methods After activation or reset of the Module no operator is authenticated. Actions on behalf of an operator require the operator’s prior successful authentication. The Module’s authentication methods prevent unauthorized disclosure and modification of SSPs. The Module supports identity-based operator authentication by means of SCP03, defined in [GP Amd D]. The Module prevents reuse of authentication data related to the Secure Channel Protocol. After completion of the authentication protocol, the Module accepts commands with correct message authentication code only. These commands must have been sent via the Secure Channel using the key previously agreed with the terminal during the authentication. Protection of user data transmitted from the Module to the terminal is achieved by means of secure messaging with encryption and message authentication codes. After authentication, user data in transit is protected from unauthorized disclosure, modification, deletion, insertion and replay attacks. In the usage phase, authentication data entry, modification and substitution is performed within a Secure Channel only. The Module does not output the Secure Channel static keys or the Secure Channel session keys. The PIN used by the Demonstration Applet’s PIN authentication service can only be transmitted to the Module after successful initiation of a Secure Channel. The PIN is never output by the Module. Giesecke+Devrient ePayments GmbH Public Material
Feedback provided during an authentication attempt is indicated in the status words (SW1 SW2) returned in the response message to the INITIALIZE UPDATE and EXTERNAL AUTHENTICATE commands. Successful execution of the command is indicated by the status bytes ’90’ ‘00’. In case of an error, the status code either corresponds to one of the General Error conditions or to a specific error condition defined in [GPCS]. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module. The status returned does not weaken the strength of the mechanism. Secure Channel Protocol Authentication Method The Secure Channel Protocol authentication method (I2 in the SSP Input-Output Methods table) is provided by the Secure Channel service. The SD-KENC and SD-KMAC keys are used to derive the SD-SENC and SD-SMAC keys, respectively. The key derivation uses KDF in counter mode as specified in NIST SP 800-108 [108]. The PRF used in the KDF is CMAC as specified in NIST 800-38B [38B], used with full 16 byte output length. The initial step of the Secure Channel Service initiates the session key derivation on the card and conveys also the host challenge. The card returns the card challenge and the card cryptogram, calculated as a CMAC with the session keys. This is checked by the host. To perform finally the mutual authentication the final step of the Secure Channel Service conveys the host cryptogram to the card, which is a CMAC based on the card challenge and calculated with the session keys on host side. After the successfully check of the exchanged cryptograms by card and host, the two participants are mutually authenticated (the external entity is authenticated to the module in the CO role). Demonstration Applet Authentication Method The Demonstration Applet Authentication method is provided by the Secure Channel Protocol Authentication Method (I1 in the SSP InputOutput Methods table) combined with the PIN Authenticate service. The Module accepts an 8 byte PIN value and compares all 8 bytes to a stored reference, with no restriction on character space (each character can be any value from 0-255). The Module does not visibly display the PIN.
The Module supports two distinct operator roles, User and Cryptographic Officer (CO). The Module enforces the separation of roles using authentication. Re-authentication is enforced when changing roles. Giesecke+Devrient ePayments GmbH Public Material
The table below lists all operator roles supported by the Module. In addition, the Module supports services which does not require to be authenticated, see also services table below. The Module does not support a maintenance role and bypass capability. The Module supports concurrent operators in a limited fashion. The module allows for multiple logical channels. Only one operator at a time is permitted on a logical channel, which explains the limitation posed upon concurrent operators. The separation of roles operating on different logical channel is ensured by having different secure channels with different session keys. Name Type Operator Type Authentication Methods Cryptographic Officer Identity CO AM1 User Identity User AM2 Table 13: Roles Giesecke+Devrient ePayments GmbH Public Material
All approved services implemented by the Module are listed in the table below: The SSPs modes of access shown in the table below are defined as:
Name Description Indicato Inputs Outputs Security SSP Access r Functions - SD-DM-RCPT-RSA: Z - PIN_KEY: Z - DEM-PIN: Z - DEM CMAC: Z - DEM HMAC: Z - DEM-DH-PRIV: Z - DEM-DH-PUB: Z - DEM-KAS-PRIV: Z - DEM-KAS-PUB: Z - DEM-SGV-RSA-PRIV: Z - DEM-SGV-RSA-PUB: Z - DEM-SGV-ECC-PRIV: Z - DEM-SGV-ECC-PUB: Z DEM_SHARED_SEC_SS C: Z - DEM SHARED_SEC_ECC: Z Manage Content Loads and Approve Content Status word aesenc Cryptographic Officer installs d mode management aesdec - SD-SENC: E application is given commands LOAD, ecsiggen - SD-SMAC: E packages and in the INSTALL, DELETE, ecsigver - SD-SRMAC: E associated ATR: the STORE DATA, PUT aeskw - SD-KDEK: E keys and data. value KEY scp03 - SD-DAP-RSA: E 0x46 - SD-DAP-AES: E ('F') - SD-CIPH-LD-AES: E - SD-DM-TOKEN-AES: E - SD-DM-TOKEN-ECC: E - SD-DM-TOKEN-RSA: E - SD-DM-RCPT-AES: E - SD-DM-RCPT-ECC: E - SD-DM-RCPT-RSA: E - SD-DAP-ECC: E Giesecke+Devrient ePayments GmbH Public Material
Name Description Indicato Inputs Outputs Security SSP Access r Functions Module Info Reads module Approve GET DATA, GET Configuration scp03 Cryptographic Officer (Authenticated) configuration d mode STATUS command data, status - SD-SENC: E or status is given word - SD-SMAC: E information in the - SD-SRMAC: E (privileged data ATR: the User objects). value - SD-SENC: E 0x46 - SD-SMAC: E ('F') - SD-SRMAC: E Module Info Reads module Approve GET DATA Configuration None Unauthenticated (Unauthenticate configuration d mode data, Status d) or status is given word information. in the ATR: the value 0x46 ('F') Secure Channel Establishes Approve INTIALIZE card kbkdf Cryptographic Officer and uses a d mode UPDATE/EXTERNA challenge, - SD-KENC: E secure is given L AUTH command card - SD-KMAC: E communication in the cryptogram, - SD-SENC: G s channel. ATR: the status word - SD-SMAC: G value - SD-SRMAC: G 0x46 User ('F') - SD-SENC: G - SD-KENC: E - SD-KMAC: E - SD-SMAC: G - SD-SRMAC: G PIN Demonstrates Approve Command to Demo Status word aesenc User Authentication PIN d mode Applet to call API aesdec - PIN_KEY: E authentication is given OwnerPIN.checkwit - DEM-PIN: R with in the h PIN OwnerPIN. ATR: the value Giesecke+Devrient ePayments GmbH Public Material
Name Description Indicato Inputs Outputs Security SSP Access r Functions 0x46 ('F') Key Generation Generates Approve Command to Demo status word ecckeygen User keys and d mode Applet to call API for rsakeygen - DEM-DH-PRIV: G initializes is given key generation. API eckeyval - DEM-DH-PUB: G symmetric and in the input: Domain - DEM-KAS-PRIV: G asymmetric ATR: the parameters - DEM-KAS-PUB: G key objects for value - DEM-SGV-RSA-PRIV: G the 0x46 ('F' - DEM-SGV-RSA-PUB: G cryptographic - DEM-SGV-ECC-PRIV: G services. - DEM-SGV-ECC-PUB: G Digital Signature Demonstrates Approve Command to Demo Signature, ecsiggen User RSA and d mode Applet to call API: status word. ecsiggencom - DEM-SGV-RSA-PRIV: E ECDSA digital is given API input: Signature p - DEM-SGV-RSA-PUB: E signature in the Generation: rsasiggen - DEM-SGV-ECC-PRIV: E generation and ATR: the ECDSA, RSA rsasp1 - DEM-SGV-ECC-PUB: E verification, value private key and ecsigver ECDSA digital 0x46 ('F' message Signature rsasigver signature Verification: ECDSA rsadp component public key and and the RSA signature Signature Primitive. Key Agreement Generates a Approve Command to Demo common kasssc User Primitive common secret d mode Applet to call API: secret - DEM-DH-PRIV: E from a DH key is given API input: Card - DEM-DH-PUB: E exchange in the Privat key, Host ATR: the Public key DEM_SHARED_SEC_SS value C: G,E 0x46 ('F' RSA Decryption Demonstrates Approve Command to Demo Cryptogram, rsadp User Primitive the RSA d mode Applet to call API: status word - DEM-SGV-ECC-PRIV: E Decryption is given API input: RSA - DEM-SGV-RSA-PUB: E Primitive in the Giesecke+Devrient ePayments GmbH Public Material
Name Description Indicato Inputs Outputs Security SSP Access r Functions ATR: the private key, plain value input data 0x46 ('F' Opacity KAS-Full with Approve Command to Demo AuthCrytogra kasecc User parameters d mode Applet to call API: m - DEM-KAS-PRIV: E according to is given API input: Card - DEM-KAS-PUB: E SP.800-73-4 in the Privat key, Host - DEM ATR: the Public key SHARED_SEC_ECC: G,E value 0x46 ('F' Message Authenticate Approve Command to Demo MAC aescmac User Authentication messages d mode Applet to call API: hmac - DEM CMAC: E is given API input: Message - DEM HMAC: E in the ATR: the value 0x46 ('F' Message Digest Generates Approve Command to Demo Hash value shs#1 User hashes d mode Applet to call API: shs#2 is given API input: Message sha-3 in the ATR: the value 0x46 ('F' Error Log Logging of Approve Error state triggered Error status in None Cryptographic Officer error states d mode ATR User is given Unauthenticated in the ATR: the value 0x46 ('F' Module Reset Resets the Approve RST or Power OFF+ ATR drbg Cryptographic Officer module. d mode Power ON trng - DRBG-EI: E,Z Includes is given - OS-DRBG-STATE: G Giesecke+Devrient ePayments GmbH Public Material
Name Description Indicato Inputs Outputs Security SSP Access r Functions Power-On Self- in the - SD-SENC: Z Test. ATR: the - SD-SMAC: Z value - SD-SRMAC: Z 0x46 ('F' DEM_SHARED_SEC_SS C: Z - DEM SHARED_SEC_ECC: Z - DEM-KAS-PUB: Z - DEM-DH-PUB: Z - DEM-DH-PRIV: Z User - DRBG-EI: E - OS-DRBG-STATE: G - SD-SENC: Z - SD-SMAC: Z - SD-SRMAC: Z DEM_SHARED_SEC_SS C: Z - DEM SHARED_SEC_ECC: Z Unauthenticated Table 14: Approved Services
NOTE: There are no non-approved services available. N/A for this module. Giesecke+Devrient ePayments GmbH Public Material
NOTE: There is no External Software/Firmware Loaded. Giesecke+Devrient ePayments GmbH Public Material
The Module’s firmware is composed of the embedded operating system and Java card packages including the demonstration applet. An error detection code is applied to all software and firmware components within the hardware module’s defined cryptographic boundary.
The operator can initiate the integrity test on demand by Module reset. Giesecke+Devrient ePayments GmbH Public Material
Type of Operational Environment: Non-Modifiable The Module has a non-modifiable operational environment under the FIPS 140-3 definitions. Giesecke+Devrient ePayments GmbH Public Material
The Module is a single-chip implementation that meets commercial-grade specifications for power, temperature, reliability, and shock/vibrations. The Module uses standard passivation techniques.
The Module’s chip packaging uses tamper evident material that is opaque within the visible spectrum. The material is designed so that attempts at removal or penetration will have a high probability of causing serious damage. Mechanism Inspection Frequency Inspection Guidance Tamper-Evident Material Before first use by end user. Operator should look for damage Table 15: Mechanisms and Actions Required
Temp/Voltage Temperature EFP Result Type or Voltage or EFT LowTemperature -60°C EFP Shutdown HighTemperature 128°C EFP Shutdown LowVoltage 2.2V EFP Shutdown HighVoltage 6.2V EFP Shutdown Table 16: EFP/EFT Information
Giesecke+Devrient ePayments GmbH Public Material
Temperature Temperature Type LowTemperature -25°C HighTemperature 85°C Table 17: Hardness Testing Temperatures
Non-invasive mechanisms employed by the Module are under Section 12 Mitigation of other attacks. Giesecke+Devrient ePayments GmbH Public Material
Storage Description Persistence Area Type Name S1 Only stored in volatile memory RAM Dynamic S2 Stored in NVM in plaintext, associated by memory location pointer Static S3 Stored in NVM, obfuscated by dynamically generated mask Static Table 18: Storage Areas
Name From To Format Distribution Entry SFI or Type Type Type Algorithm Input encapsulated in Secure Channel Application Software S3 Encrypted Manual Electronic scp03 (I1) (outside) Input encapsulated in Secure Channel Application Software S3 Encrypted Automated Electronic scp03 (I2) (outside) Table 19: SSP Input-Output Methods
Zeroization Description Rationale Operator Initiation Method Z1 Replace with All data in storage area S1 are zeroized if module is reset. Not time Any role: reset Module zeros critical, related SSPs are not accessible by unauthorized operators. Z2 Replace with Used to zeroize all sensitive data at end of life of module. See also CO role: set life cycle state zeros chapter End of Life. to TERMINATED Giesecke+Devrient ePayments GmbH Public Material
Table 20: SSP Zeroization Methods The zeroization of SSPs is implemented as an internal process without connection to data output. Zeroization is implicit Z1: Concerning the “Temporary Storage Duration”, an SSP which is stored in category S1 is stored until the next reset of the module. There is no specific time duration for this. Z2: Issuing the APDU SET STATUS (TERMINATE) command will destroy all sensitive data on the module and leave the module inoperable.
All usage of these SSPs by the Module are described in the services detailed in Section 4.3 Approved Services. Name Description Size - Strength Type - Generated By Established Used By Category By DRBG-EI Entropy input 384 - N/A Entropy - CSP trng drbg DRBG-SM Seed material 568 - N/A Entropy - CSP trng drbg DRBG-Nonce Nonce 184 - N/A Entropy - CSP trng drbg OS-DRBG-STATE Internal state: V 384 - N/A Entropy - CSP trng drbg (128 bits) and Key (AES 256) SD-KENC Master key 128,192,1256 - Symmetric Input at kbkdf decryption Key 128,192,256 authentication manufacturing key - CSP SD-KMAC Master MAC 128,192,256 - Secret - CSP Input at kbkdf Key 128,192,256 manufacturing SD-KDEK Master key 128,192,256 - Secret - CSP Input at aesenc decryption Key 128,192,256 manufacturing aesdec SD-SENC Session Key 128,192,256 - Secret - CSP kbkdf aesenc 128,192,256 aesdec Giesecke+Devrient ePayments GmbH Public Material
Name Description Size - Strength Type - Generated By Established Used By Category By SD-SMAC Session Key 128,192,256 - Secret - CSP kbkdf aescmac 128,192,256 SD-SRMAC Session Key 128,192,256 - Secret - CSP kbkdf aescmac 128,192,256 SD-DAP-AES AES DAP 128,192, 256 - Secret - CSP Input at aescmac verification key 128,192, 256 manufacturing SD-DAP-ECC ECC DAP P Curves (192, Public - PSP Input at ecsigver verification key 224, 256,384 manufacturing 521) - 96-256 SD-DAP-RSA RSA DAP 1024- 4096 - 80- Public - PSP Input at rsasigver verification key 200 manufacturing SD-CIPH-LD-AES Loadfile 128, 192, 256 - Secret - CSP Input at AES-CBC decryption key 128, 192, 256 manufacturing (A5371) SD-DM-TOKEN-AES AES token 128, 192, 256 - Public - PSP Input at aescmac verification key 128, 192, 256 manufacturing SD-DM-TOKEN-ECC ECC token P Curves (192, Public - PSP Input at ecsigver verification key 224, 256,384 manufacturing 521) - 96-256 SD-DM-TOKEN-RSA RSA token 1024- 4096 - 80- Public - PSP Input at rsasigver verification key 200 manufacturing SD-DM-RCPT-AES AES receipt 128, 192, 256 - Secret - CSP Other aescmac generation key 128, 192, 256 SD-DM-RCPT-ECC ECC receipt P Curves (224, Private - CSP Input at ecckeygen generation key 256,384 521) - manufacturing 112-256 SD-DM-RCPT-RSA RSA receipt 2048-4096 - 112- Private - CSP Other rsakeygen generation key 200 PIN_KEY Key for PIN 256 - 256 Secret - CSP Input at aesenc obfuscation manufacturing aesdec DEM-PIN Demo Applet 256 - 256 PIN - CSP Other aesdec User PIN DEM CMAC Key for CMAC 128, 192, 256 - Secret - CSP N/A aescmac calculation 128, 192, 256 Giesecke+Devrient ePayments GmbH Public Material
Name Description Size - Strength Type - Generated By Established Used By Category By DEM HMAC Key for HMAC Min: 8 Max: 2040 Secret - CSP N/A hmac calculation -DEM-DH-PRIV Demo Applet P Curves (224, Private - CSP ecckeygen ecckeygen ECC CDH 256,384 521 private key 112-256 DEM-DH-PUB Demo Applet P Curves (224, Public - PSP N/A ecckeygen ECC CDH 256,384 521) public key 112-256 DEM-KAS-PRIV Demo Applet P Curves Private - CSP ecckeygen kasssc KAS ECC (256,384) - 128, (Opacity) 192 private key DEM-KAS-PUB Demo Applet P Curves Public - PSP N/A kasssc KAS ECC (256,384) - 128, public key 192 DEM-SGV-RSA-PRIV Demo Applet 2048-4096 - 112- Private - CSP rsakeygen rsasiggen RSA signature 200 private key DEM-SGV-RSA-PUB Demo Applet 1024-4096 - 80- Public - PSP rsakeygen rsasigver RSA signature 200 public key DEM-SGV-ECC-PRIV Demo Applet P Curves (224, Private - CSP ecckeygen ecsiggen ECC signature 256,384 521) private key 112-256 DEM-SGV-ECC-PUB Demo Applet P Curves (192, Public - PSP ecckeygen ecsigver ECC signature 224, 256,384 public key 521) - 96-256 DEM_SHARED_SEC_SSC Shared secret 224, 256, 384, Private - CSP N/A kasssc kasssc
DEM SHARED_SEC_ECC Shared secret 128, 256 - 128, Private - CSP N/A kasecc kasecc Table 21: SSP Table 1 Giesecke+Devrient ePayments GmbH Public Material
Name Input - Storage Storage Zeroization Related SSPs Output Duration DRBG-EI S1:Plaintext until the Z1 DRBG-SM:Derived From next reset of the module DRBG-SM S1:Plaintext until the Z1 DRBG-EI:Used by next reset of the module DRBG-Nonce S1:Plaintext N/A until Z1 DRBG-SM:Used by the next reset of the module OS-DRBG-STATE S1:Plaintext until the Z1 DRBG-EI:Derived From next reset of the module SD-KENC S3:Obfuscated N/A Z2 SD-SENC:Derived From SD-KMAC S3:Obfuscated N/A Z2 SD-SMAC:Derived From SD-SRMAC:Derived From SD-KDEK S3:Obfuscated N/A Z2 DEM-PIN:Decrypts DEM CMAC:Decrypts DEM HMAC:Decrypts DEM-DH-PUB:Decrypts DEM-KAS-PUB:Decrypts SD-SENC S1:Plaintext until the Z1 SD-KENC:Derived From next reset of the module SD-SMAC S1:Plaintext until the Z1 SD-KMAC:Derived From next reset of the module Giesecke+Devrient ePayments GmbH Public Material
Name Input - Storage Storage Zeroization Related SSPs Output Duration SD-SRMAC S1:Plaintext until the Z1 SD-KMAC:Derived From next reset of the module SD-DAP-AES S3:Obfuscated N/A Z2 SD-DAP-ECC S3:Obfuscated N/A Z2 SD-DAP-RSA S3:Obfuscated N/A Z2 SD-CIPH-LD-AES S3:Obfuscated N/A Z2 SD-DM-TOKEN-AES S3:Obfuscated N/A Z2 SD-DM-TOKEN-ECC S3:Obfuscated N/A Z2 SD-DM-TOKEN-RSA S3:Obfuscated N/A Z2 SD-DM-RCPT-AES S3:Obfuscated N/A Z2 SD-DM-RCPT-ECC S3:Obfuscated N/A Z2 SD-DM-RCPT-RSA S3:Obfuscated N/A Z2 PIN_KEY S3:Obfuscated N/A Z2 DEM-PIN:Derived From DEM-PIN Input S3:Obfuscated N/A Z2 PIN_KEY:Derived From encapsulated in Secure Channel (I1) DEM CMAC Input S3:Obfuscated Z2 encapsulated in Secure Channel (I2) DEM HMAC Input S3:Obfuscated Z2 encapsulated in Secure Channel (I2) DEM-DH-PRIV S3:Obfuscated Z1 DEM_SHARED_SEC_SSC:Calculates S1:Plaintext Z2 secret with DEM-DH-PUB DEM SHARED_SEC_ECC:Calculates secret with DEM-DH-PUB DEM-DH-PUB Input S1:Plaintext until the Z1 DEM_SHARED_SEC_SSC:Calculates encapsulated next reset secret with DEM-DH-PRIV Giesecke+Devrient ePayments GmbH Public Material
Name Input - Storage Storage Zeroization Related SSPs Output Duration in Secure of the DEM SHARED_SEC_ECC:Calculates Channel (I2) module secret with DEM-DH-PRIV DEM-KAS-PRIV S3:Obfuscated N/A Z2 DEM-KAS-PUB:Calculates secret with DEM-KAS-PUB Input S1:Plaintext until the Z1 DEM-KAS-PRIV:Calculates secret with encapsulated next reset in Secure of the Channel (I2) module DEM-SGV-RSA-PRIV S3:Obfuscated Z2 DEM-SGV-RSA-PUB:Paired With DEM-SGV-RSA-PUB S2:Plaintext Z2 DEM-SGV-RSA-PRIV:Paired With DEM-SGV-ECC-PRIV S3:Obfuscated Z2 DEM-SGV-ECC-PUB:Paired With DEM-SGV-ECC-PUB S2:Plaintext Z2 DEM-SGV-ECC-PUB:Paired With DEM_SHARED_SEC_SSC S1:Plaintext until the Z1 DEM-DH-PRIV:Derived From next reset DEM-DH-PUB:Derived From of the module DEM SHARED_SEC_ECC S1:Plaintext until the Z1 DEM-KAS-PRIV:Derived From next reset DEM-KAS-PUB:Derived From of the module Table 22: SSP Table 2
The following list specifies applicable transition periods or timeframes where an algorithm or key length transitions from Approved to non-Approved:
The Module performs self-tests to ensure the proper operation of the Module. Per FIPS 140-3 these are categorized as either pre-operational self-tests or conditional self-tests. The Module will not accept any commands when a self-test is running, because another command can only be processed if the actual command which triggers the self-test is finished. The command which has triggered the self-test may still be in the I/O buffer and will be processed if the self-tests are finished. Therefore, no operator action is involved in executing the self-tests. If a self-test succeeds, the last two bytes of the historical bytes of the ATR is set to ‘9000’. If a self-test fails, the Module logs the latest self-test error in the last two bytes of the historical bytes of the ATR, see ATR structure in section 2.4 Modes of Operation. The CO/User can consult the error log by observing these bytes which are unique for every self-tests.
Periodic Method: All pre-operational self-tests are performed by the Module at the first command after every reset. As the Module is frequently reset the tests are performed periodically (IG 10.3.E, Resolution 3.a.). The Module performs the following pre-operational self-tests. Giesecke+Devrient ePayments GmbH Public Material
Algorithm Test Test Test Type Indicator Details or Test Properties Method Firmware Reed KAT SW/FW Pass - Approved A 16 bit Reed-Solomon EDC performed over all integrity Solomon-32 Integrity mode Fail - Error code in the cryptographic boundary is compared Code to a pre-stored value. TRNG RCT and SP 800-90B Critical Pass - Approved An RCT and APT as specified in [90B] section APT health-test Function mode Fail - Error 4.4 are executed before generation of the Code DRBG entropy input Table 23: Pre-Operational Self-Tests Giesecke+Devrient ePayments GmbH Public Material
As the column space is limited here some explanations for some columns: Periodic Method: The conditional self-tests are performed before the first use of an algorithm after every reset. This results in a periodic execution as the module is reset frequently. (IG 10.3.E, Resolution 3.a.). Period: Until next reset. Indicator: The self-test pass indicator is a ‘9000’ in the ATR, the fail indicator is an error code in the ATR. Condition: There are two conditions when a conditional self-test is executed: COND1: Before the first use of an algorithm after reset. COND2: After each key generation. The below tests with test method KAT consist of a set of known input vectors (input data, keys) which are operated on by the cryptographic algorithm to generate a result. The result is compared to the known expected output result. If the calculated output does not equal the known answer, the self-test error state is set. The Module performs the following conditional self-tests: Giesecke+Devrient ePayments GmbH Public Material
Algorithm or Test Test Test Indicator Details Conditions Test Properties Method Type AES-ECB AES-128 KAT CAST Pass - AES-128 ECB decryption of 16 byte data COND1 (A5371) Approved mode Fail Error Code AES CMAC AES-128 KAT CAST Pass - AES CMAC 128. KAT for CMAC COND1 Generation Approved generation. As CMAC uses AES mode Fail - encryption this self-tests includes an AES Error Code ENC self-test AES-CMAC AES-128 KAT CAST Pass - AES CMAC 128. KAT for CMAC COND1 Verification Approved verification. mode Fail Error Code Counter DRBG AES-256 KAT CAST Pass - One KAT for instantiation and generation COND1 (A5383) CTR_DRBG. Approved performed before the first random data mode Fail - generation. Error Code KAS-ECC P-256 KAT CAST Pass - ECCDH Shared Secret computation. COND1 Sp800-56Ar3 Approved (A5378) mode Fail Error Code One-Step KDF SHA-256 KAT CAST Pass - "One-Step KDF" part of KAS ECC. The COND1 (A5378) Approved other parts ECC CDH and the final AES mode Fail - CMAC (key confirmation) are tested Error Code already by the self-tests KAS-SCC and AES-CMAC above. KDF SP800-108 AES-128 KAT CAST Pass - SP 800-108 KDF. This self-test is COND1 (A5377) CMAC Approved inclusive of AES CMAC and AES encrypt mode Fail - self-test. Error Code ECDSA KeyGen P-224, P-256, PCT PCT Pass - With the generated key pair an ECDSA COND2 (FIPS186-5) P-384, P-521 Approved signature is generated and the result is (A5375) mode Fail - given as input to the verify method, and it Error Code is checked that the call is successful. Giesecke+Devrient ePayments GmbH Public Material
Algorithm or Test Test Test Indicator Details Conditions Test Properties Method Type ECDSA SigGen P-256 KAT CAST Pass - Test mode activated, so that a fix random COND1 (FIPS186-5) Approved is used to get a constant oupout from (A5375) mode Fail - ECDSA sign Error Code ECDSA SigVer P-256 KAT CAST Pass - KAT for signature verification COND1 (FIPS186-5) Approved (A5375) mode Fail Error Code HMAC-SHA2-256 HMAC-256 KAT CAST Pass - HMAC with key length 256 and SHA-256 COND1 (A5376) with SHA-256 Approved hash mode Fail Error Code RSA Decryption 2048 KAT CAST Pass - RSA CRT sign and verify with known key COND1 Primitive Sp800- Approved and known 256 bytes input data 56Br2 (A5374) mode Fail Error Code RSA KeyGen 2048, 3072 PCT PCT Pass - With the generated RSA Standard key COND2 (FIPS186-5) Approved pair known input data are decrypted and (A5373) mode Fail - encrypted and the result is compared to Error Code the input data. RSA SigGen 2048 KAT CAST Pass - RSA-2048 KAT for signature generation. COND1 (FIPS186-5) Approved (A5374) mode Fail Error Code RSA SigVer 2048 KAT CAST Pass - -RSA-2048 KAT for signature verification. COND1 (FIPS186-5) Approved (A5374) mode Fail Error Code RSA KeyGen 2048, 3072, - PCT Pass - With the generated RSA CRT key pair COND2 CRT 4096 Approved known input data are decrypted and mode Fail - encrypted and the result is compared to Error Code the input data. SHA-1 (A5380) SHA-1 KAT CAST Pass - Hashing of 67 bytes input data COND1 Approved Giesecke+Devrient ePayments GmbH Public Material
Algorithm or Test Test Test Indicator Details Conditions Test Properties Method Type mode Fail Error Code SHA2-256 SHA2-256 KAT CAST Pass - Hashing of 67 bytes input data COND1 (A5381) Approved mode Fail Error Code SHA3-256 SHA3-256 KAT CAST Pass - Hashing of 67 bytes input data COND1 (A5382) Approved mode Fail Error Code SHA2-512 SHA2-512 KAT CAST Pass - Hashing of 67 bytes input data COND1 (A5381) Approved mode Fail Error Code SHA2-256 SHA2-256 KAT CAST Pass - Hashing of 67 bytes input data COND1 (A5380) Approved mode Fail Error Code SHA2-512 SHA2-512 KAT CAST Pass - Hashing of 67 bytes input data COND1 (A5380) Approved mode Fail Error Code Table 24: Conditional Self-Tests Giesecke+Devrient ePayments GmbH Public Material
Algorithm or Test Method Test Type Period Periodic Test Method Firmware KAT SW/FW Integrity Every Reset All Preintegrity operational selftests are performed by the Module at the first command after every reset. As the module is frequently reset the tests are periodically performed (IG 10.3.E, Resolution 3.a.). TRNG SP 800-90B Critical Function Every Reset All Prehealth-test cycle operational selftests are performed by the Module at the first command after every reset. As the module is frequently reset the tests are periodically performed (IG 10.3.E, Resolution 3.a.) Table 25: Pre-Operational Periodic Information Algorithm or Test Method Test Type Period Periodic Test Method AES-ECB KAT CAST no specific The conditional (A5371) duration self-tests are performed before the first use of an algorithm after every reset. This results in a periodically execution as the Giesecke+Devrient ePayments GmbH Public Material
Algorithm or Test Method Test Type Period Periodic Test Method module is frequently reset. (IG 10.3.E, Resolution 3.a.). AES CMAC KAT CAST no specific The conditional Generation duration self-tests are performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). AES-CMAC KAT CAST no specific The conditional Verification duration self-tests are performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). Counter DRBG KAT CAST no specific The conditional (A5383) duration self-tests are performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). Giesecke+Devrient ePayments GmbH Public Material
Algorithm or Test Method Test Type Period Periodic Test Method KAS-ECC KAT CAST no specific The conditional Sp800-56Ar3 duration self-tests are (A5378) performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). One-Step KDF KAT CAST no specific The conditional (A5378) duration self-tests are performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). KDF SP800-108 KAT CAST no specific The conditional (A5377) duration self-tests are performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). ECDSA KeyGen PCT PCT no specific Before key (FIPS186-5) duration generation (A5375) request ECDSA SigGen KAT CAST no specific The conditional (FIPS186-5) duration self-tests are (A5375) performed Giesecke+Devrient ePayments GmbH Public Material
Algorithm or Test Method Test Type Period Periodic Test Method before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). ECDSA SigVer KAT CAST no specific The conditional (FIPS186-5) duration self-tests are (A5375) performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). HMAC-SHA2- KAT CAST no specific The conditional
256 (A5376) duration self-tests are
performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). RSA Decryption KAT CAST no specific The conditional Primitive Sp800- duration self-tests are 56Br2 (A5374) performed before the first use of an algorithm after every reset. This results in a periodically execution as the Giesecke+Devrient ePayments GmbH Public Material
Algorithm or Test Method Test Type Period Periodic Test Method module is frequently reset. (IG 10.3.E, Resolution 3.a.). RSA KeyGen PCT PCT no specific Before key (FIPS186-5) duration generation (A5373) request RSA SigGen KAT CAST no specific The conditional (FIPS186-5) duration self-tests are (A5374) performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). RSA SigVer KAT CAST no specific The conditional (FIPS186-5) duration self-tests are (A5374) performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). RSA KeyGen - PCT no specific Before key CRT duration generation request SHA-1 (A5380) KAT CAST no specific The conditional duration self-tests are performed before the first use of an algorithm after every reset. This results in a periodically execution as the Giesecke+Devrient ePayments GmbH Public Material
Algorithm or Test Method Test Type Period Periodic Test Method module is frequently reset. (IG 10.3.E, Resolution 3.a.). SHA2-256 KAT CAST no specific The conditional (A5381) duration self-tests are performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). SHA3-256 KAT CAST no specific The conditional (A5382) duration self-tests are performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). SHA2-512 KAT CAST no specific The conditional (A5381) duration self-tests are performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). SHA2-256 KAT CAST no specific The conditional (A5380) duration self-tests are Giesecke+Devrient ePayments GmbH Public Material
Algorithm or Test Method Test Type Period Periodic Test Method performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). SHA2-512 KAT CAST no specific The conditional (A5380) duration self-tests are performed before the first use of an algorithm after every reset. This results in a periodically execution as the module is frequently reset. (IG 10.3.E, Resolution 3.a.). Table 26: Conditional Periodic Information
If any self-test fails or a fault attack is detected, the first indication is that the card mutes, i.e. all data output via the data output interface are inhibited and no further communication is possible. The module does not perform any command execution or cryptographic operations in this state. The module has to be reset and the ATR shows the error status (see Section 2.4). After that the module enters one of the following error states listed in below table. Name Description Conditions Recovery Method Indicator ES1 Persistent error Entered when the None, the module is Error code in state (SELF-TEST module fails a not operative the ATR. Any ERROR) Firmware integrity anymore. further test Self-test command sent (KAT/PCT) 2 times to the module is SP800-90B Health blocked and will Test in a row Any return the status fault detection word 0x6666. occurs Giesecke+Devrient ePayments GmbH Public Material
Name Description Conditions Recovery Method Indicator ES2 Intermediate error Entered when the After reset the Error code in state module fails a module is ready for the ATR. (INTERMEDIATE SP800-90B Health use again. If the TEST ERROR) Test health test succeeds the next time, the error code in the ATR is cleared. If the heath test fails 2 times in a row the persistent error state ES1 is entered, Table 27: Error States
The Module allows the operator to initiate power-up self-tests by power cycling or resetting the Module.
No specific procedures have to be applied for secure installation, initialization, startup, and operation of the Module. Installation and Initialization: There are no specific rules to be performed in order to securely install, initialize, and start up the cryptographic module in the FIPS 140-3 Approved mode of operation. Delivery: The Module is delivered in approved mode and it starts-up in approved mode. Authorized operators of the Module are the Crypto Officer and the User. Authentication mechanisms for those operators are described in section 4.1 Authentication Methods Authentication Methods. All security mechanisms of the Module are active after production such that the Module protects itself against attacks and unauthorized access to security functions. Therefore, no additional security measures have to be applied for the delivery to the Crypto Officer or User. The module must be delivered securely, with tracking and protection against theft, by contracted logistic partners to the authorized operator. The recipient must check and confirm correct reception.
The Crypto Officer (Administrator) guidance is covered by the submission document Sm@rtCafé Expert
Giesecke+Devrient ePayments GmbH Public Material
The User (non-administrator) guidance is covered by the submission document Sm@rtCafé Expert 8.1 Reference Manual [REF_MAN] that will be sent to the User.
There are no specific overall security design and the rules of operation for the Module. Rules of Operation
The term end-of-life of the module describes the secure cleanup of the module in a way that it cannot be used any longer. There are 2 separate ways a module can enter the end-of-life state. 1. The Crypto officer decides that the module needs to be destroyed. In order to do that, the CO has to authenticate to the module (AM1) and issue a SET STATUS (TERMINATE). This will use Giesecke+Devrient ePayments GmbH Public Material
the zeroization method Z2, which destroys all sensitive data on the module (see section SSP Zeroization). 2. The module detects multiple attacks. After a predefined number of attacks the card will terminate the card by using the zeroization method Z2 (see section SSP Zeroization). The module shall be returned to the CO for secure physical destruction e.g. by shredding or cutting the chip in small pieces. Giesecke+Devrient ePayments GmbH Public Material
The Module implements the following mitigation methods against other attacks.
The Module implement the following mitigation methods against other attacks. Attack* Method Method Effectiveness description Counter-measures are implemented in The countermeasure implemented in software and hardware. The module hardware were already tested in an uses the counter-measures of the independent Common Criteria crypto coprocessor which uses e.g. evaluation of the chip platform Power Analysis randomized and hiding methods of the (ANSSI-CC-2022/21) with the highest key material and calculated vulnerability assessment possible (intermediate) results applied in the (AVA_VAN.5). crypto operation, uses a noise The counter-measures implemented generator for CPU and crypto unit, in the OS software were tested in the defines constant timing function for G+D SPA/DPA/DFA/LFI test coprocessors and applies data and laboratories with state-of-the-art register masking. equipment and methods that revealed Electromagnetic analysis Additionally software counter- no vulnerabilities for the measures against timing attacks and cryptographic algorithms of the SPA/DPA attacks are e.g. transient data module. arrays in RAM (clear on reset, clear on All requirements of the hardware applet selection), mechanisms for security guidance [AN_SECU] were sensitive data areas (creation, access implemented. and clearing), data manipulation hiding, constant time code execution, Timing analysis randomized algorithm execution, randomized data initialization, erasure and comparison. Table 28
The card is muted upon detection of a potential security violation such that the Module preserves a secure state. Giesecke+Devrient ePayments GmbH Public Material
References and Definitions The following standards are referred to in this Security Policy. Table 29
Abbreviation* Full Specification Name [38B] NIST Special Publication 800-38B, National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, May 2005 [38C] NIST Special Publication 800-38C, National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality, May 2004 (errata update 07-20-2007) [38D] NIST Special Publication 800-38D, National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, November 2007 [38E] NIST Special Publication 800-38E, National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices, January 2010 [38F] NIST Special Publication 800-38F, National Institute of Standards and Technology, Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping, December 2012 [56Ar3] NIST Special Publication 800-56A Revision 3, National Institute of Standards and Technology, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, April 2018 [56Br2] NIST Special Publication 800-56B Revision 2, National Institute of Standards and Technology, Recommendation for Pair-Wise Key Establishment Schemes Using Finite Field Cryptography, March 2019 [56Cr2] NIST Special Publication 800-56C Revision 2, National Institute of Standards and Technology, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, August 2020 [67] NIST Special Publication 800-67 Revision 2, National Institute of Standards and Technology, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, May 2004 [90A] NIST Special Publication 800-90A Revision 1, National Institute of Standards and Technology, Recommendation for Random Number Generation Using Deterministic Random Bit Generators, June 2015. [90B] NIST Special Publication 800-90B, National Institute of Standards and Technology, Recommendation for the Entropy Sources Used for Random Bit Generation, January 2018. [GPCS] GlobalPlatform Technology Card Specification, Version 2.3.1, Public Release, March 2018 [GP Amd D] GlobalPlatform Card Technology, Secure Channel Protocol ‘03’, Card Specification v2.2
Abbreviation* Full Specification Name [JCVM] Java Card Platform Virtual Machine Specification, Classic Edition, v3.1, January 2019, Oracle [JCAPI] Java Card Platform Application Programming Interface, Classic Edition, v3.1.0, Oracle [PKCS#1] PKCS#1 v2.1: RSA Cryptography Standard, RSA Laboratories, June 14, 2002 [AN_SECU] AN_SECU_ST31N Security Guidance of the ST31N secure MCU platform, Rev 1