Certification Report

Preliminary Remarks

Under the BSIG Act, the Federal Office for Information Security (BSI) is tasked with issuing certificates for information technology products. Certification is carried out at the instigation of the vendor or distributor (sponsor). The process involves a technical examination (evaluation) of the product against security criteria published by the BSI or generally recognized security criteria. The evaluation is typically conducted by an evaluation facility recognized by the BSI or by the BSI itself. This report contains the certificate (summarized assessment) and detailed Certification Results, including the technical description of security functionality, evaluation details (strengths and weaknesses), and user instructions.

A Certification

1 Specifications of the Certification Procedure

The certification procedure follows criteria outlined in:

• BSIG
• BSI Certification Ordinance
• BSI Schedule of Costs
• Special decrees from the Federal Ministry of the Interior
• DIN EN 45011 standard
• BSI certification: Procedural Description (BSI 7125)
• Common Criteria for IT Security Evaluation (CC), Version 3.1
• Common Methodology for IT Security Evaluation, Version 3.1
• BSI certification: Application Notes and Interpretation of the Scheme (AIS)

2 Recognition Agreements

To avoid multiple certifications for the same product in different countries, mutual recognition of IT security certificates based on ITSEC or CC has been agreed upon under certain conditions.

2.1 European Recognition of ITSEC/CC – Certificates (SOGIS-MRA)

The SOGIS-Mutual Recognition Agreement (SOGIS-MRA), Version 3 (effective April 2010), defines the recognition of IT-Product certificates at a basic recognition level and higher levels for specific technical domains. The basic level includes CC Evaluation Assurance Levels EAL1 to EAL4 and ITSEC E1 to E3 (basic). Higher levels cover domains like Smart card and similar Devices, including assurance levels beyond EAL4/E3 (basic), and Protection Profiles based on Common Criteria.

2.2 International Recognition of CC – Certificates (CCRA)

The Common Criteria Recognition Arrangement (CCRA), signed in May 2000, facilitates mutual recognition of certificates based on CC Evaluation Assurance Levels up to EAL 4, including Protection Profiles. As of September 2011, numerous national bodies have signed the arrangement. The CCRA logo on a certificate indicates recognition by signatory nations. Some components (ADV_FSP.5, ADV_INT.2, ADV_TDS.4, ALC_CMS.5, ALC_DVS.2, ALC_TAT.2, ASE_TSS.2, ATE_DPT.3, AVA_VAN.5) are not mutually recognized under CCRA, with EAL4 components being relevant for mutual recognition.

3 Performance of Evaluation and Certification

The certification body monitors evaluations for uniform procedure, interpretation, and ratings. The NXP Secure Smart Card Controller P60D144/080MVA including IC Dedicated Software with MIFARE Plus MF1PLUSx0 underwent certification at BSI. The evaluation was conducted by T-Systems GEI GmbH, an ITSEF recognized by BSI, and completed on March 15, 2013. NXP Semiconductors Germany GmbH is the sponsor and applicant. The product was developed by NXP Semiconductors Germany GmbH. The certification concluded with a comparability check and the production of this Certification Report by BSI.

4 Validity of the Certification Result

This Certification Report applies only to the specified product version and its configuration. The assurance package is valid only if all stipulations regarding generation, configuration, and operation are observed, and the product is operated in the specified environment and Security Target. Re-assessment may be needed as attack methods evolve. Changes to the certified version require assurance continuity (re-certification or maintenance) and may extend validity if no security deficiencies are found.

5 Publication

The product is listed in the BSI's list of certified products, accessible via https://www.bsi.bund.de. Further information is available from BSI-Infoline (+49 228 9582-111). Copies of this report can be requested from the developer, NXP Semiconductors Germany GmbH, Stresemannallee 101, 22529 Hamburg.

B Certification Results

1 Executive Summary

The Target of Evaluation (TOE) is the "NXP Secure Smart Card Controller P60D144/080MVA including Security IC Dedicated Software with MIFARE Plus MF1PLUSx0". This hardware platform with IC Dedicated Software is used in high-security applications like banking, finance, e-commerce, and government sectors. It features coprocessors for Triple-DES and AES, large integer arithmetic, cyclic redundancy check, and a True Random Number Generator. It supports ISO/IEC 7816 (contact) and ISO/IEC 14443 A (contactless) interfaces. The CPU offers multiple modes for application separation and memory management. The IC Dedicated Software supports EEPROM write operations and can call MIFARE Plus MF1PLUSx0 functionality for contactless transport applications and access management systems. The evaluation covered Security Level 0 (personalization) and Security Level 3 (MIFARE Plus), excluding Security Levels 1 and 2 (MIFARE Classic). The TOE is referenced as P60D144/080MVA with MIFARE Plus MF1Plusx0. The certification is based on the Security Target [6], which in turn is based on the certified Protection Profile Security IC Platform Protection Profile, Version 1.0, 15 June 2007, BSI-CC-PP-0035-2007 [7]. The TOE meets the assurance requirements of Evaluation Assurance Level EAL 5 augmented by ASE_TSS.2, ALC_DVS.2, and AVA_VAN.5. The TOE Security Functional Requirements (SFR) are outlined in the Security Target [6] and [8], chapter 6.1, selected from Common Criteria Part 2 and including new definitions, making the TOE CC Part 2 extended.

TOE Security Functions:

The assets to be protected are defined in the Security Target [6] and [8], chapter 3.1. The TOE Security Problem is defined by Assumptions, Threats, and Organizational Security Policies (OSPs) in chapters 3.2 to 3.4. The P60D144/080MVA with MIFARE Plus MF1Plusx0 can be delivered in different configurations, detailed in table 5. Vulnerability assessment results do not include ratings for cryptographic algorithms for encryption/decryption (see BSIG Section 9, Para. 4, Clause 2). Certification results apply only to the indicated product version and require adherence to all stipulations in this report. This certificate does not constitute an endorsement or warranty by the BSI or any other recognizing organization.

2 Identification of the TOE

The Target of Evaluation (TOE) is the NXP Secure Smart Card Controller P60D144/080MVA including IC Dedicated Software with MIFARE Plus MF1PLUSx0.

Deliverables of the TOE:

Note: The ROM mask is released according to version 6.10, but the evaluated version includes a Firmware patch to version 6.11.

3 Security Policy

The Security Policy is defined by the Security Functional Requirements (SFRs) implemented by the TOE. As a hardware platform, the TOE's security policy includes countermeasures against information leakage, physical probing, malfunctions, physical manipulations, and unauthorized access to code and data memory. The TOE aims to maintain the integrity and confidentiality of stored data and the integrity, correct operation, and confidentiality of its security functions.

4 Assumptions and Clarification of Scope

Assumptions defined in the Security Target and certain aspects of Threats and Organizational Security Policies are not covered by the TOE itself. These require specific security objectives for the TOE-Environment, including:

• Usage of Hardware Platform (OE.Plat-Appl)
• Treatment of User Data (OE.Resp-Appl)
• Protection during composite product manufacturing (OE.Process-Sec-IC)
• Check of initialisation data by the Security IC Embedded Software (OE.Check-Init)
• Check of the Originality Key of the MIFARE Plus MF1PLUSx0 (OE.Check-OriginalityKey)
• OE.Secure-Values (Generation of secure values)
• Terminal support for integrity, confidentiality, and use of random numbers (OE.Terminal-Support)

Details are available in the Security Target [6] and [8], chapters 4.2 and 4.3.

5 Architectural Information

The P60D144/080MVA with MIFARE Plus MF1Plusx0 is an integrated circuit (IC) with a hardware platform and IC Dedicated Support Software. A top-level block diagram and subsystem list are in the Security Target ([6] and [8]). Detailed descriptions of the hardware platform, IC Dedicated Support Software, and instruction set are in the "Product Data Sheet, SmartMX2 family P60D080/144 and P60C080/144" [12] and its addenda [16], [17]. The "Firmware Interface Specification" [14] relates to version 6.11 of the Firmware Operating System, and "MIFARE Plus, Functionality of implementation on smart card controllers" [13] is the datasheet for the MIFARE PLUS MF1Plusx0 software.

The hardware platform includes a SMX2 CPU, Special Function Registers, Triple-DES Co-Processor, AES Co-processor, CRC Coprocessor, Fame2 Co- Processor, Memory Management Unit, Copy Machines, Random Number Generator (RNG), Power Module, and Security Sensors and Filters. It has both contact and contactless interfaces. The CPU has three modes for application separation, with one mode reserved for the Firmware Operating System. Security measures for physical protection are integrated into the circuitry layout.

Special Function Registers, controlled by the Security IC Embedded Software, provide an interface to the TOE's security functionality. The P60D144/080MVA with MIFARE Plus MF1Plusx0 offers different access control levels to SFRs via CPU Modes, and configurable access control for Special Function Registers in User Mode and Firmware Mode. The Fame2 provides modular arithmetic functions suitable for asymmetric cryptography and implements security features against fault and timing attacks [6], [8].

The TOE executes the IC Dedicated Support Software (Boot ROM Software) during startup for configuration and initialization. This software runs in Boot Mode. After startup, the CPU mode changes to System Mode, and re-entry to Boot Mode requires a reset. The Firmware Operating System provides functions for the IC Embedded Software, including EEPROM write support (with re-trimming for endurance), activation and maintenance of the ISO 14443 contactless protocol, and MIFARE PLUS MF1Plusx0 software. MIFARE Plus MF1PLUSx0 commands can be exchanged via the contactless or remote interface (requiring shared RAM). Strict memory partitioning ensures separation between IC Dedicated Support Software and Security IC Embedded Software. The Firmware operates in Firmware Mode with access only to Firmware partitions. System Mode and User Modes access the Security IC Embedded Software partition. System Mode can configure shared RAM for data exchange with Firmware Mode. Firmware can access code and data in the Security IC Embedded Software's EEPROM partition for EEPROM write operations. Firmware Operating System code and data are not accessible by Security IC Embedded Software in System or User Mode.

The hardware platform has both contact and contactless interfaces, usable independently or simultaneously based on configuration and clock settings.

6 Documentation

The evaluated documentation, as outlined in table 2, is provided with the product to the customer, containing information for secure usage of the TOE according to the Security Target. Additional obligations and notes for secure usage are in chapter 10.

7 IT Product Testing

The TOE, a hardware platform with IC Dedicated Software, is uniquely defined by the name P60D144MVA and P60D080MVA for major configurations. Its implementation and configurations are specified by Configuration Lists [25] for the hardware platform and [11] for the IC Dedicated Support Software. Developer tests include simulation environment tests, functional tests with special software for TSFIs (including MIFARE Plus MF1PLUSx0), characterization and verification tests for production release (including operating conditions and security features), and end-of-production functional tests using IC Dedicated Test Software. Evaluator tests repeat developer tests, supplemented by independent tests, special tests, and examination of hardware and firmware using open samples and different configurations. Penetration testing considered all TOE Security Functionality, including physical tampering, reverse engineering, side-channel analysis (AES, Triple-DES), and perturbation attacks. Attacks addressed include those averted by hardware/software combinations and those against hardware and firmware directly. IC Dedicated Software penetration tests also include logical attacks.

8 Evaluated Configuration

The P60D144/080MVA with MIFARE Plus MF1Plusx0 hardware platform was tested in various major and minor configurations. Table 5 provides an overview of major configurations, showing available EEPROM for Security IC Embedded Software and Copy Machines.

The tested configurations include all major and minor options specified in table 4 of section 1.4.2.2 of [6] and [8]. Differences are listed in table 5. Major configurations do not affect security features. Minor configuration options were tested as specified and described in [12], [13], and [18]. The results apply to P60D144MVA and P60D080MVA major configurations and all minor configurations described in [6] and [8].

Customer influence on major and minor configurations is not possible. Configuration is set using mask-coded bits and switches based on the ROM code mask and EEPROM-fuses set during wafer test. These settings are fixed after delivery. Post-delivery configuration, as described in [12], can disable the AES coprocessor, the Fame2 coprocessor, and adjust accessible EEPROM and CXRAM size. Disabling a component can lead to exceptions when accessing its SFRs. The FVEC0.15 allows reconfiguration of MIFARE Plus MF1PLUSx0, including its availability and accessible memory space, and can disable security services.

The MIFARE Plus MF1PLUSx0 software supports different configurations. The evaluation covered Security Level 0 (personalization) and Security Level 3 (MIFARE Plus), excluding MIFARE Classic (Security Levels 1 and 2). Transition from Security Level 1 or 2 to Security Level 3 is possible in the field (phase 7), following guidance in manual [19], section 3.1.

9 Results of the Evaluation

9.1 CC specific results

The Evaluation Technical Report (ETR) [9], provided by the ITSEF, adheres to Common Criteria [1], Methodology [2], Scheme requirements [3], and Scheme guidelines (AIS) [4]. The Evaluation Methodology CEM [2] was used for components up to EAL5, extended by Certification Body advice for components beyond EAL5 and technology-specific guidance [4] (AIS 34). Specific guidance for integrated circuits, smartcards, and evaluation was used ([4], AIS 25, AIS 26, AIS 37). AIS 31 was used for RNG assessment. ETR for composite evaluation [10] supports composite evaluations per AIS 36. Assurance refinements in the Security Target were followed. The evaluation verdict is PASS for assurance components including the EAL 5 package (ASE class) and augmented components ASE_TSS.2, ALC_DVS.2, and AVA_VAN.5.

The evaluation confirmed:

• PP Conformance: Security IC Platform Protection Profile, Version 1.0, 15 June 2007, BSI-CC-PP-0035-2007 [7]
• Functionality: PP conformant plus product specific extensions (Common Criteria Part 2 extended)
• Assurance: Common Criteria Part 3 conformant, EAL 5 augmented by ASE_TSS.2, ALC_DVS.2, and AVA_VAN.5

Specific evaluation results for the development and production environment are in annex B (part D). Evaluation results are applicable to the TOE as defined in chapter 2 and configuration in chapter 8.

9.2 Results of cryptographic assessment

Cryptographic algorithm strength was not rated in this certification (BSIG Section 9, Para. 4, Clause 2). Cryptographic Functionalities marked 'no' in 'Security Level above 100 Bits' have a security level below 100 bits. Application context must be considered for these functionalities. Further hints are in 'Technische Richtlinie BSI TR-02102' (https://www.bsi.bund.de).

10 Obligations and Notes for the Usage of the TOE

The documentation in table 2 contains essential information for TOE usage, and all security hints must be considered. Assumptions, Threats, and OSPs not covered by the TOE must be fulfilled by the operational environment. Customers should consider certification results in their system risk management process and define periods for re-assessment. Some security measures require implementation in hardware and additional configuration or controls via the IC Dedicated Support Software or Embedded Software. Guidance documentation for developers of Security IC Embedded Software and remote stations (terminals) is provided.

Guidance documents help implement measures required by the Security Target for the MIFARE Plus MF1PLUSx0 application. The evaluation of the composite product/system must verify correct and effective implementation of these measures. Evaluation results from ETR for composite evaluation [10] should also be considered. The term "DFA" in REQ.53 of [18] should be read as "Fault Injection". The encryption/decryption operation of MIFARE Plus MF1PLUSx0 may expose XOR differences between plaintext pairs, addressed in [19] (REC.12).

11 Security Target

The Security Target [8] for the Target of Evaluation (TOE) is provided as a separate document (Annex A), which is a sanitized version of the complete Security Target [6]. Sanitization followed CCRA policy (AIS 35 [4]).

12 Definitions

12.1 Acronyms

12.2 Glossary

• Augmentation: The addition of one or more requirement(s) to a package.
• Die: The separate, isolated chip.
• Extension: The addition to an ST or PP of functional requirements not contained in part 2 and/or assurance requirements not contained in part 3 of the CC.
• Fab: Short name used for the factory producing wafers.
• FabKey: Key to protect the chips during delivery (wafers or dies).
• Formal: Expressed in a restricted syntax language with defined semantics based on well-established mathematical concepts.
• Informal: Expressed in natural language.
• Object: An passive entity in the TOE, that contains or receives information, and upon which subjects perform operations.
• Protection Profile: An implementation-independent statement of security needs for a TOE type.
• Security Target: An implementation-dependent statement of security needs for a specific identified TOE.
• Semiformal: Expressed in a restricted syntax language with defined semantics.
• Subject: An active entity in the TOE that performs operations on objects.
• Target of Evaluation: A set of software, firmware and/or hardware possibly accompanied by guidance.
• 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.

C Excerpts from the Criteria

CC Part 1:

Conformance Claim (chapter 10.4)

The conformance claim indicates the source of requirements met by a PP or ST during evaluation. It includes a CC conformance claim detailing:

• The CC version to which the PP or ST claims conformance.
• Conformance to CC Part 2 (security functional requirements):
• CC Part 2 conformant: All SFRs based only on functional components in CC Part 2.
• CC Part 2 extended: At least one SFR not based on functional components in CC Part 2.
• Conformance to CC Part 3 (security assurance requirements):
• CC Part 3 conformant: All SARs based only on assurance components in CC Part 3.
• CC Part 3 extended: At least one SAR not based on assurance components in CC Part 3.

The conformance claim may also include statements regarding packages:

• Package name Conformant: PP or ST is conformant to a pre-defined package (e.g., EAL) if its SFRs/SARs are identical to those in the package.
• Package name Augmented: PP or ST augments a predefined package if its SFRs/SARs contain all package components, plus additional or hierarchically higher SFRs/SARs.

When a TOE is evaluated to an ST, the ST's conformance claims also apply to the TOE. Conformance claims can also include statements about Protection Profiles:

• PP Conformant: TOE meets specific PP(s) listed in the conformance result.
• Conformance Statement (for PPs): Describes the manner (strict or demonstrable) in which PPs or STs must conform to this PP.

CC Part 3:

Class APE: Protection Profile evaluation (chapter 10)

Evaluating a PP requires demonstrating its soundness, internal consistency, and correct instantiation of other PPs or packages. These properties ensure suitability as a basis for writing an ST or another PP.

Class ASE: Security Target evaluation (chapter 11)

Evaluating an ST requires demonstrating its soundness, internal consistency, and correct instantiation of PPs or packages. These properties ensure suitability for a TOE evaluation.

Security assurance components (chapter 7)

Assurance classes, families, and components are described below. Each assurance class contains at least one assurance family, and each assurance family contains one or more assurance components.

Evaluation assurance levels (chapter 8)

Evaluation Assurance Levels (EALs) provide a scale balancing assurance level with cost and feasibility. CC identifies separate assurance concepts for a TOE during evaluation and operational use. Not all families/components from CC Part 3 are included in EALs, but they may be considered for augmentation in PPs and STs where useful. EALs represent increasing assurance, achieved by substituting higher assurance components and adding components from other families.

Evaluation assurance level (EAL) overview (chapter 8.1)

Table 1 summarizes EALs, showing hierarchically ordered assurance families and components. EALs are hierarchically ordered, with each EAL providing more assurance than lower EALs. Augmentation allows adding assurance components not in the base EAL or substituting with higher assurance components within the same family. Augmentation requires justification of utility and added value.

Evaluation assurance level 1 (EAL1) - functionally tested (chapter 8.3)

EAL1 is suitable when confidence in correct operation is needed, but threats are not serious. It's valuable for independent assurance regarding due care for personal information. EAL1 requires a limited security target and focuses on stating SFRs rather than deriving them from threats, OSPs, and assumptions. It includes evaluation of the TOE as provided to the customer, independent testing, and examination of guidance documentation. An EAL1 evaluation should demonstrate that the TOE functions consistently with its documentation.

Evaluation assurance level 2 (EAL2) - structurally tested (chapter 8.4)

EAL2 requires developer cooperation in delivering design information and test results, consistent with good commercial practice. It's applicable when a low to moderate level of independently assured security is needed, especially when development records are not fully available, such as in securing legacy systems or with limited developer access.

Evaluation assurance level 3 (EAL3) - methodically tested and checked (chapter 8.5)

EAL3 allows a conscientious developer to achieve maximum assurance through positive security engineering at the design stage without significant alteration of development practices. It's applicable when a moderate level of independently assured security is required, along with thorough investigation of the TOE and its development without substantial re-engineering.

Evaluation assurance level 4 (EAL4) - methodically designed, tested, and reviewed (chapter 8.6)

EAL4 permits maximum assurance from positive security engineering based on rigorous commercial development practices, without requiring substantial specialist knowledge. It's the highest level economically feasible for retrofitting to existing product lines. EAL4 is suitable for moderate to high levels of independently assured security in conventional commodity TOEs, with additional security-specific engineering costs.

Evaluation assurance level 5 (EAL5) - semiformally designed and tested (chapter 8.7)

EAL5 allows maximum assurance from security engineering based on rigorous commercial practices with moderate specialist security engineering techniques. TOEs designed for EAL5 may incur moderate additional costs for achieving this assurance. EAL5 is applicable when a high level of independently assured security is required in planned development, with a rigorous approach without unreasonable specialist costs.

Evaluation assurance level 6 (EAL6) - semiformally verified design and tested (chapter 8.8)

EAL6 enables high assurance from security engineering techniques in a rigorous development environment for premium TOEs protecting high-value assets against significant risks. EAL6 is applicable to security TOEs in high-risk situations where asset value justifies the costs.

Evaluation assurance level 7 (EAL7) - formally verified design and tested (chapter 8.9)

EAL7 is applicable to security TOEs in extremely high-risk situations or where high asset value justifies higher costs. Practical application is limited to TOEs with tightly focused security functionality amenable to extensive formal analysis.

Class AVA: Vulnerability assessment (chapter 16)

The AVA: Vulnerability assessment class addresses the possibility of exploitable vulnerabilities in the TOE's development or operation.

Vulnerability analysis (AVA_VAN) (chapter 16.1)

Vulnerability analysis assesses potential vulnerabilities identified during TOE development and operation, or through other methods (e.g., flaw hypotheses, statistical analysis), that could allow attackers to violate SFRs. It identifies flaws enabling unauthorized access to data/functionality, interference with or alteration of the TSF, or interference with authorized user capabilities.

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.

Annex B of Certification Report BSI-DSZ-CC-0840-2013

Evaluation results regarding development and production environment

The IT product NXP Secure Smart Card Controller P60D144/080MVA including IC Dedicated Software with MIFARE Plus MF1PLUSx0 (TOE) was evaluated at an approved facility using CEM, Version 3.1, extended by Certification Body advice and technology-specific guidance for CC, Version 3.1 conformance. The certification, dated April 19, 2013, confirms that Common Criteria assurance requirements ALC (ALC_CMC.4, ALC_CMS.5, ALC_DEL.1, ALC_DVS.2, ALC_LCD.1, ALC_TAT.2) are fulfilled for the listed development and production sites.

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 [6] and [8], are fulfilled by the procedures at these sites.