BSI-DSZ-CC-1252-V2-2025 for IFX_CCI_00007Ch/88h/89h/8Ah/8Bh G12 with firmware version 80.512.03.0 or 80.512.03.1, optional Crypto Suite 5.02.002 and user guidance documents from Infineon Technologies AG BSI - Bundesamt für Sicherheit in der Informationstechnik, Postfach 20 03 63, D-53133 Bonn Phone +49 (0)228 99 9582-0, Fax +49 (0)228 9582-5477, Infoline +49 (0)228 99 9582-111 Certification Report V1.0 CC-Zert-327 V5.54 BSI-DSZ-CC-1252-V2-2025 (*) IFX_CCI_00007Ch/88h/89h/8Ah/8Bh G12 with firmware version 80.512.03.0 or 80.512.03.1, optional Crypto Suite 5.02.002 and user guidance documents from Infineon Technologies AG PP Conformance: Security IC Platform Protection Profile with Augmentation Packages Version 1.0, 13 January 2014, BSI-CC-PP-0084-2014 Functionality: PP conformant plus product specific extensions Common Criteria Part 2 extended Assurance: Common Criteria Part 3 extended EAL 6 augmented by ALC_FLR.1 and ATE_SDP.1 valid until: 30 September 2030 The IT Product identified in this certificate has been evaluated at an approved evaluation facility using the Common Methodology for IT Security Evaluation (CEM), CEM:2022 extended by Scheme Interpretations by advice of the Certification Body for components beyond EAL 5 and CC Supporting Documents as listed in the Certification Report for conformance to the Common Criteria for IT Security Evaluation (CC), CC:2022. CC and CEM are also published as ISO/IEC 15408 and ISO/IEC 18045. (*) This certificate applies only to the specific version and release of the product in its evaluated configuration and in conjunction with the complete Certification Report and Notification. For details on the validity see Certification Report part A chapter 5. The evaluation has been conducted in accordance with the provisions of the certification scheme of the German Federal Office for Information Security (BSI) and the conclusions of the evaluation facility in the evaluation technical report are consistent with the evidence adduced. This certificate is not an endorsement of the IT Product by the Federal Office for Information Security or any other organisation that recognises or gives effect to this certificate, and no warranty of the IT Product by the Federal Office for Information Security or any other organisation that recognises or gives effect to this certificate, is either expressed or implied. Bonn, 1 October 2025 For the Federal Office for Information Security Fabian Hodouschek L.S. Sandro Amendola Head of Certification Director-General Directorate General S Bundesamt für Sicherheit in der Informationstechnik Godesberger Allee 87 - D-53175 Bonn - Postfach 20 03 63 - D-53133 Bonn Phone +49 (0)228 99 9582-0 - Fax +49 (0)228 9582-5477 - Infoline +49 (0)228 99 9582-111 SOGIS Recognition Agreement for components up to EAL 4 Common Criteria Recognition Arrangement recognition for components up to EAL 2 and ALC_FLR only Certification Report BSI-DSZ-CC-1252-V2-2025 This page is intentionally left blank. 4 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report Contents A. Certification.....................................................................................................................6 1. Preliminary Remarks....................................................................................................6 2. Specifications of the Certification Procedure...............................................................6 3. Recognition Agreements..............................................................................................7 4. Performance of Evaluation and Certification................................................................8 5. Validity of the Certification Result.................................................................................8 6. Publication...................................................................................................................9 B. Certification Results......................................................................................................10 1. Executive Summary...................................................................................................11 2. Identification of the TOE............................................................................................13 3. Security Policy...........................................................................................................15 4. Assumptions and Clarification of Scope.....................................................................16 5. Architectural Information............................................................................................17 6. Documentation...........................................................................................................19 7. IT Product Testing......................................................................................................19 8. Evaluated Configuration.............................................................................................21 9. Results of the Evaluation...........................................................................................21 10. Obligations and Notes for the Usage of the TOE.....................................................39 11. Security Target.........................................................................................................40 12. Regulation specific aspects (eIDAS, QES)..............................................................40 13. Definitions................................................................................................................40 14. Bibliography.............................................................................................................42 C. Excerpts from the Criteria.............................................................................................44 D. Annexes........................................................................................................................ 45 5 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 A. Certification 1. Preliminary Remarks Under the BSIG1 Act, the Federal Office for Information Security (BSI) has the task of issuing certificates for information technology products. Certification of a product is carried out on the instigation of the vendor or a distributor, hereinafter called the sponsor. A part of the procedure is the technical examination (evaluation) of the product according to the security criteria published by the BSI or generally recognised security criteria. The evaluation is normally carried out by an evaluation facility recognised by the BSI or by BSI itself. The result of the certification procedure is the present Certification Report. This report contains among others the certificate (summarised assessment) and the detailed Certification Results. The Certification Results contain the technical description of the security functionality of the certified product, the details of the evaluation (strength and weaknesses) and instructions for the user. 2. Specifications of the Certification Procedure The certification body conducts the procedure according to the criteria laid down in the following: ● Act on the Federal Office for Information Security1 ● BSI Certification and Approval Ordinance2 ● BMI Regulations on Ex-parte Costs3 ● Special decrees issued by the Bundesministerium des Innern (Federal Ministry of the Interior) ● DIN EN ISO/IEC 17065 standard ● BSI certification: Scheme documentation describing the certification process (CC- Produkte) [3] ● BSI certification: Scheme documentation on requirements for the Evaluation Facility, its approval and licensing process (CC-Stellen) [3] ● Common Criteria for IT Security Evaluation (CC), CC:2022 4 [1] also published as ISO/IEC 15408 1 Act on the Federal Office for Information Security (BSI-Gesetz – BSIG) of 14 August 2009, Bundesgesetzblatt I p. 2821 2 Ordinance on the Procedure for Issuance of Security Certificates and approval by the Federal Office for Information Security (BSI-Zertifizierungs- und -Anerkennungsverordnung – BSIZertV) of 17 December 2014, Bundesgesetzblatt 2014, part I, no. 61, p. 2231 3 BMI Regulations on Ex-parte Costs – Besondere Gebührenverordnung des BMI für individuell zurechenbare öffentliche Leistungen in dessen Zuständigkeitsbereich (BMIBGebV), Abschnitt 7 (BSI- Gesetz) – dated 2 September 2019, Bundesgesetzblatt I p. 1365 6 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report ● Common Methodology for IT Security Evaluation (CEM), CC:2022 [2] also published as ISO/IEC 18045 ● BSI certification: Application Notes and Interpretation of the Scheme (AIS) [4] 3. Recognition Agreements In order to avoid multiple certification of the same product in different countries a mutual recognition of IT security certificates – as far as such certificates are based on ITSEC or CC – under certain conditions was agreed. 3.1. European Recognition of CC – Certificates (SOGIS-MRA) The SOGIS-Mutual Recognition Agreement (SOGIS-MRA) Version 3 became effective in April 2010. It defines the recognition of certificates for IT-Products at a basic recognition level and, in addition, at higher recognition levels for IT-Products related to certain SOGIS Technical Domains only. The basic recognition level includes Common Criteria (CC) Evaluation Assurance Levels EAL 1 to EAL 4. For "Smartcards and similar devices" a SOGIS Technical Domain is in place. For "HW Devices with Security Boxes" a SOGIS Technical Domains is in place, too. In addition, certificates issued for Protection Profiles based on Common Criteria are part of the recognition agreement. The current list of signatory nations and approved certification schemes, details on recognition, and the history of the agreement can be seen on the website at https://www.sogis.eu. The SOGIS-MRA logo printed on the certificate indicates that it is recognised under the terms of this agreement by the related bodies of the signatory nations. A disclaimer beneath the logo indicates the specific scope of recognition. This certificate is recognized under SOGIS-MRA for components applicable for the IT technical domain concerned, in this case the Technical Domain “Smartcards and Similar Devices”. 3.2. International Recognition of CC – Certificates (CCRA) The international arrangement on the mutual recognition of certificates based on the CC (Common Criteria Recognition Arrangement, CCRA-2014) has been ratified on 08 September 2014. It covers CC certificates based on collaborative Protection Profiles (cPP) (exact use), CC certificates based on assurance components up to and including EAL 2 or the assurance family Flaw Remediation (ALC_FLR) and CC certificates for Protection Profiles and for collaborative Protection Profiles (cPP). The current list of signatory nations and approved certification schemes can be seen on the website: https://www.commoncriteriaportal.org. The Common Criteria Recognition Arrangement logo printed on the certificate indicates that this certification is recognised under the terms of this agreement by the related bodies of the signatory nations. A disclaimer beneath the logo indicates the specific scope of recognition. 4 Proclamation of the Bundesamtes für Sicherheit in der Informationstechnik vom 14. April 2023 auf https://www.bsi.bund.de 7 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 This certificate is recognized according to the rules of CCRA-2014, i. e. up to and including CC part 3 EAL 2 and ALC_FLR components. 4. Performance of Evaluation and Certification The certification body monitors each individual evaluation to ensure a uniform procedure, a uniform interpretation of the criteria and uniform ratings. The product IFX_CCI_00007Ch/88h/89h/8Ah/8Bh G12 with firmware version 80.512.03.0 or 80.512.03.1, optional Crypto Suite 5.02.002 and user guidance documents has undergone the certification procedure at BSI. This is a re-certification based on BSI-DSZ- CC-1252-2025. Specific results from the evaluation process BSI-DSZ-CC-1252-2025 were re-used. The evaluation of the product IFX_CCI_00007Ch/88h/89h/8Ah/8Bh G12 with firmware version 80.512.03.0 or 80.512.03.1, optional Crypto Suite 5.02.002 and user guidance documents was conducted by TÜV Informationstechnik GmbH. The evaluation was completed on 1 October 2025. TÜV Informationstechnik GmbH is an evaluation facility (ITSEF)5 recognised by the certification body of BSI. For this certification procedure the sponsor and applicant is: Infineon Technologies AG. The product was developed by: Infineon Technologies AG. The certification is concluded with the comparability check and the production of this Certification Report. This work was completed by the BSI. 5. Validity of the Certification Result This Certification Report applies only to the version of the product as indicated. The confirmed assurance package is valid on the condition that ● all stipulations regarding generation, configuration and operation, as given in the evaluated guidance documentation, are observed, ● the product is operated in the environment as specified and in the Security Target. For the meaning of the assurance components and assurance levels please refer to CC itself. Detailed references are listed in part C of this report. The Certificate issued confirms the assurance of the product claimed in the Security Target. As attack methods evolve over time, the resistance of the certified version of the product against new attack methods needs to be re-assessed. Therefore, the sponsor should apply for the certified product being monitored within the assurance continuity program of the BSI Certification Scheme (e.g. by a re-assessment or re-certification). Specifically, if results of the certification are used in subsequent evaluation and certification procedures, in a system integration process or if a user's risk management needs regularly updated results, it is recommended to perform a re-assessment on a regular e.g. annual basis. Therefore the BSI reserves the right to revoke the certificate, especially if a exploitable vulnerability of the certified product gets to known. In order to avoid an indefinite usage of the certificate when evolved attack methods would require a re-assessment of the products resistance to state of the art attack methods, the 5 Information Technology Security Evaluation Facility 8 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report maximum validity of the certificate has been limited. The certificate issued on 1 October 2025 is valid until 30 September 2030. Validity can be re-newed by re-certification. The owner of the certificate is obliged: 1. when advertising the certificate or the fact of the product's certification, to refer to the Certification Report as well as to provide the Certification Report, the Security Target and user guidance documentation mentioned herein to any customer of the product for the application and usage of the certified product, 2. to inform the Certification Body at BSI immediately about vulnerabilities of the product that have been identified by the developer or any third party after issuance of the certificate, 3. to inform the Certification Body at BSI immediately in the case that security relevant changes in the evaluated life cycle, e.g. related to development and production sites or processes, occur, or the confidentiality of documentation and information related to the Target of Evaluation (TOE) or resulting from the evaluation and certification procedure where the certification of the product has assumed this confidentiality being maintained, is not given any longer. In particular, prior to the dissemination of confidential documentation and information related to the TOE or resulting from the evaluation and certification procedure that do not belong to the deliverables according to the Certification Report part B, or for those where no dissemination rules have been agreed on, to third parties, the Certification Body at BSI has to be informed. 4. fulfil further obligations mentioned in the Zertifizierungsbescheid, if applicable. In case of changes to the certified version of the product, the validity can be extended to the new versions and releases, provided the sponsor applies for assurance continuity (i.e. re-certification or maintenance) of the modified product, in accordance with the procedural requirements, and the evaluation does not reveal any security deficiencies. 6. Publication The product IFX_CCI_00007Ch/88h/89h/8Ah/8Bh G12 with firmware version 80.512.03.0 or 80.512.03.1, optional Crypto Suite 5.02.002 and user guidance documents, has been included in the BSI list of certified products, which is published regularly in the listing found at the BSI Website https://www.bsi.bund.de/dok/Zertifizierung-Gesamtlisten. Further information can be obtained from BSI-Infoline +49 (0)228 9582-111. Further copies of this Certification Report can be requested from the developer6 of the product. The Certification Report may also be obtained in electronic form at the internet address stated above. 6 Infineon Technologies AG St.- Martin - Straße 53 81541 München Deutschland 9 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 B. Certification Results The following results represent a summary of ● the Security Target of the sponsor for the Target of Evaluation, ● the relevant evaluation results from the evaluation facility, and ● complementary notes and stipulations of the certification body. 10 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report 1. Executive Summary The Target of Evaluation (TOE) is the Infineon Security Controller IFX_CCI_00007Ch/88h/89h/8Ah/8Bh G12 with firmware version 80.512.03.0 or 80.512.03.1, optional Crypto Suite 5.02.002 and user guidance documents. The Identifier IFX_CCI_00008Bh was added to the scope. The TOE is represented by various configurations called products, while the module design, layout, and footprint of all products are identical. The identifier IFX_CCI_00008Bh represents another configuration of the TOE in the limits of the already certified TOE (BSI-DSZ-CC-1252-2025). Please refer to Table 2 for an identification of the hardware, firmware, and software components, including the corresponding version identifiers. The TOE provides a 32-bit Armv8-M CPU architecture. The major components of the processor system are the CPU (Central Processing Unit), a MPU (Memory Protection Unit), a Security Attribution Unit (SAU), a Nested Vectored Interrupt Controller (NVIC), an Instruction Stream Signature (ISS) coprocessor, and a Masked Instruction Set Extension (MISE) coprocessor. The TOE can communicate using contact-based and contactless interfaces. This TOE is intended to be used in smart cards for particular security relevant applications and as a developing platform for smart card operating systems. The term smartcard embedded software is used in the following for all operating systems and applications stored and executed on the TOE. The TOE is the platform for the smartcard embedded software. The Security Target [5] is the basis for this certification. It is based on the certified Protection Profile Security IC Platform Protection Profile with Augmentation Packages Version 1.0, 13 January 2014, BSI-CC-PP-0084-2014 [7]. The TOE Security Assurance Requirements (SAR) are based entirely on the assurance components defined in Part 3 of the Common Criteria (see part C or [1], Part 3 for details). The TOE meets the assurance requirements of the Evaluation Assurance Level EAL 6 augmented by ALC_FLR.1 and ATE_SDP.1. The TOE Security Functional Requirements (SFR) relevant for the TOE are outlined in the Security Target [5] and [8], chapter 6. They are selected from Common Criteria Part 2 and some of them are newly defined. Thus the TOE is CC Part 2 extended. The TOE Security Functional Requirements are implemented by the following TOE Security Functionality: TOE Security Functionality Addressed issue SF_DPM Device Phase Management: The life cycle of the TOE is split up into several phases. Different operation modes help to protect the TOE during each phase of its lifecycle. ‍ SF_PS Protection against Snooping: The TOE uses various means to protect from snooping of memories and busses and prevents single stepping. ‍ SF_PMA Protection against Modifying Attacks: This TOE implements protection against modifying attacks of memories, alarm lines, and sensors. 11 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 TOE Security Functionality Addressed issue ‍ SF_PLA Protection against Logical Attacks: The TOE provides four distinct security quadrants for memory protection formed by the combination of the privileged and unprivileged access modes as well as the secure and non- secure security states of the CPU. Up to eight memory regions can be assigned security attributes using the Security Attribution Unit (SAU). For each security state, it is possible to define up to eight memory regions with differ-ent access rights enforced by the Memory Protection Unit (MPU). ‍ SF_HC Hardware provided Cryptography: The TOE is equipped with a hardware accelerator for AES and TDES. Additionally, it is equipped with a True Random Number Generator. SF_CS CryptoSuite Services: The TOE is equipped with the CryptoSuite software supporting: • Encryption, decryption, and MAC generation using the block ciphers AES and TDES, • FFC cryptography, • RSA, • ECC (ECDSA, EdDSA, ECSDSA, curve arithmetic, X25519, X448), • PQC algorithms ML-KEM and MLDSA, • Hashing using SHA-1, SHA-2, SHA-3, • HMAC generation, • Extendable-output function (XOF) generation using SHAKE, and • deterministic and non-deterministic random number generation. Table 1: TOE Security Functionalities For more details please refer to the Security Target [5] and [8], chapter 7. The assets to be protected by the TOE are defined in the Security Target [5] and [8], chapter 3.1. Based on these assets the TOE Security Problem is defined in terms of Assumptions, Threats and Organisational Security Policies. This is outlined in the Security Target [5] and [8], chapter 3. This certification covers the configurations of the TOE as outlined in chapter 8. The vulnerability assessment results as stated within this certificate do not include a rating for those cryptographic algorithms and their implementation suitable for encryption and decryption (see BSIG Section 9, Para. 4, Clause 2). The certification results only apply to the version of the product indicated in the certificate and on the condition that all the stipulations are kept as detailed in this Certification Report. This certificate is not an endorsement of the IT product by the Federal Office for Information Security (BSI) or any other organisation that recognises or gives effect to this certificate, and no warranty of the IT product by BSI or any other organisation that recognises or gives effect to this certificate, is either expressed or implied. 12 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report 2. Identification of the TOE The Target of Evaluation (TOE) is called: IFX_CCI_00007Ch/88h/89h/8Ah/8Bh G12 with firmware version 80.512.03.0 or 80.512.03.1, optional Crypto Suite 5.02.002 and user guidance documents. The following table outlines the TOE deliverables: No Type Identifier Release Form of Delivery 1 HW IFX_CCI_00007Ch, IFX_CCI_000088h, IFX_CCI_000089h, IFX_CCI_00008Ah, IFX_CCI_00008Bh G12 (design step) Depending on customer order. As stated in [5] section 1.4.4, the hardware can be delivered as bare dies (sawn wafer), as modules, or in an IC case. ‍ 2 FW Firmware (BOS, ROM part of HSL, Flash Loader) 80.512.03.0 and 80.512.03.1 (Flash Loader version is also separately identified as version 10.08.0002) Stored on the delivered hardware. ‍ 3 SW HSL (NVM part) 04.08.0000 Secure download of object file via iShare. ‍ 4 SW UMSLC library 02.01.0040 Secure download of object file via iShare. ‍ 5 SW CryptoSuite (optional) 5.02.002 Secure download of object file via iShare. ‍ 6 SW NRG™ SW library (optional; not part of the TSF) 06.10.0005 Secure download of object file via iShare. ‍ 7 DOC TEGRION™ SLC27 (32-bit Security Controller – V32), Hardware Reference Manual See [AGD_HRM]. Personalized PDF via secure iShare server. ‍ 8 DOC TEGRION™ SLx2 security controller family Programmer's, Reference Manual SLx2_DFP See [AGD_PRM]. Personalized PDF via secure iShare server. ‍ 9 DOC SLC27 32-bit Security Controller – V32, Security Guidelines See [AGD_SG]. Personalized PDF via secure iShare server. ‍ 10 DOC SLC27 (32-bit Security Controller – V32), Production and personal- ization manual See [AGD_PPM]. Personalized PDF via secure iShare server. ‍ 11 DOC Crypto2304T V4, User Manual See [AGD_CryptoUM] . Personalized PDF via secure iShare server. ‍ 12 DOC CS-SLC27V32 Crypto Suite 32-bit Security Controller, User interface manual See [AGD_CS]. Personalized PDF via secure iShare server. 13 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 No Type Identifier Release Form of Delivery ‍ 13 DOC TEGRION™ SLC27 (32-bit Security Controller – V32), Errata sheet See [AGD_ES]. Personalized PDF via secure iShare server. Table 2: Deliverables of the TOE Regarding TOE delivery: According to [8], section 1.2.3 the TOE or parts of it are delivered between the following three parties: ● IC Embedded Software Developer, ● TOE Manufacturer (compromises all roles before TOE delivery), ● Composite Product Manufacturer (compromises all roles after TOE delivery except the end consumer). Therefore, three different delivery procedures must be taken into consideration: ● Delivery of the IC dedicated software components (IC dedicated SW, guidance) from the TOE Manufacturer to the IC Embedded Software Developer. ● Delivery of the IC Embedded Software (e.g. ROM / Flash data, initialisation, and pre- personalisation data) from the IC Embedded Software Developer to the TOE Manufacturer. ● Delivery of the final TOE from the TOE Manufacturer to the Composite Product Manufacturer. After phase 3 the TOE is delivered in form of sawn wafers, after phase 4 in form of modules (with or without inlay antenna). To determine the necessary procedures to maintain security when distributing versions of the TOE the assumptions, threats, organisational security policies, and security objectives identified in the ST must be considered for an appropriate level of protection on delivery. ● The internal delivery procedures of the TOE Manufacturer comprise all deliverables among the several TOE Manufacturer sites themselves. These deliverables consist of electronic as well as paper documents and physical items like wafers or masks. The corresponding security procedures guarantee an integer and confidential transfer. These internal procedures are evaluated within the ALC_DVS evaluation activity. ● Delivery from the TOE Manufacturer to the IC Embedded Software Developer: The delivery from Infineon Technologies (the TOE Manufacturer) to the IC Embedded Software Developer is an external delivery process. This is not a delivery of the final TOE. The delivered items are the optional software libraries and the user guidance. For these items the integrity, confidentiality, and authenticity must be maintained. The delivered items are either of type documentation or software. As such, they are delivered electronically in encrypted form. ● Delivery from the IC Embedded Software Developer to the TOE Manufacturer: The delivery procedures from the IC Embedded Software Developer to the TOE Manufacturer (i.e. IFX) are described in a specific developer document. ● Delivery from the TOE Manufacturer to the Composite Product Manufacturer: The deliverables and the way of protection are described in a separate document as well as above. The delivered TOEs contain the actual TOE and the embedded software. In general, the TOE is delivered via these logistics sites: 14 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report ● DHL Singapore, ● KWE Shanghai, and ● K&N Großostheim. Regarding TOE identification: Depending on the blocking configuration, an “IFX_CCI_00007Ch, IFX_CCI_000088h, IFX_CCI_000089h, IFX_CCI_00008Ah, IFX_00008Bh G12” product can have different user available memory sizes and interface configurations. All products are identical regarding module design, layout, and footprint. In the field, the IC embedded software developer can identify a product in question using the Generic Chip Identification Mode (GCIM) (see [AGD_HRM] section 7.1.2.4.3 and [AGD_PRM] section 8.4). The design step of the TOE is also indicated by several bytes of the GCIM. Information on the exact TOE and blocking configuration are provided in the IFX-Mailbox area (see [AGD_PRM] section 8.4 / 8.11). In addition to the hardware part, the TOE consists of firmware parts and software parts. The firmware part of the TOE is identified also via the GCIM. Thereby, the exact and distinct identification of any product with its exact configuration of this TOE is given. 3. Security Policy The Security Policy is expressed by the set of Security Functional Requirements and implemented by the TOE. It covers the following issues: The security policy of the TOE is to provide basic security functionalities to be used by the smart card operating system and the smart card application, thus providing an overall smart card system security. Therefore, the TOE will implement different cryptographic algorithms to ensure the authenticity, confidentiality, and integrity of data and to support secure authentication protocols it will provide a true random number generator. Besides that, the TOE can come with the optional Hardware Support Library (HSL) providing a simplified interface for NVM management and provides the possibility to write tearing safe into the NVM. As the TOE is a hardware security platform, the security policy of the TOE is also to provide protection against leakage of information (e.g. to ensure the confidentiality of cryptographic keys during AES cryptographic functions performed by the TOE), against physical probing, against malfunctions, against physical manipulations, and against abuse of functionality. Hence, the TOE shall ● maintain the integrity and the confidentiality of data stored in the memory of the TOE, and ● maintain the integrity, the correct operation, and the confidentiality of security functionalities (security mechanisms and associated functions) provided by the TOE. Specific details concerning the above-mentioned security policies can be found in Chapters 6 and 7 of the Security Target [5] and [8]. 15 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 4. Assumptions and Clarification of Scope The Assumptions defined in the Security Target and some aspects of Threats and Organisational Security Policies are not covered by the TOE itself. These aspects lead to specific security objectives to be fulfilled by the TOE-Environment. The following topics are of relevance: Objective Description ‍ Security objectives for the operational environment from [PP0084] ‍ OE.Resp-Appl The objective states that the IC Embedded Software Developer shall treat user data (especially keys) of the composite product appropriately. The IC Embedded Software Developer gets sufficient information on how to protect user data adequately in the security guidelines [AGD_SG] and [AGD_PRM]. ‍ OE.Process-Sec-IC The objective requires the protection of the TOE, as well as of its manufacturing and test data up to the delivery to the end- consumer. As defined in [7] section 1.2.4, the TOE can be delivered to the composite product manufacturer after Phase 3 or after Phase 4. However, the actual ICs are identical in all cases. This means that the test mode is deactivated, and the TOE is locked into user mode. Therefore, it is not necessary to distinguish between these forms of delivery. Since IFX has no information about the security requirements of the implemented IC embedded software, it is not possible to define any concrete security requirements for the environment of the Composite Product Integrator and Personaliser. ‍ OE.Lim_Block_Loader The objective requires the composite product manufacturer to protect the loader against misuse, to limit the capability of the loader, and to terminate the loader irreversibly after the intended usage. The permanent deactivation of the FL is described in [AGD_PPM] section 2.2.4. This objective for the environment originates from the “Package 1: Loader dedicated for usage in secured environment only”. However, this TOE also implements “Package 2: Loader dedicated for usage by authorized users only” and thus the FL can also be used in an unsecure environment and is able to protect itself against misuse if the authentication and download keys are handled appropriately. ‍ OE.Loader_Usage The objective requires the authorised user to support the trusted communication with the TOE’s loader by protecting the confidentiality and integrity of the loaded data and to meet the access conditions defined by the loader. [AGD_PPM] section, 4 describing the FL’s personalization interface provides sufficient information regarding this topic. ‍ OE.TOE_Auth The objective requires the environment to support the authentication and verification mechanism and to know the corresponding authentication reference data. The composite 16 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report Objective Description product manufacturer receives sufficient information regarding the authentication mechanism in [AGD_PPM] section 4.1. Please note that this mechanism is based on the FL and is thus only available until the FL is permanently deactivated. ‍ Security objectives for the operational environment defined in this ST ‍ OE.Secure_UC_Load The objective requires the user software to support secure image loading in phase 7 (infield) by providing the relevant key material for the image. For a field update download the Flash Loader requires from the User-OS additional information about the update. As Infineon has no information about the security requirements of the implemented IC embedded software, it is not possible for the guidance to define any concrete security requirements for the environment of the IC Embedded Software Developer or Composite Product Manufacturer. ‍ OE.Secure_Delivery7 The objective states that, in case the Flash Loader is (temporarily) de-activated, technical and / or organisational security procedures (e.g. a custom mutual authentication mechanism or a security transport) should be put in place by the customer to secure the personalized TOE during delivery as required by the security needs of the loaded IC Embedded Software. This requirement is provided to the user as part of [AGD_PPM] Annex A: In case devices are ordered using the Infineon flashing service, the application active during transport becomes responsible for transport protection. As Infineon has no information about the security requirements of the implemented IC embedded software, it is not possible for the guidance to define any concrete security requirements for the environment of the IC Embedded Software Developer or Composite Product Manufacturer. Table 3 security objectives to be fulfilled by the TOE-Environment Details can be found in the Security Target [5] and [8], chapter 3.3. 5. Architectural Information The TOE hardware consists of a core, a memory system and peripherals. There are two separate bus entities: a memory bus and a peripheral bus for high-speed communication with the peripherals. In more detail, the TOE hardware can be further divided into: ● Processor: 7 This OE is only applicable if the conditions in the Description column apply. 17 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 ● CPU according to Armv8-M mainline architecture, ● Armv8-M compatible NVIC controller, ● Armv8-M compatible Memory Protection Unit (MPU) with 8 regions, ● Armv8-M compatible Security Attribution Unit (SAU) with 8 regions, ● Instruction Stream Signature (ISS) coprocessor, ● Fast Random Source (FRS) nonce generator coprocessor, ● EDC protected caches for memory access and instruction fetch, ● MCICE provides encryption and EDC protection for RAM, ROM, and NVM. ● Wakeup Event Controller (WEC). ● Memories: ● Encrypted and EDC-protected ROM, ● Encrypted and EDC-protected RAM, ● Encrypted and EDC-protected NVM. ● Peripherals: ● Timers, ● Watchdog, ● CRC accelerator. ● System peripherals: ● Clock unit, ● Interface Management Module (IMM), ● Power Management, ● System Peripheral Access Unit (SPAU) to manage access to peripherals, ● Memory Peripheral Access Unit (MPAU). ● Cryptographic peripherals: ● RNG according to class PTG.2 of [AIS31], ● Crypto2304T coprocessor for long modular integer arithmetic, ● SCP for secure AES and TDES computation. ● Security peripherals: ● UMSLC, ● Sensors. ● I/O Interfaces: ● UART for ISO 7816-3, ● I2C master/slave, ● Miller interface, ● ACLB Advanced Contactless Bridge, 18 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report ● GPIO ports, ● RFI contactless interface. The ROM is used by the vendor only. The user software must be implemented in the NVM. The user can choose whether the software is loaded into the NVM by Infineon Technologies AG or by the user. The firmware and software components are described in more detail in the ST [5] an [8] Section 3.1. 6. Documentation The evaluated documentation as outlined in table 2 is being provided with the product to the customer. This documentation contains the required information for secure usage of the TOE in accordance with the Security Target. Additional obligations and notes for secure usage of the TOE as outlined in chapter 10 of this report have to be followed. 7. IT Product Testing Developer’s testing approach: All TSFs and related security mechanisms, subsystems and modules are tested to assure complete coverage of all SFRs. Different classes of tests are performed to test the TOE in a sufficient manner: ● Functional verification is done using simulation tests and formal verification during TOE development. The simulation tests result in CRC checksums that are used for further testing to check that a processed TOE matches the expected results from simulation. ● Post-silicon product qualification tests are conducted in Test Mode and User Mode after production of the TOE. Here, the CRC checksums derived in simulation are used to verify the design of the processed TOE. In addition, regression tests are conducted as characterization of firmware parts of the TOE. ● For each produced TOE, production testing is conducted and aims to check the correct functionality of each produced IC. The TOE has passed all tests defined in the developer’s test plan so that all TSFs have been tested successfully. The developer’s testing results demonstrate that the TSFs behave as specified. The developer’s testing results demonstrate that the TOE behaves as expected. Independent Evaluator Testing according to ATE_IND: The evaluator's objective regarding this aspect was to test the functionality of the TOE and to verify the developer's test results by repeating developer's tests and to add independent tests. During the evaluation of the TOE, the following classes of tests were carried out: ● Module tests, ● Simulation tests, ● Emulation tests, ● Tests in user mode, 19 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 ● Tests in test mode, ● Hardware tests, and ● Optional library tests. The results of the specified and conducted independent evaluator tests confirm the TOE’s functionality. The TSF and the interfaces were found to operate as specified. The results of the developer tests, which have been repeated by the evaluator, matched the results the developer stated. Overall, the TSF has been tested against the functional specification, the TOE design, and the security architecture description. The tests demonstrate that the TSF performs as specified. Penetration Testing according to AVA_VAN: All configurations of the TOE being intended to be covered by the current evaluation were tested. The overall test result is that no deviations were found between the expected and the actual test results; moreover, no attack scenario with the attack potential high was successful in the TOE’s operational environment as defined in [5], provided that all measures required by the developer are applied. The embedded software must implement the security advice given in [AGD_HRM], [AGD_PRM], [AGD_SG], [AGD_PPM], [AGD_CryptoUM], [AGD_ES] and [AGD_CS]. Testing Summary: The tests performed by the developer were divided into the following categories: ● Simulation Tests (Design Verification), ● Qualification/Verification Tests, and ● Production Tests. The developer tests cover all security functionalities and all security mechanisms as identified in the functional specification. The evaluators were able to repeat the tests of the developer by using the library of programs, tools, and prepared chip samples delivered to the evaluators or at the developer’s site. They performed independent tests to supplement, augment, and to verify the tests performed by the developer. For the developer tests, repeated by the evaluators, other test parameters were used and the test equipment was varied. Security features of the TOE realised by specific design and layout measures were checked by the evaluators during layout inspections both in design data and on the final product. The evaluation has shown that the actual version of the TOE provides the security functionalities as specified by the developer. The test results confirm the correct implementation of the TOE security functionalities. For penetration testing, the evaluators took all security functionalities into consideration. Intensive penetration testing was planned based on the analysis results and performed for the underlying mechanisms of security functionalities. The penetration tests considered both the physical tampering of the TOE and attacks, which do not modify the TOE physically. The penetration test results confirm that the TOE is resistant to attackers with high attack potential in the intended environment for the TOE. 20 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report 8. Evaluated Configuration This certification covers the following configurations of the TOE: Smartcard IC IFX_CCI_00007Ch, IFX_CCI_000088h, IFX_CCI_000089h, IFX_CCI_00008Ah, IFX_CCI_00008Bh G12 (TSMC fab 15). The evaluation tests are performed with the chip IFX_CCI_00007Ch, IFX_CCI_000088h, IFX_CCI_000089h, IFX_CCI_00008Ah, IFX_CCI_00008Bh G12, produced by TSMC fab 15 in Taiwan. The identifiers IFX_CCI_00007Ch, IFX_CCI_000088h, IFX_CCI_000089h, IFX_CCI_00008Ah, IFX_CCI_00008Bh G12 may differ from each other only in terms of blocked modules: They are still physically present on the TOE, but not accessible. Thus, the tests were performed on a TOE without any blocked features. This TOE is represented by various configurations called products. The module design, layout, and footprint, of all products are identical. The degree of freedom for configuring the TOE is predefined by the developer. For specific configuration options, see [5], section 1.4.6. 9. Results of the Evaluation 9.1. CC specific results The Evaluation Technical Report (ETR) [6] was provided by the ITSEF according to the Common Criteria [1], the Methodology [2], the requirements of the Scheme [3] and all interpretations and guidelines of the Scheme (AIS) [4] as relevant for the TOE. The Evaluation Methodology CEM [2] was used for those components up to EAL 5 extended by advice of the Certification Body for components beyond EAL 5 and guidance specific for the technology of the product [4] (AIS 34). The following guidance specific for the technology was used: ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 1, Durchführung der Ortsbesichtigung in der Entwicklungsumgebung des Herstellers, Version 14, 2017- 10-11, Bundesamt für Sicherheit in der Informationstechnik. ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 14, Anforderungen an Aufbau und Inhalt der ETR-Teile (Evaluation Technical Report) für Evaluationen nach CC (Common Criteria), Version 7, 2010-08-03, Bundesamt für Sicherheit in der Informationstechnik. ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 19, Anforderungen an Aufbau und Inhalt der Zusammenfassung des ETR (Evaluation Technical Report) für Evaluationen nach CC (Common Criteria), Version 9, 2014-11-03, Bundesamt für Sicherheit in der Informationstechnik. ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 20, Funktionalitätsklassen und Evaluationsmethodologie für deterministische Zufallszahlengeneratoren, Version 3, 2013-05-15, Herausgeber: Zertifizierungsstelle des BSI im Rahmen des Zertifizierungsschemas, Bundesamt für Sicherheit in der Informationstechnik. ● A proposal for: Functionality classes for random number generators, W. Killmann, W. Schindler, Version 2.0, 2011-09-18, T-Systems GEI GmbH and Bundesamt für Sicherheit in der Informationstechnik. (same as [KS2011]) 21 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 ● Developer evidence for the evaluation of a deterministic random number generator, Version 0.9, 2013-02-28, Bundesamt für Sicherheit in der Informationstechnik. ● Evaluation Report as part of the Evaluation Technical Report, Part B – ETR-Part Deterministic Random Number Generator, Template-Version 0.10, 2013-02-28, Bundesamt für Sicherheit in der Informationstechnik. ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 23, Zusammentragen von Nachweisen der Entwickler, Version 4, 2017-03-15, Bundesamt für Sicherheit in der Informationstechnik. ● Joint Interpretation Library – Collection of Developer Evidence, Version 1.5, January 2012. ● Application Notes and Interpretation of the Scheme (AIS) – AIS 25, Anwendungen der CC auf integrierte Schaltungen, Version 9, 2017-03-15, Bundesamt für Sicherheit in der Informationstechnik. ● CC Supporting Document Mandatory Technical Document – Security Architecture requirements (ADV_ARC) for smart cards and similar devices, Version 2.1, April 2014, CCDB-2012-04-004. ● Security Architecture requirements (ADV_ARC) for smart cards, and similar devices extended to Secure Sub-Systems in SoC, Version 2.1, 2021-07, Joint Interpretation Working Group. ● CC Supporting Document Mandatory Technical Document – The Application of CC to Integrated Circuits, Version 3.0, Revision 1, March 2009, CCDB-2009-03-002. ● Security Architecture requirements (ADV_ARC) for smart cards, and similar devices extended to Secure Sub-Systems in SoC – Appendix 1, Version 2.1, 2021-07, Joint Interpretation Working Group. ● Joint Interpretation Library – The Application of CC to Integrated Circuits, Version 3.0, February 2009. ● Security requirements for post-delivery code loading, Version 2.0, 2024-09, Joint Interpretation Working Group. ● Validity of conducted tests on Security Smart Card ICs in dependence of test date, Version 1, 2017-03-15, Bundesamt für Sicherheit in der Informationstechnik. ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 26, Evaluationsmethodologie für in Hardware Integrierte Schaltungen, Version 10, 2017-07- 03, Bundesamt für Sicherheit in der Informationstechnik. ● Auswahl geeigneter Chips für DPA-Messungen, Version 1.1, 2008-12-07, Bundesamt für Sicherheit in der Informationstechnik. ● Special Attack Methods for Smartcards and Similar Devices, Version 1.4, 2011-06-08, Bundesamt für Sicherheit in der Informationstechnik. ● CC Supporting Document Mandatory Technical Document – Requirements to perform Integrated Circuit Evaluations, Version 1.1, May 2013, CCDB-2013-05-001. ● Joint Interpretation Library – Application of Attack Potential to Smartcards, Version 3.2.1, 02-2024. ● Joint Interpretation Library – Attack Methods for Smartcards and Similar Devices, Version 2.4, 2020, confidential. 22 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report ● Joint Interpretation Library – Requirements to perform Integrated Circuit Evaluations, Version 1.1, February 2013. ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 31, Funktionalitätsklassen und Evaluationsmethodologie für physikalische Zufallszahlengeneratoren, Version 3, 2013-05-15, Bundesamt für Sicherheit in der Informationstechnik. ● Developer evidence for the evaluation of a physical true random generator, Version 0.8, 2013-02-28, Bundesamt für Sicherheit in der Informationstechnik. ● Evaluation Report as part of the Evaluation Technical Report, Part B – ETR-Part True Physical and Hybrid Random Number Generator, Template-Version 0.7, 2013-02-28, Bundesamt für Sicherheit in der Informationstechnik. ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 32, CC- Interpretationen im deutschen Zertifizierungsschema, Version 7, 2011-06-08, Bundesamt für Sicherheit in der Informationstechnik. ● Application Notes and Interpretation of the Scheme (AIS) – AIS 34, Evaluation Methodology for CC Assurance Classes for EAL5+ (CC v2.3 & v3.1) and EAL6 (CC v3.1), Version 3, 2009-09-03, Bundesamt für Sicherheit in der Informationstechnik. ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 35, Öffentliche Fassung eines Security Target (ST-lite), Version 2, 2007-11-12, Bundesamt für Sicherheit in der Informationstechnik. ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 36, Kompositionsevaluierung, Version 5, 2017-03-15, Bundesamt für Sicherheit in der Informationstechnik. ● CC Supporting Document Mandatory Technical Document – Composite product evaluation for Smart Cards and similar devices, Version 1.4, December 2015, CCDB-2015-12-001. ● Joint Interpretation Library – Composite product evaluation for Smart Cards and similar devices, Version 1.5.1, May 2018. ● CC Supporting Document Guidance – ETR template for composite evaluation of Smart Cards and similar devices, Version 1.1, December 2015, CCDB-2015-12-002. ● Joint Interpretation Library – ETR template for composite evaluation of Smart Cards and similar devices, Version 1.1, August 2015. ● Joint Interpretation Library – Certification of “open” smart card products, Version 2.0, 2024-05. ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 37, Terminologie und Vorbereitung von Smartcard-Evaluierungen, Version 3, 2010-05-17, Bundesamt für Sicherheit in der Informationstechnik. ● CC Supporting Document Guidance – Smartcard Evaluation, Version 2.0, February 2010, CCDB-2010-03-001. ● Application Notes and Interpretation of the Scheme (AIS) – AIS 38, Reuse of evaluation results, Version 2, 2007-09-28, Bundesamt für Sicherheit in der Informationstechnik. ● Application Notes and Interpretation of the Scheme (AIS) – AIS 39, Formal Methods, Version 3, 2008-10-24, Bundesamt für Sicherheit in der Informationstechnik. 23 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 ● Application Notes and Interpretation of the Scheme (AIS) – AIS 41, Guidelines for PPs and STs, Version 2, 2011-01-31, Bundesamt für Sicherheit in der Informationstechnik. ● Guidance Document – The PP/ST Guide, Version 2, Revision 0, 2010-08, Bundesamt für Sicherheit in der Informationstechnik. ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 46, Informationen zur Evaluierung von kryptographischen Algorithmen und ergänzende Hinweise für die Evaluierung von Zufallszahlengeneratoren, Version 3, 2013-12-04, Bundesamt für Sicherheit in der Informationstechnik. ● Review-Protokoll zum (Krypto-)AVA-KickOff, Template-Version/Date: 2019-08-23, Bundesamt für Sicherheit in der Informationstechnik. ● Guidelines for Evaluating Side-Channel and Fault Attack Resistance of Elliptic Curve Implementations, Version 3.0, February 29, 2024, BSI. ● Methodology for cryptographic rating of memory encryption schemes used in smartcards and similar devices, Version 1.0, 2013-10-31, BSI. ● Guidelines for Evaluating Side-Channel-Attack Resistance of RSA, DSA and Diffie- Hellman Key Exchange Implementations, Version 2024-01, February 29, 2024, BSI. ● Anwendungshinweise und Interpretationen zum Schema (AIS) – AIS 47, Regelungen zu Site Certification, Version 1.1, 2013-12-04, Bundesamt für Sicherheit in der Informationstechnik. ● Guidance for Site Certification, Version 1.1, 2013-12-04, Bundesamt für Sicherheit in der Informationstechnik. ● Joint Interpretation Library – Minimum Site Security Requirements, Version 3.1, 12/2023. (see [4] for respective AIS references). For RNG assessment the scheme interpretations AIS 31 was used (see [4]). To support composite evaluations according to AIS 36 the document ETR for composite evaluation [9] was provided and approved. This document provides details of this platform evaluation that have to be considered in the course of a composite evaluation on top. As a result of the evaluation the verdict PASS is confirmed for the following assurance components: ● All components of the EAL 6 package including the class ASE as defined in the CC (see also part C of this report) ● The components ALC_FLR.1 and ATE_SDP.1 augmented for this TOE evaluation. As the evaluation work performed for this certification procedure was carried out as a re- evaluation based on the certificate BSI-DSZ-CC-1252-2025, re-use of specific evaluation tasks was possible. The focus of this re-evaluation was on: ● The Identifier IFX_CCI_00008Bh was added to the scope. The TOE is represented by various configurations called products, while the module design, layout, and footprint of all products are identical. The identifier IFX_CCI_00008Bh represents another configuration of the TOE in the limits of the already certified TOE (BSI-DSZ- CC-1252-2025). ● The functionality ML-KEM and ML-DSA were added to the scope with their respective SFRs. 24 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report ● The functionality AES GCM and CCM mode were added to the scope with their re- spective SFRs. ● The functionality HwrngAlg_PTG3_Sec1 and HwrngAlg_DRG4_Sec1 were added to the scope as services to FCS_RNG.1/CS/PTG3 and FCS_RNG/CS/DRG4 respectively. ● There are no changes to the firmware, software or guidance documentation. The evaluation has confirmed: ● PP Conformance: Security IC Platform Protection Profile with Augmentation Packages Version 1.0, 13 January 2014, BSI-CC-PP-0084- 2014 [7] ● for the Functionality: PP conformant plus product specific extensions Common Criteria Part 2 extended ● for the Assurance: Common Criteria Part 3 extended EAL 6 augmented by ALC_FLR.1 and ATE_SDP.1 The results of the evaluation are only applicable to the TOE as defined in chapter 2 and the configuration as outlined in chapter 8 above. 9.2. Results of cryptographic assessment The strength of the cryptographic algorithms was not rated in the course of this certification procedure (see BSIG Section 9, Para. 4, Clause 2). But cryptographic functionalities with a security level of lower than 120 bits can no longer be regarded as secure without considering the application context. Therefore, for these functionalities it shall be checked whether the related crypto operations are appropriate for the intended system. Some further hints and guidelines can be derived from the 'Technische Richtlinie BSI TR-02102' (https://www.bsi.bund.de). The following table gives an overview of the cryptographic functionalities inside the TOE to enforce the security policy and outlines its rating from cryptographic point of view. Any Cryptographic Functionality that is marked in column 'Security Level above 120 Bits' of the following table with 'no' achieves a security level of lower than 120 Bits (in general context) only. 25 / 47 # Purpose Cryptographic mechanism Implementation standard Key size in bits ‍ Security level above 120 bits ‍ Comments Symmetric coprocessor (SCP)‍ 1 Cryptogr aphic primitive TDES [NIST_SP800- 67_2017] 112, 168 ‍ -- ‍ Cryptographic Primitives might have various use case scenarios not explicitly specified on HW platform level (e.g. confidentiality, integrity, authenticity etc.). Hence no rating on “security level > 120 bits” but considered according to AVA_VAN.5 penetration testing.‍ 2 Cryptogr aphic primitive AES [FIPS197] 128, 192, 256 ‍ -- 3 Confiden tiality #1 in ECB mode for encryption and decryption [NIST_SP800-38A] 112, 168 ‍ No ‍ “No” is for ECB mode in general for all implementation s and certification procedures.‍ 4 Confiden tiality #2 in ECB mode for encryption and decryption [NIST_SP800-38A] 128, 192, 256 ‍ No CryptoSuite: symmetric functionality‍ 5 Cryptogr aphic primitive TDES [NIST_SP800- 67_2017] 112, 168 ‍ -- ‍ Cryptographic Primitives might have 26 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report # Purpose Cryptographic mechanism Implementation standard Key size in bits ‍ Security level above 120 bits ‍ Comments various use case scenarios not explicitly specified on HW platform level (e.g. confidentiality, integrity, authenticity etc.). Hence no rating on “security level > 120 bits” but considered according to AVA_VAN.5 penetration testing.‍‍ 6 Cryptogr aphic primitive AES [FIPS197] 128, 192, 256 ‍ -- 7 Confiden tiality #5 in ECB mode for encryption and decryption [NIST_SP800-38A] 112, 168 ‍ No ‍ “No” is for ECB mode in general for all implementation s and certification procedures. 8 Confiden tiality #5 in CBC mode for encryption and decryption [NIST_SP800-38A] 112, 168 ‍ CBC-168: Yes, CBC-112: No. ‍ -- 9 Confiden tiality #5 in CTR mode for encryption and decryption [NIST_SP800-38A] 112, 168 ‍ CTR-168: Yes, CTR-112: No. ‍ -- 10 Confiden tiality #6 in ECB mode for encryption and decryption [NIST_SP800-38A] 128, 192, 256 ‍ No ‍‍ “No” is for ECB mode in general for all implementation s and certification procedures. 11 Confiden tiality #6 in CBC mode for encryption and decryption [NIST_SP800-38A] 128, 192, 256 ‍ Yes ‍ -- 12 Confiden tiality #6 in CTR mode for encryption and decryption [NIST_SP800-38A] 128, 192, 256 ‍ Yes ‍ -- 27 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 # Purpose Cryptographic mechanism Implementation standard Key size in bits ‍ Security level above 120 bits ‍ Comments 13 Confiden tiality #6 in CCM mode for encryption and decryption [NIST_SP800-38C] 128, 192, 256 Yes -- 14 Confiden tiality #6 in GCM mode for encryption and decryption [NIST_SP800-38D] 128, 192, 256 Yes -- 15 Integrity #5 in Retail MAC mode for MAC generation [ISO_9797-1_2011] 112 ‍ No “No” is for Retail Mac mode in general for all implementation s and certification procedures.‍ 16 Integrity #5 in CBC MAC mode for MAC generation [ISO_9797-1_2011] padding method 2 112, 168 ‍ No ‍ “No” is for CBC-MAC mode in general for all implementation s and certification procedures. 17 Integrity #6 in CMAC mode for MAC generation [NIST_SP800-38B] 128, 192, 256 ‍ Yes ‍ -- 18 Integrity #6 in CBC MAC mode for MAC generation [ISO_9797-1_2011] padding method 2 128, 192, 256 ‍ No ‍ “No” is for CBC-MAC mode in general for all implementation s and certification procedures. 28 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report # Purpose Cryptographic mechanism Implementation standard Key size in bits ‍ Security level above 120 bits ‍ Comments CryptoSuite: asymmetric functionality‍ 19 N/A FFC domain parameters:  1024-bit MODP Group with 160-bit Prime Order Subgroup  2048-bit MODP Group with 224-bit Prime Order Subgroup  2048-bit MODP Group with 256-bit Prime Order Subgroup [RFC5114] N/A ‍ -- ‍ -- 20 Key agreeme nt Finite-Field Diffie- Hellman computation using domain parameters listed in #17 [NIST_SP800-56A, 5.7.1.1] without step 2, 1024- 2048 ‍ N/A8 --‍ 21 Key generati on Finite-Field key generation for domain parameters listed in #17 [NIST_SP800-56A, 5.6.1.1] 1024- 2048 ‍ N/A8 ‍ -- 22 N/A Montgomery elliptic curves:  Curve25519, Curve448 [RFC7748] N/A ‍ -- ‍ -- 23 Key agreeme nt X25519 using Curve25519 [RFC7748] 256 ‍ N/A8 ‍ -- 24 Key agreeme nt X448 using Curve448 [RFC7748] 448 ‍‍ N/A8 ‍ -- 8 „N/A“ means: No explicit rating on “security level > 120 bits” but implemented according to the listed standard and evaluated with AVA_VAN.5 penetration testing. 29 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 # Purpose Cryptographic mechanism Implementation standard Key size in bits ‍ Security level above 120 bits ‍ Comments 25 Confiden tiality RSA encryption [PKCS#1_2012, 5.1. 1], [NIST_SP800-56B, 7.1.1] 1024 – 4224 ‍‍ For Keysize >=2000 bit: security level >=100bit Yes to 120bit for >= 2800 bit only. ‍ -- 26 Confiden tiality RSA decryption [PKCS#1_2012, 5.1. 2 2a], [NIST_SP800-56B, 7.1.2.1] 1024 – 2112 ‍ -- 27 Confiden tiality RSA decryption with CRT [PKCS#1_2012, 5.1. 2 2b], [NIST_SP800-56B, 7.1.2.3] 1024 – 4224 ‍ -- 28 Authenti city RSA signature generation9 [PKCS#1_2012, 5.2. 1 2a] 1024 – 2112 ‍ For Keysize >=2000 bit: security level >=100bit ‍ -- 29 Authenti city RSA signature generation with CRT4 [PKCS#1_2012, 5.2. 1 2b] 1024 – 4224 ‍ Yes for >= 2800 bit ‍ -- 30 Authenti city RSA signature verification4 [PKCS#1_2012, 5.2. 2] 1024 – 4224 ‍ Yes for >= 2800 bit ‍ -- 31 Key generati on Generation of probably random primes p and q for RSA keys [FIPS186-5, A.1.3] without step 1 1024- 4128 ‍ N/A8 Only conformant for key size bitlength >= 2048; in case keysize Bitlength < 2048 identical algorithm is used, but considered proprietary Method: “Ccc_Rsa_Key GenPQ”. 9 Note that the hash calculation is not implemented by the library and lies in the responsibility of the user. 30 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report # Purpose Cryptographic mechanism Implementation standard Key size in bits ‍ Security level above 120 bits ‍ Comments 32 Key generati on Generation of RSA’s N and d parameters from p, q [FIPS186-5, A.1.1], [PKCS#1_2012, 3.1 / 3.2(1)], 1024 – 4224 ‍ N/A8 ‍ Method: “Ccc_Rsa_Key GenN + Ccc_Rsa_Key GenD” 33 Key generati on Generation of RSA CRT parameters from p, q [FIPS186-5, A.1.1], [PKCS#1_2012, 3.1 / 3.2(2)] 1024 – 4224 ‍ N/A8 Method: “Ccc_Rsa_Key GenCrt”‍ 34 Primality testing Miller-Rabin primality test [FIPS186-5, B.3.1] 512 – 2064 (prime length) ‍ N/A8 (Prime candidate length)‍ 35 Primality testing Enhanced Miller- Rabin primality test [FIPS186-5, B.3.2] 512 – 2064 (prime length) ‍ N/A8 (Prime candidate length)‍ 36 N/A Weierstrass elliptic curves:  all NIST curves over prime fields in [NIST_SP800 -186],  all Brainpool curves of [RFC5639],  secp160k1, secp160r1, secp160r2, secp256k1 of [SEC2_2010],  ANSII FRP256V1 of [ANSSI],  BN P256 of [ISO_15946- 5], and  W-25519, W-448 of [NIST_SP800 -186]. [NIST_SP800-186], [RFC5639], [SEC2_2010], [ANSSI], [ISO_15946-5] N/A ‍ “No” for BN P256 in [ISO_159 46, 7.3] in general case, “not rated w.r.t. 120 bits” in specific cases. ‍ -- 31 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 # Purpose Cryptographic mechanism Implementation standard Key size in bits ‍ Security level above 120 bits ‍ Comments 37 Authenti city ECDSA signature generation on curves listed in #344 [FIPS186-5, 6.4.1] 160 – 521 ‍ Key size 160,163,1 92, 224: No Key sizes >=250: Yes ‍ (Note that the hash calculation of ECDSA is not implemented by the library and lies in the responsibility of the user.) 38 Authenti city ECDSA signature verification on curves listed in #344 [FIPS186-5, 6.4.2] 160 – 521 ‍ Key size 160,163,1 92, 224: No Key sizes >=250: Yes ‍ (Note that the hash calculation of ECDSA is not implemented by the library and lies in the responsibility of the user.) 39 Key agreeme nt Elliptic Curve Diffie-Hellman (ECDH) key agreement on curves listed in #34 [NIST_SP800-56A, 5.7.1.2] without cofactor multiplication 160 – 521 ‍ Key size 160,163,1 92, 224: No Key sizes >=250: Yes ‍ -- 40 N/A PACE integrated mapping on curves listed in #34 [ICAO_11, Appendix B.2] 160 – 521 ‍ N/A8 -- 41 Key generati on ECDSA key generation on curves listed in #34 [FIPS186-5, A.2.1] 160 – 521 ‍ N/A8 -- 42 Authenti city ECSDSA signature generation on curves listed in #34 [ISO_14888- 3_2018, 6.10.4], [TR-03111_2018, 4.2.3], 160 – 521 ‍ N/A8 -- 43 Authenti city ECSDSA signature verification on curves listed in #34 [ISO_14888- 3_2018, 6.10.5], [TR-03111_2018, 4. 2.3] 160 – 521 ‍ N/A8 -- 32 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report # Purpose Cryptographic mechanism Implementation standard Key size in bits ‍ Security level above 120 bits ‍ Comments 44 Key generati on ECSDSA key generation on curves listed in #34 [ISO_14888- 3_2018, 6.10.3] 160 – 521 ‍ N/A8 45 N/A Edwards curves:  Ed25519, Ed448 [NIST_SP800-186] N/A ‍ -- ‍ -- 46 Authenti city EdDSA signature generation on curves listed in #43 [FIPS186-5, 7.6] 256, 456 ‍ N/A8 -- 47 Authenti city EdDSA signature verification on curves listed in #43 [FIPS186-5, 7.7] 256, 456 ‍ N/A8 -- 48 Authenti city EdDSA pre-hash signature generation4 on curves listed in #43 [FIPS186-5, 7.8.1] 256, 456 ‍ N/A8 -- 49 Authenti city EdDSA pre-hash signature verification4 on curves listed in #43 [FIPS186-5, 7.8.2] 256, 456 ‍ N/A8 -- 50 Key generati on Elliptic Curve key generation on curves listed in #43 [FIPS186-5, A.2.3] 256, 456 ‍ N/A8 --‍ CryptoSuite: hashing functionality‍ 51 Hash SHA-1 [FIPS180-4] N/A ‍ -- ‍ -- 52 Hash SHA2-256, SHA2-256, SHA2-384, SHA2-512, SHA2-512/224, SHA2-512/256 [FIPS180-4] N/A ‍ -- ‍ -- 53 Hash SHA3-224, SHA3-256, SHA3-384, SHA3-512 [FIPS202, 6.1] N/A ‍ -- ‍ -- 54 XOF SHAKE-128, SHAKE-256 [FIPS202, 6.2] N/A ‍ -- ‍ -- 33 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 # Purpose Cryptographic mechanism Implementation standard Key size in bits ‍ Security level above 120 bits ‍ Comments 55 HMAC HMAC generation using SHA-1, SHA2-256, SHA2-384, SHA2-512 [FIPS180-4], [FIPS198-1] 160, 256, 384, 512 ‍ SHA-1: No. “No” is for SHA-1 mode in general for all implementation s and certification procedures.‍ Hardware RNG‍ 56 RNG Physical RNG N/A; corresponds to PTG.2 in [KS2011] N/A ‍ -- ‍ -- CryptoSuite: RNG functionality‍ 57 RNG Physical RNG N/A; corresponds to class PTG.2 in [KS2011] N/A ‍ -- ‍ -- 58 RNG Physical RNG with cryptographic post-processing Post-processing based on [NIST_SP800-90A] CTR_DRBG; corresponds to PTG.3 in [KS2011] and [NIST_SP800- 90A] CTR_DR BG uses AES-128 or AES-256 ‍ N/A8 ‍ Post- processing based on [NIST SP800- 90A] CTR_DRBG. 59 RNG Deterministic RNG CTR_DRBG as specified in [NIST_SP800-90A]; corresponds to DRG.3 in [KS2011] CTR_DR BG uses AES-128 or AES-256 ‍ N/A8 ‍ Implementation according to CTR_DRBG specified in [NIST SP800- 90A] 60 RNG Hybrid deterministic RNG Post-processing based on [NIST_SP800-90A] CTR_DRBG; corresponds to DRG.4 in [KS2011] and [NIST_SP800- 90A] CTR_DR BG uses AES-128 or AES-256 ‍ N/A8 ‍ Post- processing based on [NIST SP800- 90A] CTR_DRBG. 61 RNG Physical RNG with crypto- graphic post- processing Proprietary Post- processing; cor- responds to PTG.3 in [KS2011] uses AES-128 Not rated -- 62 RNG Physical RNG with crypto- graphic post- processing Proprietary Post- processing; cor- responds to DRG.4 in [KS2011] uses AES-128 Not rated -- 34 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report # Purpose Cryptographic mechanism Implementation standard Key size in bits ‍ Security level above 120 bits ‍ Comments Flash Loader‍ 63 Cryptogr aphic primitive AES [FIPS197] 128 ‍ -- ‍ -- 64 Authenti cated encrypti on #59 in CCM mode [NIST_SP800-38C] 128 ‍ N/A8 -- 65 Authenti cation #59 in CMAC mode [NIST_SP800-38B] 128 ‍ N/A8 -- 66 Key derivatio n KDF in counter mode with AES CMAC as PRF [NIST_SP800-108, 4.1], [NIST_SP800-38B, 6.2] 128 ‍ N/A8 ‍ -- Table 4: TOE cryptographic functionality 35 / 47 # Purpose Cryptographic mechanism Implementation standard Parameter size ‍ Security level above 120 bits ‍ Comments 67 Key generation ML-KEM key generation with random seed [FIPS203, 6.1] ML- KEM-512, ML- KEM-768, ML- KEM-1024 Not rated, Yes, Yes 68 ML-KEM key generation with provided seed [FIPS203, 6.1], Proprietary implementation ML- KEM-512, ML- KEM-768, ML- KEM-1024 Not rated, Yes, Yes Proprietary implementation: optionally generate a key by using a seed parameter instead of using a random number generator. 69 ML-DSA key generation with random seed [FIPS204, 5.1] ML-DSA-44, ML-DSA-65, ML-DSA-87 Not rated, Yes Yes 70 ML-DSA key generation with provided seed [FIPS204, 5.1], Proprietary implementation ML-DSA-44, ML-DSA-65, ML-DSA-87 Not rated, Yes Yes Proprietary implementation: optionally generate a key by using a seed parameter instead of using a random number generator. 71 Key encapsulati on ML-KEM key encapsulation [FIPS203, 6.2] ML- KEM-512, ML- KEM-768, ML- KEM-1024 Not rated, Yes Yes 72 Key decapsulati on ML-KEM key decapsulation [FIPS203, 6.3] ML- KEM-512, ML- KEM-768, ML- KEM-1024 Not rated, Yes Yes 36 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report # Purpose Cryptographic mechanism Implementation standard Parameter size ‍ Security level above 120 bits ‍ Comments 73 Authenticity ML-DSA signature generation [FIPS204, 5.2 / 5.4] ML-DSA-44, ML-DSA-65, ML-DSA-87 Not rated, Yes Yes 74 ML-DSA signature verification [FIPS204, 5.3 / 5.4] ML-DSA-44, ML-DSA-65, ML-DSA-87 Not rated, Yes Yes Table 5: TOE Quantum ready Asymetric Please take into account the following additional information: ● Conformance evaluation and assessment to claimed cryptographic functionality standards, as required by Common Criteria Part 1 section A.13, is documented in the confidential report “Cryptographic Standards Compliance Verification” [18]. ● The Flash Loader's cryptographic strength was also not assessed by BSI. However, the evaluation of the Flash Loader’s implementation strength according to the TOE's Evaluation Assurance Level (including AVA_VAN.5) did not reveal any implementation weaknesses. The references within table 3 are as follows: [ANSSI] Avis relatif aux paramètres de courbes elliptiques définis par l'Etat français, 2011-10-16, Journal Officiel de la République Française (JORF) [FIPS197] Federal Information Processing Standards Publication PUB 197, Ad- vanced Encryption Standard (AES), Updated Version, 2023-05-09, National Institute of Standards and Technology (NIST) [FIPS198-1] FIPS PUB 198-1 Federal Information Processing Standards Publica- tion, The Keyed-Hash Message Authentication Code (HMAC), 2008-07, National Institute of Standards and Technology (NIST). [FIPS202] FIPS PUB 202 Federal Information Processing Standards Publica-tion, SHA-3 Standard: Permutation-Based Hash and Extendable-Out-put Functions, 2015-08, National Institute of Standards and Technol-ogy (NIST) [NIST_SP800-38A] NIST Special Publication 800-38A – Recommendation for Block Cipher Modes of Operation – Methods and Techniques, 2001-12, National Institute of Standards and Technology (NIST) [NIST_SP800-38B] NIST Special Publication 800-38B – Recommendation for Block Cipher Modes of Operation – The CMAC Mode for Authentication, Updated Version, 2016-10-06, National Institute of Standards and Technology (NIST) [NIST_SP800-38C] NIST Special Publication 800-38C – Recommendation for Block Cipher Modes of Operation – The CCM Mode for Authentication 37 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 and Confidentiality, Errata Updated Version, 2007-07-20, National Institute of Standards and Technology (NIST) [NIST_SP800-56A] NIST Special Publication 800-56A – Recommendation for Pair- Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography, 2018-04, National Institute of Standards and Technology (NIST) [NIST_SP800-56B] NIST Special Publication 800-56B Revision 2 – Recommendation for Pair-Wise Key Establishment Using Integer Factorization Cryptography, 2019-03, National Institute of Standards and Technology (NIST) [NIST_SP800-67_2017] NIST Special Publication 800-67 – Revision 2 – Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, rev. 2, 2017-11, National Institute of Standards and Technology (NIST) [NIST_SP800-90A] NIST Special Publication 800-90A – Revision 1 – Recommendation for Random Number Generation Using Deterministic Random Bit Generators, rev. 1, 2015-06, National Institute of Standards and Technology (NIST) [NIST_SP800-108] NIST Special Publication 800-108 (NIST SP 800-108r1) – Recommendation for Key Derivation Using Pseudorandom Functions, 2022-08, National Institute of Standards and Technology (NIST) [NIST_SP800-186] NIST Special Publication 800-186 – Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters 2023-02, National Institute of Standards and Technology (NIST) [ICAO_11] ICAO Doc 9303, Machine Readable Travel Document, eighth edition, 2021, Part 11: Security Mechanisms for MRTDs [ISO_9797-1_2011]Information technology - Security techniques - Message Authentication Codes (MACs) - Part 1: Mechanisms using a block cipher, 2011-03, ISO/IEC [ISO_14888-3_2018]ISO/IEC 14888-3, IT Security techniques – Digital signatures with appendix – Part 3: Discrete logarithm based mechanisms, 2018-11, ISO/IEC [ISO_15946-5]ISO/IEC 15946-5: Information security — Cryptographic techniques based on elliptic curves Part 5: Elliptic curve generation, 2022-02, ISO/IEC [KS2011] A proposal for: Functionality classes for random number generators, W. Killmann, W. Schindler, Version 2.0, 2011-09-18, T-Systems GEI GmbH and Bundesamt für Sicherheit in der Informationstechnik. [PKCS#1] PKCS #1: RSA Cryptography Standard, Version 2.2, October 27, 2012, RSA Laboratories. [RFC5114] RFC 5114 - Additional Diffie-Hellman Groups for Use with IETF Standards, 2008-01, The Internet Engineering Task Force (IETF), http://www.ietf.org/rfc/rfc5114.txt 38 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report [RFC5639] RFC 5639 - Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, 2010-03, M. Lochter (BSI), J. Merkle (secunet Security Networks), The Internet Engineering Task Force (IETF), http://www.ietf.org/rfc/rfc5639.txt [RFC7748] RFC 7748 - Elliptic Curves for Security, 2016-01, The Internet Engi- neering Task Force (IETF), http://www.ietf.org/rfc/rfc7748.txt [SEC2_2010]Standards For Efficient Cryptography – SEC 2: Recommended Elliptic Curve Domain Parameters, Version 2.0, 2010, Certicom Research [TR-03111] BSI - Technical Guideline BSI TR-03111 - Elliptic Curve Crypto-graphy, Version 2.10, 2018-06-01, Bundesamt für Sicherheit in der Informationstechnik 10. Obligations and Notes for the Usage of the TOE The documents as outlined in table 2 contain necessary information about the usage of the TOE and all security hints therein have to be considered. In addition all aspects of Assumptions, Threats and OSPs as outlined in the Security Target not covered by the TOE itself need to be fulfilled by the operational environment of the TOE. The customer or user of the product shall consider the results of the certification within his system risk management process. In order for the evolution of attack methods and techniques to be covered, he should define the period of time until a re-assessment of the TOE is required and thus requested from the sponsor of the certificate. The limited validity for the usage of cryptographic algorithms as outlined in chapter 9 has to be considered by the user and his system risk management process, too. Some security measures are partly implemented in this certified TOE, but require additional configuration or control or measures to be implemented by a product layer on top, e.g. the [Auswahl im Einzelfall: IC Dedicated Support Software and/or Embedded Software] using the TOE. For this reason the TOE includes guidance documentation (see table 2) which contains obligations and guidelines for the developer of the product layer on top on how to securely use this certified TOE and which measures have to be implemented in order to fulfil the security requirements of the Security Target of the TOE. In the course of the evaluation of the composite product or system it must be examined if the required measures have been correctly and effectively implemented by the product layer on top. Additionally, the evaluation of the composite product or system must also consider the evaluation results as outlined in the document "ETR for composite evaluation" [9]. At the point in time when evaluation and certification results are reused there might be an update of the document "ETR for composite evaluation" available. Therefore, the certified products list on the BSI website has to be checked for latest information on reassessments, recertifications or maintenance result available for the product. Requirements for the Usage of the Evaluated Product: The TOE is delivered to the composite product manufacturer and to the security IC embedded software developer. The actual end-consumer obtains the TOE from the composite product issuer together with the application that runs on the TOE. 39 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 The security IC embedded software developer receives all necessary recommendations and hints to develop his software in form of the delivered documentation. ● All security hints described in the delivered documents in [11] – [16], [18] must be considered. The composite product manufacturer receives all necessary recommendations and hints to develop his software in form of the delivered documentation. ● All security hints described in [11] – [16], [18] (if applicable) must be considered. In addition, the following hints resulting from the ASE and ALC evaluation aspect must be considered: ● The security IC embedded software developer can deliver their software either to Infineon to let them implement it in the TOE (in the NVM) or to the composite product manufacturer to let them download the software into the NVM. ● The delivery procedure from the security IC embedded software developer to the com- posite product manufacturer is not part of this evaluation and a secure delivery is re- quired. ● The delivery procedure from the TOE manufacturer (IFX) to the composite product manufacturer is not part of this evaluation. However, for security reasons, a form of transport protection might be required depending on the order option (see Section 2.1 for details). The applied transport protection mechanisms must be considered during the composite evaluation considering the security needs of any pre-loaded IC Embedded Software that is active during delivery. 11. Security Target For the purpose of publishing, the Security Target [8] of the Target of Evaluation (TOE) is provided within a separate document as Annex A of this report. It is a sanitised version of the complete Security Target [5] used for the evaluation performed. Sanitisation was performed according to the rules as outlined in the relevant CCRA policy (see AIS 35 [4]). 12. Regulation specific aspects (eIDAS, QES) None 13. Definitions 13.1. Acronyms AIS Application Notes and Interpretations of the Scheme BSI Bundesamt für Sicherheit in der Informationstechnik / Federal Office for Information Security, Bonn, Germany BSIG BSI-Gesetz / Act on the Federal Office for Information Security CCRA Common Criteria Recognition Arrangement CC Common Criteria for IT Security Evaluation CEM Common Methodology for Information Technology Security Evaluation cPP Collaborative Protection Profile 40 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report EAL Evaluation Assurance Level ETR Evaluation Technical Report IT Information Technology ITSEF Information Technology Security Evaluation Facility PP Protection Profile SAR Security Assurance Requirement SFR Security Functional Requirement ST Security Target TOE Target of Evaluation TSF TOE Security Functionality 13.2. Glossary Augmentation – The addition of one or more requirement(s) to a package. Collaborative Protection Profile – A Protection Profile collaboratively developed by an International Technical Community endorsed by the Management Committee. Extension – The addition to an ST or PP of functional requirements not contained in CC part 2 and/or assurance requirements not contained in CC part 3. Formal – Expressed in a restricted syntax language with defined semantics based on well- established mathematical concepts. Informal – Expressed in natural language. Object – A passive entity in the TOE, that contains or receives information, and upon which subjects perform operations. Package – named set of either security functional or security assurance requirements Protection Profile – A formal document defined in CC, expressing an implementation independent set of security requirements for a category of IT Products that meet specific consumer needs. Security Target – An implementation-dependent statement of security needs for a specific identified TOE. Subject – An active entity in the TOE that performs operations on objects. Target of Evaluation – An IT Product and its associated administrator and user guidance documentation that is the subject of an Evaluation. TOE Security Functionality – Combined functionality of all hardware, software, and firmware of a TOE that must be relied upon for the correct enforcement of the SFRs. 14. Bibliography [1] Common Criteria for Information Technology Security Evaluation/CC ISO-Version: ISO 15408:2022, Common Criteria for Information Technology Security Evaluation - Part 1: Introduction and general model - Part 2: Security functional components 41 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 - Part 3: Security assurance components - Part 4: Framework for the specification of evaluation methods and activities - Part 5: Pre-defined packages of security requirements https://www.iso.org/standard/72891.html https://www.iso.org/standard/72892.html https://www.iso.org/standard/72906.html https://www.iso.org/standard/72913.html https://www.iso.org/standard/72917.html CCRA-Version: CC:2022 R1, Common Criteria for Information Technology Security Evaluation - Part 1: Introduction and general model - Part 2: Security functional components - Part 3: Security assurance components - Part 4: Framework for the specification of evaluation methods and activities - Part 5: Pre-defined packages of security requirement https://www.commoncriteriaportal.org [2] Gemeinsame Evaluationsmethodologie für die Prüfung und Bewertung der Sicherheit von Informationstechnik (Common Methodology for Information Technology Security Evaluation (CEM), Evaluation Methodology ISO-Version: ISO 18045:2022: Information technology Security techniques Methodology for IT security evaluation https://www.iso.org/standard/72889.html CCRA-Version: CEM:2022 R1, Common Methodology for Information Technology Security Evaluation https://www.commoncriteriaportal [3] BSI certification: Scheme documentation describing the certification process (CC- Produkte) and Scheme documentation on requirements for the Evaluation Facility, approval and licensing (CC-Stellen), https://www.bsi.bund.de/zertifizierung [4] Application Notes and Interpretations of the Scheme (AIS) as relevant for the TOE10 https://www.bsi.bund.de/AIS [5] Security Target Lite BSI-DSZ-CC-1252-V2-2025, Version 2.5, 2025-09-25, “IFX_CCI_00007Ch/88h/89h/8Ah/8Bh G12 with optional Crypto Suite, Security Target Lite”, Infineon Technologies AG (public document) [6] Evaluation Technical Report, Version 3, 2025-09-30, “EVALUATION TECHNICAL REPORT SUMMARY (ETR SUMMARY)”, TÜV Informationstechnik, (confidential document) [7] Security IC Platform Protection Profile with Augmentation Packages Version 1.0, 13 January 2014, BSI-CC-PP-0084-2014 [8] Security Target BSI-DSZ-CC-1252-V2-2025, Version 2.5, 2025-09-25, “ IFX_CCI_00007Ch/88h/89h/8Ah/8Bh G12 with optional Crypto Suite, Security Target”, Infineon Technologies AG (confidential document) [9] ETR for composite evaluation according to AIS 36 for the Product, Version 3, 2025- 09-30, “Evaluation Technical for Composite Evaluation (ETR COMP) for the 10 See section 9.1 on usage of specific AIS. 42 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report IFX_CCI_00007Ch/88h/89h/8Ah/8Bh G12 with optional Crypto Suite”, TÜV Informationstechnik GmbH (confidential document) [10] Configuration list for the TOE, Version 0.2, 2025-05-15 (confidential document) [11] also referred to as [AGD_HRM], “TEGRION™ SLC27 (32-bit Security Controller – V32), Hardware Reference Manual”, Version 5.0, 2025-02-26, Infineon Technologies AG (confidential document) [12] also referred to as [AGD_PRM], “TEGRION™ SLx2 security controller family Programmer’s Reference Manual SLx2_DFP”, Version 1.8.0, 2025-05-09, Infineon Technologies AG (confidential document) [13] also referred to as [AGD_SG], “SLC27, 32-bit Security Controller – V32, Security Guidelines”, Version 1.00-3087, 2025-05-28, Infineon Technologies AG (confidential document) [14] also referred to as [AGD_PPM], “TEGRION SLC27 (32-bit Security Controller – V32), Production and personalization manual”, Version 10.08, 2025-05-07, Infineon Technologies AG (confidential document) [15] also referred to as [AGD_CryptoUM], “Crypto2304T V4, User Manual”, Version 3.0, 2024-06-21, Infineon Technologies AG (confidential document) [16] also referred to as [AGD_ES], “TEGRION™ SLC27 (32-bit Security Controller – V32), Errata sheet”, Version 6.0, 2025-05-22, Infineon Technologies AG (confidential document) [17] “SINGLE EVALUATION REPORT ADDENDUM to ETR-Part ADV Cryptographic Standards Compliance Verification”, Version 1, 2025-08-19, TÜV Informationstechnik GmbH (confidential document) [18] also referred to as [AGD_CS], “CS-SLC27V32 CryptoSuite, 32-bit Security Controller, User interface manual”, Version 5.02.002, 2025-05-28, Infineon Technologies AG (confidential document) [19] “Site Technical Audit Report (STAR) Infineon Technologies GmbH & Co. KG, Dresden”, version 1, 2025-05-02, TÜV Informationstechnik GmbH (confidential document) 43 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 C. Excerpts from the Criteria For the meaning of the assurance components and levels the following references to the Common Criteria in its CCRA Documents can be followed: • On conformance claim definitions and descriptions refer to CC:2022 part 1 chapter 10.5 • On the concept of assurance classes, families and components refer to CC:2022 Part 3 chapter 6.1 • On the concept and definition of pre-defined assurance packages (EAL) refer to CCRA CC:2022 Part 5. • On the assurance class ASE for Security Target evaluation refer to CC:2022 Part 3 chapter 9 • On the detailed definitions of the assurance components for the TOE evaluation refer to CC:2022 Part 3 chapters 7 to 15 • The table 1 in CC:2022 part 5, Chapter 4.2 summarizes the relationship between the evaluation assurance levels (EAL) and the assurance classes, families and components. The CC are published as the CCRA Version at https://www.commoncriteriaportal.org/cc/index.cfm The CC are published as the ISO/IEC Version at https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html 44 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report D. Annexes List of annexes of this certification report Annex A: Security Target provided within a separate document. Annex B: Evaluation results regarding development and production environment 45 / 47 Certification Report BSI-DSZ-CC-1252-V2-2025 Annex B of Certification Report BSI-DSZ-CC-1252-V2-2025 Evaluation results regarding development and production environment The IT product IFX_CCI_00007Ch/88h/89h/8Ah/8Bh G12 with firmware version 80.512.03.0 or 80.512.03.1, optional Crypto Suite 5.02.002 and user guidance documents (Target of Evaluation, TOE) has been evaluated at an approved evaluation facility using the Common Methodology for IT Security Evaluation (CEM), CEM:2022 extended by Scheme Interpretations by advice of the Certification Body for components beyond EAL 5 and CC Supporting Documents for conformance to the Common Criteria for IT Security Evaluation (CC), CC:2022. As a result of the TOE certification, dated 1 October 2025, the following results regarding the development and production environment apply. The Common Criteria assurance requirements ALC – Life cycle support (i.e. ALC_CMC.5, ALC_CMS.5, ALC_DEL.1, ALC_DVS.2, ALC_LCD.1, ALC_FLR.1, ALC_TAT.3) are fulfilled for the development and production sites of the TOE. Besides the production and development sites, the relevant TOE distribution centers are as follows: Distribution Center name Address DHL Singapore DHL Supply Chain Singapore Pte Ltd., Advanced Regional Center Tampines LogisPark 1 Greenwich Drive Singapore 533865 KWE Shanghai KWE Kintetsu World Express (China) Co., Ltd. Shanghai Pudong Airport Pilot Free Trade Zone No. 530 Zheng Ding Road Shanghai, P.R. China K&N Großostheim Kühne & Nagel Stockstädter Strasse 10 63762 Großostheim Germany Table 6: TOE Distribution Centers For the sites listed above, the requirements have been specifically applied in accordance with the Security Target [5] and [8]. The evaluators verified, that the threats, security objectives and requirements for the TOE life cycle phases up to delivery (as stated in the Security Target [5] and [8]) are fulfilled by the procedures of these sites. 46 / 47 BSI-DSZ-CC-1252-V2-2025 Certification Report Note: End of report 47 / 47