MIFARE Plus and DESFire

Transcription

1 Rev January 2015 Specification l Document information Info Content Keywords Security, Certification, MIFARE Abstract Document describing the NXP MIFARE Security Scheme Process

2 Revision history Rev Date Description Initial Release Contact information For more information, please visit: For sales office addresses, please send an to: Specification Rev January of 46

3 1. Introduction The NXP MIFARE is used by NXP to demonstrate that a specific product is in compliance with the security requirements associated with either MIFARE Plus or MIFARE DESFire. This NXP MIFARE - Security Evaluation Processes (this Document ) describes the security process to be followed when either MIFARE Plus technology and/or MIFARE DESFire technologies is implemented. For the purposes of this Document, a approval is provided for a unique combination of a hardware platform + software compliant with MIFARE for 7.5 years. The NXP MIFARE specifies the composite security evaluation which must be satisfied to get an approval. This composite security evaluation leverages the hardware platform which has already been approved (either Common Criteria or EMVCo). 1.1 Audience This document is restricted to use by authorized NXP personnel, Recognized Security Laboratories approved by NXP, and entities (such as MIFARE Plus & DESFire licensees) who wish to submit products for testing under this Security Evaluation Scheme. 1.2 Document Organization This document is organized using the section structure and data conventions described in the following subsections Structure of Sections This document is divided into the following sections: Section 2: Contains the key objectives of the scheme, roles and responsibilities for all participants, and an overview of the evaluation process. Section 3: Describes the processes and procedures associated with either MIFARE Plus and/or MIFARE DESFire Security Evaluation. Appendices, including: Naming Conventions Appendix A: Acronyms and Glossary Appendix B: Licensee Submission Form Appendix C: Request for Approval The following naming conventions are adopted throughout this document: A hardware platform consisting of wafers of semiconductor material with etched or printed electronic switching circuits. A Recognized Security Laboratory (i.e., a recognized EMVCo and/or CC Laboratory approved by NXP) referred to as Laboratory or Lab. A product manufacturer who wants to develop a card or reader product compliant with the MIFARE Plus or MIFARE DESFire Specification, referred to as Licensee. Specification Rev January of 46

4 MIFARE Technology refers to either MIFARE Plus and/or MIFARE DESFire A Letter of Approval is a written statement that documents the decision of the Certification Authority Lab that a specified product has been approved. A NonDisclosure Agreement is referenced as an NDA. A Product Registration Number is a unique identification number assigned by NXP to a product for testing. The PRN is communicated by NXP when initiating the MIFARE security evaluation The Approval Reference Number is a unique identification number assigned by NXP to an approved product. The ARN is communicated by NXP at the end of the security evaluation when the product is approved. A Licensee Submission Form is a form designed to record information submitted by the Licensee. A Licensee Registration Number is a unique identification number assigned by NXP to be used by a Licensee on all communication and reports sent to NXP. A Final or Full Report is the exhaustive report which is addressed by the Security Lab to the Licensee An Evaluation Report Lite is a report which contains no IP transmitted to the Certification Authority Lab by the Recognized Security Laboratory A Test Subject submitted for Security Evaluation is a product that is compliant with the MIFARE technology Terminology The following terminology applies: shall or must Denotes a mandatory requirement should Denotes a recommendation may Denotes an optional feature Specification Rev January of 46

5 1.3 Reference Materials The documents listed in Table 1 may have been cited in this document or used to obtain background information. Table 1. Reference Documents Title Source Reference Joint Interpretation Library Application of Attack Potential to Smartcards, Version [JIL] ISO Standard Common Criteria for Information Security Evaluation 2 [CC] ISO Standard Identification cards Contactless integrated circuit cards Proximity cards Product data sheet MIFARE Plus Functionality of implementations on smart card controllers MIFARE Plus specification MF3ICD81 MIFARE DESFire EV1, Rev February [ISO-14443] 3 [MIFARE-PLUS] 3 [MIFARE-EV1] MIFARE Approved Lab List 4 [MIFARE-ALL] MIFARE Approved Certification Authority Lab List 4 [MIFARE-ACAL] MIFARE Evaluation Report Lite 4 [MIFARE-ERL] MIFARE Security Analysis 4 [MIFARE-SA] Key: 1 = Available online from the Joint Interpretation Library 2 = Available from the ISO standards website ( 3 = Available via Internet 4 = Available from NXP 1.4 Contact Names and Inquiry Procedures related to the security evaluation All requests or inquiries should be addressed by to: MIFAREcertification@nxp.com. Specification Rev January of 46

6 [This page is intentionally left blank.] Specification Rev January of 46

7 2. SECURITY EVALUATION SCHEME OVERVIEW This section provides an overview of the, including the objectives of the scheme, roles and responsibilities for all Licensees, and a highlevel description of the evaluation process. 2.1 Objective The purpose of this document is to define the MIFARE Security Evaluation Scheme to validate that all MIFARE Plus and MIFARE DESFire products are compliant with the NXP security requirements with the goal of mitigating potential threats. The evaluation must be performed by a Laboratory approved by NXP to verify that an acceptable level of security exists for the product for the duration of its approval. Upon the successful completion of security testing, NXP shall issue an Approval Reference Number to the Licensee. 2.2 Definition of the Scheme The described in this Document validates a level of security assurance acceptable to NXP based on state-of-the-art industries best practice at the time of testing. The security assurance evaluation will be conducted by examining the software applications, the hardware platform, and any interactions between these components. Approval under this scheme pertains to acceptance for use of the MIFARE brand on a product embedding the MIFARE technology. Approval obtained by completing the security evaluation described in this document cannot be used to draw any conclusions about the security assurance of a particular product when it is evaluated under another. Neither can approval under this NXP Security Evaluation be used to infer any recommendation about a Licensee or an IC. The approval does not constitute a recommendation for use of the product nor is it a guarantee that the product is totally free of any exploitable vulnerability. There is always a residual probability that exploitable vulnerabilities have not been discovered. The Certification Authority Lab shall make the decision to approve or fail (approval not granted) a submitted Test Subject evaluated under the NXP MIFARE Security Evaluation Scheme. NXP will respect the decision taken by the Certification Authority. 2.3 Certificate Lifespan The initial approval duration period for products passed under this scheme is 3 years. The type of security evaluation for first approval of the Test Subject is named Full Security Evaluation, also known as FSE. A Renewal Security Evaluation, also known as RSE, must be performed three years after the first security evaluation, to extend the lifespan of the product. Note that this renewal extends the lifespan by 18 months. As 3 renewals are accepted, the whole approval duration period can be 7.5 years. For each renewal there must be a valid underlying hardware or platform certificate, this can be either CC or EMVCo based. The following figure illustrates how the certificate lifespan is managed under the MIFARE. Specification Rev January of 46

8 Whole Certificate Lifespan: 7.5 years FSE RSE#1 RSE#2 RSE#3 End Of Life 12 months FSE: Full Security Evaluation 18 months RSE: Renewal Security Evaluation Figure 1 Certificate Lifespan The previous figure gives the maximum Lifespan of a certificate (7.5 years). Hereafter is a set of scenarios which may appear while evaluating a Test Subject. Note that these scenarios are defined to illustrate the close relationship between FSE, RSE, new potential attack path and either platform or hardware certificate. Scenario #A: FSE and RSE#1 OK // New potential attack path raised before RSE#2 During RSE#2, the new potential attack path will be introduced in the penetration test plan to ascertain the Test Subject is resistant to this new threat. Scenario #B: FSE and RSE#1 OK // New potential attack path raised before RSE#2 // RSE #2 not OK During RSE#2, the Security Lab demonstrates that the Test Subject is not resistant to the new threat. In other words, the evaluated product is lower than an AVA_VAN.5 level of resistance. In this case, the Licensee can fix the security issue by implementing dedicated security mechanisms. The lab will assess the modifications as follows: 1. Perform a security analysis to ascertain whether or not the new security mechanisms protect the Test Subject properly, 2. Perform a security impact analysis to verify the modifications do not introduce new potential attack paths, 3. Perform testing to confirm the security issue has been fixed properly. Specification Rev January of 46

9 Scenario #C: FSE, RSE#1, RSE#2 and RSE#3 OK. In this scenario the Licensee has fully leveraged the certificate lifespan. The product reaches the End of Life. Scenario #D: FSE, RSE#1 are OK // the underlying element does not have a valid certificate before RSE#2 When reviewing the Licensee Submission Form sent by the Licensee to perform RSE#2, both Certification Authority Lab and Security Lab identify that the underlying certificate dedicated to either platform or hardware is not valid anymore. In this case, the product has reached its End of Life. Scenario #E: FSE, RSE#1, RSE#2 and RSE#3 OK // the underlying hardware or platform s certificate expires after RSE#3 but before End of Life. This scenario does not impact the Test Subject and it can reach the End of Life,, even if the underlying element s certificate has expired. Provided the underlying certificate was valid at the time of RSE#3. The underlying certificate must be valid only when conducting FSE, RSE#1, RSE#2 and RSE#3. In other words, if the underlying certificate expires three months after processing RSE#3, this has no impact because it is only necessary to have a valid certificate when conducting a security evaluation.. Scenario #F: FSE, RSE#1 OK // the underlying element lost its certificate due to severe security issues before RSE#2. It is the only scenario in which all products based on this underlying element could lose their certificate. Licensees will be made aware by NXP that their certificates may be revoked this will depend on a risk analysis of the security issue and any mitigating mechanisms in place through the MIFARE application It is worth mentioning that the validity of the test results follows the same lifetime as the type of security evaluation which could be either FSE or RSE. Hence, FSE test results cover 3 years while RSE test results cover 18 months. 2.4 Roles and Responsibilities The principal parties participating in the Security Evaluation are: NXP The sponsor of the NXP MIFARE Security Evaluation scheme. Licensee - The Corporation submitting a Test Subject for evaluation. Laboratory An independent recognized test Laboratory, approved by NXP, to perform (all or some parts) of the Security Evaluation. Certification Authority Lab entity, approved by NXP, in charge of giving the decision to the submitted Test Subject. The following figure illustrates stakeholder involved in a MIFARE security evaluation and the corresponding relationship. Specification Rev January of 46

10 Licensee Laboratories Certification Authority NXP approved NXP approved Figure 2 MIFARE Security Evaluation Overview e NXP Licensee In order to make the MIFARE as neutral as possible, the following two rules must be followed: 1. Licensee cannot choose the same Lab acting as Laboratory and Certification Authority Lab. Two different Laboratories must be chosen Certification Authority Lab Certification Authority Lab. 2. The roles between the Laboratory and the Certification Authority Lab must not be changed during a security evaluation. NXP, sponsor of this security scheme, shall perform the following roles: Maintain the Approved Laboratories List (ALL). This ALL will be provided to the Licensee by NXP as soon as the security evaluation is initiated. Maintain the Approved Certification Authority Lab List (ACAL). This ACAL will be provided to the Licensee by NXP as soon as the security evaluation is initiated. Approve both the Security Lab and Certification Authority Lab selected by the Licensee. Give the Product Registration Number and Approval Reference Number. Maintain the scheme documents and expand the scheme scope. The MIFARE technology product Licensee will be responsible for the following: Complete a Licensee Submission Form and send it to NXP and the Laboratory. Specification Rev January of 46

11 Select evaluation and Certification Laboratory to perform the MIFARE security evaluation. Obtain from NXP the approval to submit the product embedding the MIFARE technology for Security Evaluation to the selected Laboratory. Submit the required information and required number of test samples to the approved Laboratory for testing Approved Laboratories The Security Laboratories, approved by NXP, execute the following tasks: Assist Licensee by verifying that any documentation submitted by a Licensee is complete, and performing any necessary preliminary testing prior to formal testing. Define the key testing phases (with a proposed completion time schedule). Identify test sample configurations as necessary. Perform all aspects of security testing (an approved Laboratory may delegate testing tasks only with the written authorization of NXP). Submit the Final Report to the Licensee. Submit the Evaluation Report Lite to the Certification Authority Approved Certification Authority The Certification Authority Lab, approved by NXP, works with NXP to: Notify NXP as soon as the security evaluation is initiated. Notify NXP as soon as the security evaluation is completed. The Certification Authority Lab works with the Laboratory to: Review in detail the Licensee Submission Form Review in detail the evaluation scope Review in detail the Penetration Test Plan Review in detail the Evaluation Report Lite delivered by the Laboratory Address questions to the Laboratory to better understand the security mechanisms embedded in the product when required Ascertain that the security test items selected for this security evaluation have been processed properly The Certification Authority works with the Licensee to: Provide one of the following evaluation outcomes: o Pass o Pass with comments o Fail Issue and transmit the Letter of Approval after a successful security evaluation containing the Approval Reference Number provided by NXP NXP follows the final decision without any comments. In order words, NXP completely relies on the Certification Authority Lab concerning the risk management of the security evaluation. One of the objectives of the Specification Rev January of 46

12 Certification Authority role is to create isolation between NXP and the Licensee in order to render this MIFARE NXP agnostic. 2.5 Test Subject This section contains a description of a Test Subject. Details of all previous Security Evaluations undergone by the Test Subject shall be provided to the Laboratory by the Licensee Submitted for Evaluation This may only evaluate a product that is submitted for evaluation as a Test Subject. In addition, the hardware platform that is used must have been previously certified to be compliant with either EMVCo standards [EMV] or Common Criteria [CC]. Such compliance must be demonstrated by the Licensee. After the Test Subject is submitted, the attributes of the Test Subject submitted for Security Evaluation shall not be changed during the evaluation without the explicit permission of NXP. These attributes includes all documentation as well as the product type and version numbers of the underlying hardware, platform and any additional applications which may be present on the Test Subject. A Test Subject submitted for Security Evaluation must contain either MIFARE Plus or MIFARE DESFire which is compliant with the corresponding standards [MIFARE Plus Specification] and [MIFARE DESFire Specification]. The MIFARE technology relies on a hardware platform which has been previously certified following either the CC or EMVCo security evaluation scheme. The objective of the MIFARE Security Scheme is to create a hierarchy of secure components with all secure MIFARE applications using the secure functionality provided by a secure platform or secure OS, which in turn must use the secure features made available by the secure hardware (IC) Configuration Overview Several configurations can be offered according to the type of MIFARE technology. From a global overview, the Test Subject is compliant with one of the following designs: Application + IC, Application + Platform Two types of platforms are defined: Open Platform with post-issuance capability and Closed platform without post-issuance capability. The following figure sums-up the two designs Specification Rev January of 46

13 1. Application 1. Application 2. Platform 3. Hardware Figure 3 Test Subject design The following figure makes the link between the Test Subject designs with the MIFARE technology. Specification Rev January of 46

14 Test Subject Configuration 1. Application 1.A MIFARE 1.B MIFARE + SES 2. Platform 2.A Platform (IC + OS) Either CC or EMVCo certified 2.B Platform (IC + OS) Either CC or EMVCo certified 3. Hardware 3.A Integrated Circuit Either CC or EMVCo certified 3.B Integrated Circuit Either CC or EMVCo certified Standalone Integrated Legend: CC: Common Criteria SES: Security Embedded Software (payment and other applications as well) developed by the ICC provider MIFARE: The following configurations are available: 1. MIFARE Plus only 2. MIFARE DESFire EV1 only 3. Both MIFARE Plus and MIFARE DESFire EV1 Standalone: a Test Subject configuration embedding only MIFARE Integrated: a Test Subject configuration embedding both MIFARE and SES Figure 3A Test subject Configuration (High Level) The following table sums up the four configurations dedicated to a Test Subject. Table 2. Test Subject Configuration Test Subject Involved Elements Comments #1 1.A + 2.A Open Platform or Closed can be used #2 1.A + 3.A #3 1.B + 2.B Open Platform or Closed Specification Rev January of 46

15 Test Subject Involved Elements Comments #4 1.B + 3.B can be used Whatever the configuration, the security evaluation is always composite, meaning the Test Subject is built on an element (either Platform or Hardware) which must have a valid certificate Platform Security Requirements Focus In order to ensure the security level for configuration #1 and #3, the platform must have been evaluated and covered under a valid certificate. If the security evaluation operates with a platform evaluated in an EMV context, the platform must have a valid Platform Certificate Number (PCN). Note that the Lab must also analyze the Shared Evaluation Report to understand which security features have been covered during the platform security evaluation. The same approach must be followed when the security evaluation operates with a platform evaluated in a CC context. Note that the minimum Evaluation Assurance Level for a platform is EAL4+ (AVA_VAN.5) Hardware Security Requirements Focus In order to ensure the security level for configuration #2 and #4, the hardware must have been evaluated and covered under a valid certificate. If the security evaluation operates with hardware evaluated in an EMV context, the hardware must have a valid Integrated Circuit Certificate Number (ICCN). Note that the Lab must also analyse the Shared IC Report to understand which security features have been covered during the IC security evaluation. The same approach must be followed when the security evaluation operates with an IC evaluated in a CC context. Note that the minimum Evaluation Assurance Level for an IC is EAL4+ (AVA_VAN.5) Environment. During the MIFARE Security Evaluation, the Licensee must justify its development sites have been audited and are compliant with either CC or EMVCo security requirements. If a remark has been highlighted during a site audit, the Licensee must prove to the Laboratory that this security issue has been fixed properly. Note all details concerning site audits must be communicated to the Laboratory because a section dedicated to site audits in [MIFARE-ERL] must be populated. 2.6 Security Evaluation Goals and Requirements Based on the decision given by the Certification Authority Lab (pass, pass with comments, or fail decision) NXP will issue the Approval Reference Number. This decision, taken by the Certification Authority Lab, is based on the analysis of the Evaluation Report Lite submitted by the Lab. To preserve the intellectual property associated to the Licensee, NXP will not review the Evaluation Report Lite NXP s Requirements NXP requires the following: Specification Rev January of 46

16 1. A reasonable and demonstrable level of assurance of security strengths is provided to protect security-sensitive assets against threats. 2. A level of resistance to threats equivalent to industry best practices must be implemented. The evaluated product must reach an AVA_VAN.5 level of resistance. 3. In an evaluation, Licensees shall conform to the definitions of security requirements and recommendations for the scheme. NXP shall provide information to Licensees regarding this matter upon the initiation of an evaluation. 4. The Laboratory shall demonstrate due diligence performed by providing evidence of the evaluation activities and results in report documents. In an evaluation, Laboratories shall conform to the definitions of test procedures and recommendations for the scheme. NXP shall provide information to Laboratories regarding these definitions upon initiation of an evaluation process. 5. An appropriate balance must be struck between exhaustive testing and a demonstration of contemporary industry best-practice security standards. NXP requires mitigations against the various threats to protect the MIFARE brands by seeking a balance of due diligence applied by the License against appropriate test benchmarks determined by NXP. The test strategy is based on the required depth (strength of evaluation), the scope of the evaluation, and efficiency in terms of time and cost. At the same time, the test strategy shall remain extendable to accommodate any emerging threats Scope of Assets, Threats, Attacks and Evaluation Techniques Assets are the security critical data values or functionalities residing on the Test Subject. For the purposes of this, primary security assets are defined as data values or functionalities whose exposure or corruption would directly compromise the Test Subject. These primary security assets include, but are not limited to: cryptographic keys, embedded software and user data assets. Secondary assets may also include data values or functions whose exposure or corruption indirectly compromises the Test Subject by facilitating an attack(s) on a primary asset(s). An important methodology used in this scheme is an assessment to determine which threats against certain assets are most significant and/or applicable for a particular Test Subject. Additionally, in every evaluation, several mandatory attack investigations are defined to provide a baseline assessment of the Test Subject s response to common threats and to validate the Laboratory s attack potential. High-level groupings of attack types that may be considered significant include: 1. Logical attacks that may make use of protocol based attack, exploiting a bug or remnant backdoor or more specific attacks targeting specific mechanisms implemented by an open platform. The latter threat may require specific rights granted on the platform for malicious applications being loaded and installed. Observation-based attacks, most often involving spying or deduction techniques, such as side-channel cryptanalysis. These approaches attempt to exploit an embedded system by determining correlations between its physical behavior and Specification Rev January of 46

17 assets being exercised (such as cryptographic keys or PIN), without physically invading the device. 2. Perturbation attacks that may be invasive (e.g., laser fault injection) and directed with the intent to exploit an embedded system by inducing controllable faults to reveal assets. Other factors such as combination attacks or particular situations where controllable devices may be obtained by an attacker will be used to generate model attacks on the Test Subject. In this regard, certain classes of attacks will be defined as out of scope when existing evaluation evidence is available such as the IC s resistance to reverse engineering. Specification Rev January of 46

18 3. EVALUATION PROCESSES This section defines the lifecycle of a MIFARE Security Evaluation, and outlines the principal activities that shall occur during the evaluation process. The provided information should be used as an initial reference by Licensees or Laboratories intending to participate in a MIFARE Security Evaluation. A high-level process flow is shown in Figure 4. After the security evaluation, the following two reports will be delivered by the lab. 1. The Final Report which is exhaustive and contains all details concerning how the Test Subject has been assessed. This Final Report is only addressed to the Licensee, 2. The Evaluation Report Lite is derived from the Final Report. This one is not as exhaustive as the Final Report. This Evaluation Report will be addressed to the Certification Authority. The Certification Authority will base its approval decision on this Evaluation Report Lite. The Evaluation Report Lite is only addressed to the Certification Authority. Specification Rev January of 46

19 Start Phase 1 Submission Phase 2 Evaluation Scope Phase3 Vulnerability Analysis Phase 4 Penetration Test Plan Phase 5 Penetration Testing Phase 6 Approval End Figure 4 Evaluation Process Flow Specification Rev January of 46

20 3.1 Phase 1: Submission Process Submission Licensee NXP Certification Authority Laboratory Submission Send request for a security evaluation via (draft LSF) Provide the list of: 1. Approved (CA) labs 2. Issue PRN Complete the LSF LSF completed No Are Lab and CA ok? Yes Approve LSF and return to Licensee Send LSF to CA lab and evaluation lab Review the LSF No OK? Yes Notify that security evaluation is initiated and that LSF is approved by labs Approval to proceed Approve to proceed with evaluation Submission Complete Figure 5 Submission Process Specification Rev January of 46

21 Table 3. RACI Matrix of Submission Process Roles Activities NXP Certification Authority Laborator y Licensee Send a request for a MIFARE security evaluation via Provide the following two lists: 1. ALL, 2. ACAL, Issue PRN Complete the Licensee Submission Form and send to NXP Review and check the LSF, either accept or decline the Lab and the Certification Authority Lab Submit the LSF with PRN to labs Review and discuss the LSF with selected Lab Give the Licensee the approval to proceed with the evaluation (LSF review) Give the Licensee the approval to proceed with the evaluation I I I I I I I I I I I I I Prerequisites Flow Before the Submission process can begin, the following inputs are required: The entity submitting a MIFARE product must be a genuine licensee. This Licensee registration and all related activities must be performed before initiating the security evaluation. The submission process as described in Figure 5 includes the following tasks: 1. NXP receives a request for a security evaluation from the Licensee. 2. NXP provides ALL and ACAL lists to the Licensee. 3. The Licensee must complete the Licensee Submission Form. The Licensee Submission Form should contain the information necessary for the Laboratory to perform an assessment to determine the scope of testing during phase 2: Scope of Work. The required details on the Licensee Submission Form will include at least the following: a. Functional definitions that define the product, its architecture, and its functionality. Specification Rev January of 46

22 3.1.3 Outputs b. Details of how the Security Requirements of the scheme have been fulfilled. c. Product identifiers such as Licensee name, contacts, product name, IC make/model, OS name/version, application(s) name/version, product specifications, data sheets, design documents, and any other relevant Licensee documentation. d. Details of whether this product belongs to a class of products that have previously been tested (which may result in a delta test). e. Name of Labs acting as: i. The security Lab ii. The Certification Authority Lab endorsing the role of the Certification Body 4. As soon as the LSF is received by NXP, NXP completes the Product Registration Number and check both the Lab and the Certification Authority Lab. NXP has the right to reject the choice made by the Licensee without any justifications. 5. Declaration of evidence of any separate security evaluations that have been performed. Results from other schemes will be taken into consideration. The Certification Authority Lab reserves the right to apply such results towards the reduction of the scope of the evaluation. 6. The Certification Authority Lab reviews and discusses the Licensee Submission Form with the selected Laboratory. The Scope of testing must (as a minimum) cover the Security Requirements. Note however that the Scope may not be entirely defined until the Laboratory has performed some evaluation work. 7. Upon their agreement with the Laboratory regarding the collected and proposed data collection, the Certification Authority Lab provides an approval to proceed with the evaluation. When the Submission process is complete, the following outputs will be produced: The Licensee will have an approved Licensee Submission Form including PRN. The Certification Authority Lab will send an to the Licensee with an approval to continue the security evaluation. NXP will be notified by the Certification Authority Lab the security evaluation is initiated. Specification Rev January of 46

23 3.2 Phase 2: Evaluation Scope Process Figure 6 provides a summary of the Scoping process of the Security Evaluation. Evaluation Scope Licensee NXP Certification Authority Laboratory Evaluation Scope Approved LSF Evaluate details from the Licensee Assess the scope of required testing Communicate requirements to the Licensee & the Lab via Propose the Evaluation Scope Review The Evaluation Scope with the Lab No OK? Yes Approval to proceed Lab and the Licensee establishes a commercial relationship Evaluation Scope Complete Figure 6 Evaluation Scope Process Specification Rev January of 46

24 Table 4. RACI Matrix of the Evaluation Scope Process Roles Activities NXP Certification Authority Lab Laboratory Licensee Evaluate details from Licensee Assess the evaluation scope of required testing Communicate requirements to Licensee & the Lab via Specification Rev January of 46 I I Propose Evaluation Scope I Review Evaluation Scope with Lab Approval to proceed I I Lab and Licensee concludes the commercial relationship Inputs Flow R Before the Evaluation Scope Process can commence, the following input is required: Approved Licensee Submission Form (from the Certification Authority Lab). This corresponds to the output of the previous phase called Submission Process. During the completion of this phase, the Evaluation Scope (i.e., the degree of testing required for the MIFARE security evaluation) is determined as follows: 1. The Laboratory evaluates the details provided by the Licensee on the Licensee Submission Form to determine the required Scope of testing; including whether to perform a full test, a delta test, a renewal test or no test (in which case a formal letter only shall be required to complete the evaluation) as follows: a. A full test is required for a new product, and/or a product that has not been tested by a Laboratory. b. A delta test is required for a product demonstrably belonging to a family of products that have been tested by a Laboratory. The Laboratory in this case determines the differences and considers which tests are applicable or not. One example of a typical delta test condition would be for changes such as an application software patch or a minimally changed ROM mask. c. A renewal test is required when a product has been initially successfully evaluated 3 (three) years ago. Note that the Lab selected to process a renewal does not have to be the lab used during the initial security evaluation. d. No test is required for a product demonstrably belonging to a family of products that have been tested previously by a Laboratory, where sufficient evidence addressing all the major security requirements of this scheme is available. In this case R

25 the Laboratory determines that repeated testing is highly likely to provide identical results. To make this determination, the Laboratory must review: The security requirements and security procedures defined for this scheme. The Laboratory s prior experience with the Licensee and their products. Any prior testing and/or evaluation that is thought to be relevant. Any assessment(s) of the submitted product submitted for testing against contemporary attack techniques that may be leveraged as part of the process Outputs 2. The Certification Authority Lab reviews the proposed Scope of the testing and responds with permission to progress to the next step called Vulnerability Analysis, or refers the evaluation back to the Laboratory for additional evaluation before progressing, or terminates the evaluation. The Certification Authority Lab may request additional information before making this decision. The Certification Authority Lab may decide on full or delta testing to be performed for reasons other than those submitted on the basis of the evaluation submission evidence. The Certification Authority Lab reserves the right to terminate the Security Evaluation under any circumstance. 3. Upon receipt of the Certification Authority Lab approval to progress to Vulnerability Analysis phase, the Laboratory and Licensee form contractual agreement(s) for the purpose of implementing the evaluation. The Certification Authority Lab shall allow delta evaluations to be performed, when a requirement for omitting certain vulnerability analysis and/or penetration testing activities can be demonstrated because the Test Subject closely shares security attributes with a similar product having been already evaluated under the scheme. The Certification Authority Lab may determine that certain testing activities may be omitted for different reasons, on a case-by-case basis. Similarly, the Certification Authority Lab may determine that additional tests are required for some evaluations. It is expected that these decisions may be made during the Scope of Work phase. However, it is possible that such decisions could occur at any time in an evaluation process. When the Evaluation Scope process is complete, the following Outputs shall be produced: Agreement between the Laboratory and the Licensee on the Scope of testing, pricing, estimated duration (from Laboratory to the Licensee) Approval from the Certification Authority Lab to proceed to the Vulnerability Analysis Process. Specification Rev January of 46

26 3.3 Phase 3: Vulnerability Analysis Process This phase defines the testing components that are required to verify that the Test Subject is fit for purpose before testing commences. An important component of this phase is to use previous testing evidence to the fullest extent possible. The Certification Authority Lab shall decide which previous test evidence shall be admissible. A summary of the Vulnerability Analysis process is provided in Figure 7. Specification Rev January of 46

27 Vulnerability Analysis Licensee NXP Certification Authority Laboratory Vulnerability Analysis Agreed Evaluation Scope Provide the relevant data for vulnerability analysis Clarification on Configuration? Yes Confirm Configuration details No Submission of prior evaluations Source code Define security attributes Test Samples Review source code with the Licensee Derive feasible attacks defined by assets threat matrix Test Subject Security Level knowledge Vulnerability Analysis Complete Figure 7 Vulnerability Analysis Process Specification Rev January of 46

28 Table 5. RACI Matrix of Vulnerability Analysis and Penetration Test Plan Development Process Roles Activities NXP Certification Authority Lab Laboratory Licensee Provide the relevant data for vulnerability analysis Confirm Configuration details C Define security attributes Review source code with Licensee Define feasible attacks defined by assets threat matrix Have a comprehensive knowledge of the Test Subject Security Level C C Inputs The Vulnerability Analysis process requires that the following inputs shall be provided: Agreement on the Evaluation Scope to be performed (from the Certification Authority Lab and the Licensee). This corresponds to the output of the previous phase called Evaluation Scope Process. Demonstration/submission of prior evaluations (from the Licensee) Source code of the Test Subject (from the Licensee), or an arrangement for a visit by the Laboratory s experts to the Licensee s secure premises. Test Subject samples (from the Licensee to the Laboratory). The number of samples that are required must have previously been determined by discussion between the Laboratory and the Licensee. At least 2 Test Subjects for each MIFARE product must be submitted. In practice, a Laboratory may require a greater number of test samples (10-20) for fault injection penetration tests. If the Licensee has any clarifications on the samples configuration details, the Licensee should clarify it with the Laboratory. If the Laboratory requires further clarification, the Laboratory should consult the Certification Authority Lab. Specification Rev January of 46

29 3.3.2 Flow Outputs At a minimum, the Vulnerability Analysis will include the following: 1. The Laboratory performs the following work tasks with regard to security requirements and security procedures defined for the scheme: a. Obtain existing evidence of compliance to acceptable standards validating quality assurance such as Common Criteria, EMVCo. If a deficiency in this part of the assessment is identified, then the Certificate Authority may determine that a thorough audit of the Licensee s site and development processes is required. b. Product documentation assessments. c. Application source code assessments. d. Further gathering and review of separate evaluation evidence. e. As required, site visit(s) to support these assessments. 2. The Laboratory defines the Test Subject s architecture, security functions and security assets regarding all possible threats, with regard to security requirements and procedures for the scheme. In this process, the Laboratory shall consider attacks and protections regarding both primary security assets (e.g., security-critical MIFARE application data and cryptographic keys for Crypto1, TDES and AES), and secondary security assets (e.g., application code). 3. The Laboratory evaluates the Test Subject s source code. If a Licensee decides not to disclose source code to the Laboratory, then in most circumstances this will necessitate a visit by the Laboratory to one of the Licensee s secure premises, where the source code can be evaluated in a secure environment., The Licensee s must support the evaluation lab in the code review session. For example they should, describe the design/architecture of the product, answer the Laboratory s questions and assist the Laboratory in the review. 4. The Laboratory derives a matrix of feasible attacks, considering all possible attacks that derive from security-related threats against all known assets. In the case of a delta evaluation, the Laboratory shall define which changes have been made between the product(s) submission and the reference product, in order to exclude those attacks that are not applicable. The matrix indicates the relative feasibility of all the possible cross-combinations. When the Evaluation Scope process is complete, the following Outputs shall be produced: Agreement between the Laboratory and the Licensee on the Scope of testing, pricing, estimated duration (from Laboratory to the Licensee) Approval from the Certification Authority Lab to proceed to the Penetration Test Plan Process. Specification Rev January of 46

30 3.4 Phase 4: Penetration Test Plan Process This phase is derived from the completion of the Phase 3 Vulnerability Analysis and consists of the development of a Penetration Test Plan by the Laboratory for delivery to the Licensee and to the Certification Authority Lab. The Penetration Test Plan defines the required work to be performed by the Laboratory in Penetration Testing. A summary of the Phase 4: Penetration Test Plan Process is provided in Figure 8 Penetration Test Plan Licensee NXP Certification Authority Laboratory Penetration Test Plan Test Subject Security level knowledge No Define the Penetration Test Plan Review the submitted Penetration Test Plan OK? Yes Approved Penetration Test Plan Penetration Test Plan Complete Figure 8 Penetration Test Plan Process Specification Rev January of 46

31 Table 6. RACI Matrix of Penetration Test Plan Process Roles Activities NXP Certification Authority Lab Laboratory Licensee Define the Penetration Test Plan Review the submitted Penetration Test Plan C Approve the Penetration Test Plan I Inputs Flow Outputs The Penetration Test Plan process requires that the following inputs shall be provided: The Lab has an exhaustive understanding of the security mechanisms embedded in the Test Subject. This corresponds to the output of the previous phase called Vulnerability Analysis Process. The minimum requirement for the Phase 4 Penetration Test Plan includes the following: 1. Derive a selection of tests to perform and provide a rationale for the tests that are not required.. Note this Penetration Test Plan is built according to the Vulnerability Analysis phase. The priority for this Penetration Test Plan is given to potential attack paths targeting primary assets. Then this Penetration Test Plan is submitted to the Certification Authority. 2. The Certification Authority may provide significant input to the Security Evaluation at this stage, for example by determining if any additional test item planning is required. The certification Authority will make a review of the Penetration Test Plan and provide a response back to the Evaluation Lab. This response will either be permission to progress to Penetration Testing, or a request for additional evaluation before progressing with or terminating the evaluation. 3. As soon as the Certificate Authority has approved the submitted Penetration Test Plan, the Lab sends it to the Licensee. At the conclusion of this stage, the following Outputs will be produced: An approved Penetration Test Plan. A decision by the Certification Authority Lab to move to the Penetration Testing Specification Rev January of 46

32 3.5 Phase 5: Penetration Testing Process The minimum scope of penetration testing to be performed by the Laboratory is the output from the Evaluation Scope phase, derived into work tasks defined in the Penetration Test Plan. A high-level process flow for Penetration Testing is shown in Figure 9. Penetration Testing Licensee NXP Certification Authority Laboratory Penetration Testing Approved Penetration Test Plan Test Samples Perform Penetration Testing Derive Security Assurance Rating Discuss additional tests with Licensee Communicate requirements to the Certification Authority via Yes More tests required? No Final Report Evaluation Report Lite Penetration Testing Complete Figure 9 Penetration Testing Process Specification Rev January of 46

33 Table 7. RACI Matrix of Penetration Testing Process Roles Activities NXP Certification Authority Laboratory Licensee Perform Penetration Testing Derive Security Assurance Rating Communicate requirements to the Certification Authority Lab via I Discuss additional tests with Licensee C Produce the Final Report Produce the Evaluation Report Lite Inputs Flow The Penetration Testing process requires that the following inputs shall be provided: The Penetration Test Plan approved by the Certification Authority. This corresponds to the output of the previous phase called Penetration Test Plan Process. In this phase, the laboratory performs practical Penetration Testing to ascertain the resistance of the Test Subject to attack. This testing will be based on the Test Plan as defined in Phase 4, Penetration Test Plan Process. 1. Based on the test results, the Laboratory must derive a Security Assurance rating as defined in the Joint Interpretation document ref [JIL] that describes to what extent the attacks on the Test Subject succeeded. The Security Assurance ratings are only a guide, and do not in themselves define a pass/fail condition. During the Penetration Testing, the Lab may perform additional tests to ascertain that the current Penetration Testing covers up-to-date attacks. For instance, if a new attack targeting a symmetric algorithm is unveiled, the Penetration Test Plan must be improved by adding a dedicated test targeted at the new attack. The Lab is responsible for informing the Licensee that additional testing is required which may involve additional cost. The Laboratory must produce the following two reports: a. The Final Report which is a comprehensive report containing all details of the test results. b. The Evaluation Report Lite which can be considered as a high level security report. It provides results of the testing, but not necessarily the details of how the testing was performed, which may be considered the IP of the Evaluation Lab. The Evaluation Report Lite must be built according to [MIFARE-ERL]. Specification Rev January of 46

34 3.5.3 Outputs When the Penetration Testing is complete, the following Outputs will be produced: The Final Report The Evaluation Report Lite (based on [MIFARE-ERL]) 3.6 Phase 6: Approval Process This last step concludes the security evaluation of the Test Subject. In this phase, an approval or a rejection is made. A high-level process flow for the Approval Process is shown in Figure 10. Specification Rev January of 46

35 Approval Licensee NXP Certification Authority Laboratory Approval Final Report Review the Final Report Evaluation Report Lite Approve final report The Certification Authority reviews The Evaluation Report Lite Discussion required? Yes Discussion with Lab on the Evaluation Report Lite evidence No Communicate results to the Licensee via No OK? Yes The Certification Authority approves Notified the security evaluation is completed Provide the Approval Reference Number Request for Approval completed Letter of Approval issued The CA lab sends letter of approval and certification report containing the corresponding Approval Reference Number Approval Complete Figure 10 Approval Process Specification Rev January of 46

36 Table 8. RACI Matrix of Penetration Testing Process Roles Activities NXP Certification Authority Laboratory Licensee Submit Final Report to the Licensee Review the Final Report Submit Evaluation Report Lite to the Certification Authority The Certification Authority reviews the Evaluation Report Lite Discussion with the Lab on the Evaluation Report Lite evidence The Certification Authority Lab approves (possibly with restrictions) Communicate results to Licensee via if the security evaluation fails NXP gives the Approval Reference Number The CA (possibly with restrictions): 1. Issues the Letter of Approval 2. Creates and sends the certification report to the Licensee C C R I I I I I I I Inputs Before the Approval Process can commence, the following input is required: The Final Report must be produced The Evaluation Report Lite must be produced This corresponds to the output of the previous phase called Penetration Testing Process. Specification Rev January of 46

37 NXP must provide an ARN for the final approval and certification report Flow The following tasks must be processed during the Approval process: 1. As soon as the Certification Authority receives the Evaluation Report Lite it starts reviewing it. 2. The Evaluation Report Lite may contain some sections which are unclear, not sufficiently detailedor missing. In this case, the Evaluation Lab must provide support to the Certification Authority so that the Evaluation Report Lite becomes clear. If some modifications are requested by the Certification Authority to make the Evaluation Report Lite more clear or consistent, the Lab will manage these improvements or corrections by sending a new version of the Evaluation Report Lite. 3. The Certification Authority reviews the Evaluation Report Lite, and then decides upon one of the following courses of action: a. Either Pass or Pass with comments b. Failed. The security evaluation has demonstrated that the Test Subject is not high resistant to some attacks. The dedicated JIL rating is employed to rate the attack. The Certification Authority Lab communicates the security evaluation has failed to the Licensee by . NXP will not be informed that the security evaluation has failed. Therefore details of the failure will not be made known. However, it will become obvious that a request for the Approval Reference Number is not being made, therefore it would make sense that when the evaluation process is finished, NXP should be informed. The evaluation could have terminated for a number of reasons, but it is not necessary to state why. Note that Additional testing may be required. This is at the sole discretion of the Certification Authority Lab. 4. Certification Authority Lab requests an Approval Reference Number from NXP and issues the Letter of Approval and the certification report with the ARN. One of the following decisions is possible: a. Pass b. Pass with comments NXP will respect the decision delivered by the Certification Authority Lab. NXP cannot change the Certification Authority Lab s decision. In other words, NXP endorses the role of observer preventing NXP from conflicts of interest. In addition, the Certification Authority will create and issue a certification report that summarizes the highlights of the certification. Both, the letter of approval and the certification report will be published on a website hosted by NXP. In case the Licensee has objections to making the letter of approval and the report public, he can request NXP to refrain from publishing these documents. Specification Rev January of 46