Sm@rtCafé Expert 8.1

Certificate

Derived Review-Risk Graph (review prompts, not findings)

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;

Security Policy, page by page

Giesecke+Devrient ePayments GmbH Sm@rtCafe Expert 8.1 Document Version: 1.3 Date: 09/16/2025 Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

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: Table 1: Security Levels Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

2 – Cryptographic Module Specification

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

• G+D’s PD6 (PHS2.2) module: black encapsulation (left); lead frame (right) Figure 2 depicts the module block diagram. Giesecke+Devrient ePayments GmbH Public Material
• May be reproduced only in its original entirety (without revision). Template v1.0

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

2. This response value of Get Data is mapped to the Firmware Version in Table
3. Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Tested Module Identification – Hardware: Giesecke+Devrient Sm@rtCafé Expert 8.1 cryptographic module is tested on the following operational environment.

There are no components that are excluded from the cryptographic boundary.

Modes List and Description: The ATR has the following structure:

53 43 45 20 38 2E 31 2D 46

⏟       31 4D 31 ⏟             03 ⏟      𝑋𝑋 𝑋𝑋 ⏟          𝑋𝑋 ⏟ 𝐹𝐼𝑃𝑆      𝑉𝑎𝑟𝑖𝑎𝑛𝑡    𝑐𝑦𝑐𝑙𝑒𝑒 𝑒𝑟𝑟𝑜𝑟 𝑐𝑜𝑑𝑒 𝑎𝑝𝑝𝑟𝑜𝑣𝑒𝑑                𝑠𝑡𝑎𝑡𝑒  𝑖𝑓 𝑠𝑒𝑙𝑓 𝑡𝑒𝑠𝑡 𝑚𝑜𝑑𝑒                        𝑒𝑟𝑟𝑜𝑟 𝑜𝑐𝑐𝑢𝑟𝑠 Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision).                                   Template v1.0

Approved Algorithms: The Module implements the FIPS Approved cryptographic algorithms listed in the table below. Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Table 5: Approved Algorithms Vendor-Affirmed Algorithms: The Module implements the FIPS Vendor Affirmed cryptographic algorithms listed. Table 6: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: The Module implements the FIPS Non-Approved, but Allowed cryptographic algorithms listed. 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 – May be reproduced only in its original entirety (without revision). Template v1.0

The following table shows the Security Function Implementations that the module implements: Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Table 8: Security Function Implementations Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

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. Table 9: Entropy Certificates The Module uses the following entropy sources: 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 – May be reproduced only in its original entirety (without revision). Template v1.0

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. Table 11: Ports and Interfaces Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

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.

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

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]. 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 – May be reproduced only in its original entirety (without revision). Template v1.0

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 – May be reproduced only in its original entirety (without revision). Template v1.0

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. Table 13: Roles Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

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:

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

C: Z Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

('F') Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

('F') Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

NOTE: There are no non-approved services available. N/A for this module. Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

NOTE: There is no External Software/Firmware Loaded. Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

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 – May be reproduced only in its original entirety (without revision). Template v1.0

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 – May be reproduced only in its original entirety (without revision). Template v1.0

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. Table 15: Mechanisms and Actions Required Table 16: EFP/EFT Information

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

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 – May be reproduced only in its original entirety (without revision). Template v1.0

Table 19: SSP Input-Output Methods

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

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. Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Table 21: SSP Table 1 Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

The following list specifies applicable transition periods or timeframes where an algorithm or key length transitions from Approved to non-Approved:

• SHA-1: The module includes an implementation of SHA-1 for hashing and digital signature verification. This implementation will be non-Approved for all uses starting January 1, 2030. Giesecke+Devrient ePayments GmbH Public Material
• May be reproduced only in its original entirety (without revision). Template v1.0

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 – May be reproduced only in its original entirety (without revision). Template v1.0

Table 23: Pre-Operational Self-Tests Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

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 – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Table 24: Conditional Self-Tests Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Table 25: Pre-Operational Periodic Information Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

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 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. Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

The Module allows the operator to initiate power-up self-tests by power cycling or resetting the

No specific procedures have to be applied for secure installation, initialization, startup, and operation of 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 – May be reproduced only in its original entirety (without revision). Template v1.0

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

1. The Module provides two distinct operator roles: User and Cryptographic Officer.
2. The Module provides identity-based authentication.
3. The Module clears previous authentications on power cycle.
4. An operator does not have access to any cryptographic services prior to assuming an authorized role.
5. The Module allows the operator to initiate power-up self-tests by power cycling or resetting the Module.
6. All self-tests do not require any operator action.
7. Data output is inhibited during key generation, self-tests, zeroization, and error states.
8. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the Module.
9. There are no restrictions on which keys or SSPs are zeroized by the zeroization service.
10. The Module does not support concurrent operators.
11. The Module does not support a maintenance interface or role.
12. The Module does not support manual SSP establishment method.
13. The Module does not have any proprietary external input/output devices used for entry/output of data.
14. The Module does not enter or output plaintext CSPs.
15. The Module stores CSPs in plaintext.
16. The Module does not output intermediate key values.
17. The Module does not provide bypass services for ports/interfaces.

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 – May be reproduced only in its original entirety (without revision). Template v1.0

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 – May be reproduced only in its original entirety (without revision). Template v1.0

The Module implements the following mitigation methods against other attacks.

The Module implement the following mitigation methods against other attacks. Table 28

• Attack List The Module detects physical tampering with sensors for operating voltage, clock frequency, temperature and electromagnetic radiation. It is resistant to physical tampering. If the COS detects with the above mentioned sensors that it is not supplied within the specified limits, a security reset is initiated and the Module is not operable until the supply is back in the specified limits. The design of the hardware protects it against analyzing and physical tampering. This Module provides resistance to side channel attacks and enforces protection of its secret data during that are based on external observable physical phenomena of the Module. The Module hides information about IC power consumptions and command execution time such that no confidential information can be derived from this data. Giesecke+Devrient ePayments GmbH Public Material
• May be reproduced only in its original entirety (without revision). Template v1.0

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 – May be reproduced only in its original entirety (without revision). Template v1.0

References and Definitions The following standards are referred to in this Security Policy. Table 29

• References Giesecke+Devrient ePayments GmbH Public Material
• May be reproduced only in its original entirety (without revision). Template v1.0

Giesecke+Devrient ePayments GmbH Public Material – May be reproduced only in its original entirety (without revision). Template v1.0

Table 30

• Acronyms and Definitions Giesecke+Devrient ePayments GmbH Public Material
• May be reproduced only in its original entirety (without revision). Template v1.0