EMVCo Security Evaluation Process V5€¦ · 3.5.1 Send EMVCo Update Registration Questionnaire ... For CCD/CPA ICC products, ... EMVCo Security Evaluation Process v5.1 Page 10

© 2016 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.

EMV® Security Guidelines

EMVCo Security Evaluation Process

Version 5.1 June 2016

EMV Security Guidelines EMVCo Security Evaluation Process v5.1 Page 2 / 38


Legal Notice The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of the EMV Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party’s infringement of any intellectual property rights in connection with the EMV Specifications.



Version History Version Date Description

v4.0 December 2010 Introduction of the Platform security evaluation process.

v5.0 March 2015 This release clarifies the product renewal policy terms, and provides additional details on the initial and renewal registration, evaluation, and certification process.

v5.1 June 2016 This release references the product certification policy and introduces the terms of the expired product extension process. It provides additional details on the certification process.



Contents 1 Scope ............................................. ................................................................................ 7

1.1 Audience ................................................................................................................ 7

1.2 Overview ................................................................................................................ 8

1.3 Related Information ................................................................................................ 8

1.4 Support ................................................................................................................. 10

2 Overview .......................................... ............................................................................ 11

2.1 Background .......................................................................................................... 11

2.2 EMVCo Security Evaluation .................................................................................. 12

2.2.1 The Role of EMVCo in the Security Evaluation Process ............................ 12

2.2.2 Development and Production Site Audit .................................................... 13

2.2.3 IC Security Evaluation ............................................................................... 13

2.2.4 Platform Security Evaluation ..................................................................... 14

2.2.5 ICC Security Evaluation ............................................................................ 15

2.3 Security Assurance............................................................................................... 16

2.4 Risk Management ................................................................................................ 18

2.5 Changes to Previously Approved Products ........................................................... 19

2.6 EMVCo Approval Renewal Date ........................................................................... 19

3 Security Evaluation Process ....................... ............................................................... 20

3.1 Security Evaluation Roles and Responsibilities .................................................... 21

3.1.1 Maintain Security Guidelines ..................................................................... 21

3.1.2 Design Product ......................................................................................... 21

3.1.3 Test Product ............................................................................................. 21

3.1.4 Certify Product .......................................................................................... 21

3.1.5 Security Monitoring ................................................................................... 22

3.2 Compliance Certificates ........................................................................................ 23

3.2.1 Certifiable Products ................................................................................... 23

3.2.2 Types of Certificates ................................................................................. 23

3.3 Security Evaluation Process ................................................................................. 24

3.3.1 Sign EMVCo Agreement ........................................................................... 25

3.3.2 Complete EMVCo Registration Questionnaire .......................................... 25

3.3.3 Initial Discussion ....................................................................................... 25

3.3.4 Product Design ......................................................................................... 25

3.3.5 Select Laboratory and Decide Evaluation Details ...................................... 26

3.3.6 Assess Product and Product Provider Infrastructure ................................. 26

3.3.7 Submit Reports to EMVCo Security Evaluation Secretariat ....................... 28

3.3.8 Validate Laboratory Evaluation Reports .................................................... 28



3.3.9 Risk Analysis ............................................................................................ 29

3.3.10 Issue EMVCo Compliance Certificate ....................................................... 30

3.4 Certificate Renewal Process ................................................................................. 31

3.4.1 Send EMVCo Renewal Registration Questionnaire ................................... 31

3.4.2 Perform Renewal Evaluation with Laboratory ............................................ 31

3.4.3 Renew Product Certificate ........................................................................ 31

3.5 Certificate Update Process ................................................................................... 32

3.5.1 Send EMVCo Update Registration Questionnaire ..................................... 32

3.5.2 Perform Delta Evaluation with Laboratory ................................................. 32

3.5.3 Update Product Certificate ........................................................................ 32

3.6 Expired Product Extension Process ...................................................................... 33

3.6.1 Send EMVCo Extension Registration Questionnaire ................................. 33

3.6.2 Perform Extension Evaluation with Laboratory .......................................... 33

3.6.3 Extension Recognition Letter .................................................................... 33

Annex A Glossary .......................................... ................................................................ 34



Figures

Figure 1: EMVCo Security Evaluation Overview ................................................................. 20

Figure 2: EMVCo Security Evaluation Process................................................................... 24



1 Scope

This manual describes the EMVCo Security Evaluation Process requirements and procedures for Integrated Circuit (IC), Platform (IC + OS), and Integrated Circuit Card (IC + OS + App) products.

Registration

IC and Platform product providers shall follow the registration process described in this document to register their products.

For CCD/CPA ICC products, the registration process is managed by the Card Approval Secretariat, and is described in the EMVCo Card Type Approval Administrative Process documents [CTA AP].

Security Evaluation

All product providers shall follow the process outlined in this document in order to obtain and maintain security evaluation certificates for their products. Such certification will allow product providers to sell ICC products to issuers of ICCs bearing the brand marks of American Express, Discover, JCB, MasterCard, UnionPay, or Visa.

1.1 Audience

This manual is intended for:

• Product providers – To enable them to gain certification of their IC, Platform, and ICC products

• Laboratories – To give them a better understanding of the process followed by product providers, and to provide them with details on their role in the evaluation process

• Issuers – To provide them with valuable and practical information relating to the general security performance characteristics and the ‘suitability of use’ of IC, Platform, and ICC products



1.2 Overview

This document includes the following sections:

Chapter 1 – Scope provides a high-level overview of this document, including references to related information.

Chapter 2 – Overview provides a high-level description of the EMVCo Security Evaluation Process and its rationale.

Chapter 3 – Security Evaluation Process provides a description of the overall EMVCo Security Evaluation Process, leading to issuance of an EMVCo Compliance Certificate, as well as certificate renewal or update and expired product extension.

Annex A – Glossary includes all abbreviations and definitions.

1.3 Related Information

Throughout this document, the following references have been used. These references include the most current versions at the time of this document’s writing. For future use, the most current versions should be referenced.

Reference Document Title Version

[SG IC] EMVCo Security Guidelines for Smart Card Integrated Circuits

2 – Jan 2008

[SG CPA] EMVCo CPA Secure Implementation Guidelines 1 – Jan 2007

[SG PF] EMVCo Security Guidelines for Java Card, Multos and Global Platform Implementations including Mobile Payments

1.1 – Jun 2012

[CTA AP] EMVCo Card Type Approval Administrative Process for CCD

Available on www.emvco.com under Approvals & Certification, Card Type Approval, Process and Forms, CCD Process.

2.5 – Mar 2014

EMVCo Card Type Approval Administrative Process for CPA

Available on www.emvco.com under Approvals & Certification, Card Type Approval, Process and Forms, CPA Process.

2.5 – Mar 2014




[REQ LABS] EMVCo Requirements for Security Evaluation Laboratories

3 – Jan 2016

[REUSE] EMVCo SEWG – Reuse Of Evaluation Evidence May 2010

[JIL AM] JIL Attack Methods for Smartcards and Similar Devices 2.2 – Jan 2013

[JIL AP] JIL Application of Attack Potential to Smart Cards 2.9 – Jan 2013

[SITE AUDIT] EMVCo Security Guidelines – Development and Production Site Audit Guidelines

1.1 – May 2015

[PCP] EMVCo Security Guidelines – EMVCo Product Certification Policy – Technical Requirements

1 – Apr 2016

The Bulletins listed below are available on www.emvco.com under Approvals & Certification, Security Evaluation, Process and Forms, Process Updates.

[BL1] EMVCo SEWG Bulletin 1 – Insurance Requirements for Functional Evaluation Laboratories and Security Evaluation Laboratories

1 – Jun 2009

[BL2] EMVCo SEWG Bulletin 2 – Product Renewal and Reuse of Evaluation Evidence

1 – Jun 2010

[BL3] EMVCo SEWG Bulletin 3 – Evaluation Review Fees 2 – June 2011

[BL4] EMVCo SEWG Bulletin 4 – Updated Insurance Requirements for Functional Evaluation Laboratories and Security Evaluation Laboratories

1 – Oct 2010

[BL5] EMVCo SEWG Bulletin 5 – Platform Evaluation Process

2 – Oct 2013

[BL6] EMVCo SEWG Bulletin 6 – ICCN and PCN Product Renewal Policy Update

1 – Oct 2011

[BL7] EMVCo SEWG Bulletin 7 – Development and Production Site Audit

2 – May 2015

[BL8] EMVCo SEWG Bulletin 8 – Code Delivery Policy Update

2 – Dec 2013




[BL9] EMVCo SEWG Bulletin 9 – Platform Security Guidance Update

1 – May 2013

[BL10] EMVCo SEWG Bulletin 10 – No Security Impact – Fast Track Review Process

1 – Jun 2014

[BL11] EMVCo SEWG Bulletin 11 – Platform Derivative Certificate Numbering Policy Update

1 – Oct 2014

[BL12] EMVCo SEWG Bulletin 12 – Typical Workload Guidelines for Platform and ICC Product Evaluations

1 – Dec 2014

[BL13] EMVCo SEWG Bulletin 13 – Platform Evaluation Scoping

1 – May 2015

1.4 Support

For help and support, contact the EMVCo Security Evaluation Secretariat at [email protected].



2 Overview

This chapter provides a high-level description of the EMVCo Security Evaluation Process and its rationale.

2.1 Background

EMVCo acts as the security certification entity for all approvals relating to the security of IC, Platform, and ICC products intended for use in payment cards issued by EMVCo members. EMVCo oversees and administers the security evaluation process and maintains security guidelines ([SG IC], [SG PF], and [SG CPA]).

The EMVCo security guidelines support product providers in developing and testing their products, and test laboratories in performing security evaluations.

The EMVCo Security Evaluation Process evaluates the security features of IC, Platform, and ICC products.

• IC Security Evaluation includes the firmware and software routines required to access the security functions of the IC.

• Platform Security Evaluation includes the Integrated Circuit (IC) hardware with its dedicated software, Operating System (OS), Run Time Environment (RTE), and Platform environment on which one or more applications (e.g., CCD, CPA) can be executed.

• ICC Security Evaluation includes the IC, the Operating System, and the CCD/CPA payment application(s) that reside(s) on the ICC.

The EMVCo Security Evaluation Process also takes into account the security of the design, development, and delivery processes.



2.2 EMVCo Security Evaluation

The EMVCo Security Evaluation Process is based on a complete set of published EMVCo documents (specifications, requirements, and security guidelines) made available to product providers and security evaluation laboratories for the development and security evaluation of their products.

The EMVCo composite security evaluation approach reflects the structure of the ICC industry, taking into account the relationships between the component suppliers of Platform and ICC products, their development processes, and the fact that IC migrations are underway. It also reflects developments in security evaluation methodology by the ICC industry, and combines independent evaluations with internal security testing. This flexibility allows EMVCo to maintain a high level of security assurance, while minimising evaluation time and financial burden on product providers.

2.2.1 The Role of EMVCo in the Security Evaluation Process

EMVCo has established a common security evaluation process that assists IC manufacturers, Platform product providers, and ICC product providers in promoting the continuous improvement of security standards in the implementation of their products.

The methodology used in the evaluation process leverages a program of research targeted at the leading edge of attack methodology. In addition, EMVCo supports the work of the JIL Hardware Attack Subgroup (JHAS) and related subgroups or initiatives working on specific security topics, to maintain a common set of current threats and attacks.

This process benefits both issuers and product providers by defining a flexible, state of the art, common security evaluation methodology that is recognised by all stakeholders, thus saving time and avoiding the duplication of effort when evaluating IC, Platform, and ICC products as well as their development environments. Product providers are responsible for ensuring that the security evaluation of their products is performed.

EMVCo does not, however, guarantee or provide any warranties for any product provider’s products, and the security evaluation process does not relieve issuers from the need to make their own investigations to ensure the security or fitness for purpose of any products. No product implementation can be 100% secure, but as explained later, the EMVCo Security Evaluation Process provides product users and issuers with additional information to assist in their risk analysis with product providers.

The security evaluations are performed by EMVCo recognised, independent security evaluation laboratories and funded by product providers. Security evaluation can take advantage of evaluation work already performed by product providers (see EMVCo Reuse Of Evaluation Evidence policy [REUSE]); however, this may need to be supplemented by additional work.

Upon successful completion of an EMVCo security evaluation for an IC, Platform, or ICC product, the EMVCo Security Evaluation Secretariat issues a compliance certificate.



2.2.2 Development and Production Site Audit

The security evaluation of an IC, Platform, or ICC product also includes an onsite audit of the product provider’s development, production, and delivery infrastructure. This includes the facility at which the product will be programmed (e.g., in the case of a flash memory product).

EMVCo has defined common requirements and guidelines for security evaluation laboratories to use when performing such audits at the product provider’s development and production site(s). The process allows for re-use of existing audit results and reports to avoid duplication of effort.

For more detailed information on the audit process, please refer to SEWG Bulletin 7 [BL7] and EMVCo Development and Production Site Audit Guidelines [SITE AUDIT].

2.2.3 IC Security Evaluation

The EMVCo IC Security Evaluation considers the security of the IC product, and is intended to provide a high level of assurance in the security functions that are designed to effectively deal with known attack methods. Attack methods include threats such as reverse engineering, information leakage, and fault injection.

The EMVCo IC Security Evaluation covers the following:

• IC security functions and libraries offered to the upper layers

• If applicable, IC code loading mechanisms (e.g., Flash loader)

• IC security guidance documents

IC Product for IC Security Evaluation

The IC product submitted for IC Security Evaluation is uniquely identified as:

• A specific integrated circuit with associated

• Firmware or software libraries that allow access to the security functions of the IC



2.2.4 Platform Security Evaluation

The EMVCo Platform Security Evaluation considers how the Platform developed by the product provider follows relevant security guidelines. An important factor is how the product provider builds upon the security of the IC to provide security for the complete Platform product. Based on the initial declaration from the Platform product provider in the Registration Questionnaire, the Platform is evaluated either:

• In an open Platform configuration: Application loading and installation in the field is enabled during the Platform’s usage phase.

• In a closed Platform configuration: Application loading and installation is deactivated during Platform personalization, so that no application on the card can be changed in the field. The Platform can then be considered as a final product.

The EMVCo Platform Security Evaluation covers the following:

• Secure storage and execution space provided to applications by the Platform Run Time Environment

• Platform services offered to the applications

• Card content management services, including:

o Security management (e.g., application downloading, card locking)

o Security domains for multi-provider Platforms

o Secure communication between the on-card representatives and off-card systems

• Platform security guidance document(s) (similar to user guidance documentation provided by chip hardware manufacturers)

Platform Product for Platform Security Evaluation

The Platform product submitted for Platform Security Evaluation is uniquely identified as:

• A combination of the following:

o A specific Integrated Circuit (IC) with its dedicated software

o The Operating System (OS) software developed for a specific IC

o The Run Time Environment (RTE) (e.g., Java Card) and associated RTE API providing interface with the applications

o The Platform environment (e.g., GlobalPlatform) and in particular the Security Domains with card content management privileges

o Applications or packages (either native or interpreted) that provide Platform functionalities and as such are considered part of the Platform as defined in SEWG Bulletin 13 [BL13]

• That is able to execute one or more applications (e.g., CPA, CCD)



2.2.5 ICC Security Evaluation

The ICC Security Evaluation considers how the payment applications developed by the product provider follow the relevant security guidelines. An important factor is how the product provider builds upon the security of the IC and the OS or the underlying approved Platform to provide overall security for a payment application on the ICC.

The EMVCo ICC Security Evaluation covers the following:

• Secure implementation of financial applications protecting EMVCo assets

• Security assessment of any non-financial applications present on the product

When the ICC evaluation does not build on an approved Platform, additional security assessment is required, as applicable:

• Services provided to the application(s) by the underlying OS

• Implementation of MULTOS or Java Card virtual machines and APIs, including application and data segregation

• Application loading mechanism (e.g., GlobalPlatform)

ICC Product for ICC Security Evaluation

The ICC product submitted for ICC Security Evaluation is uniquely identified as:

• The complete EMV CCD/CPA application(s) present on a

• Specific integrated circuit with a

• Specific operating system and transmission protocol(s) surrounded by a

• Specific environment including other non-EMV CCD/CPA applications and/or software components



2.3 Security Assurance

The EMVCo Security Evaluation Process strives for a high level of assurance for IC, Platform, and ICC products at all stages of the development process. The evaluation methodology balances ‘black box’ and ‘white box’ testing, performing a security analysis that considers all viable attacks on a product in order to derive a set of penetration tests based on individual product characteristics.

The level of assurance requirement is High as per the levels of resistance to attacks defined in JIL Application of Attack Potential to Smart Cards [JIL AP].

EMVCo recognises external evaluation laboratories to perform security evaluations using the relevant EMV Security Guidelines and externally developed testing tools. EMVCo may leverage previous work performed by the product provider. EMVCo recognises the methodology used in some formal evaluation schemes (e.g. Common Criteria), but will accept only full evaluation reports as evidence of such evaluation.

The EMVCo Security Evaluation Process reflects a partnership with product providers, and is designed to minimise the cost and time spent in performing evaluation work and to avoid duplication of effort. Evaluations that are based on a core family of devices can use delta evaluations to manage product migration. Associated design and production processes are evaluated once, and paperwork overhead is reduced.

The EMVCo Security Evaluation Secretariat supports the process with a research program that seeks optimal awareness of threats and defences whilst maintaining confidential relationships with laboratories and product providers.

Once all steps of the EMVCo Security Evaluation Process (see Chapter 3) have been fulfilled, an EMVCo Compliance Certificate can be issued for a product, with:

• A number that identifies a single approval path from product provider through manufacturer to issuer

• A date that reflects the version of the EMVCo security guidelines at the time of evaluation

Product providers must present their EMVCo Compliance Certificate number to issuers as proof that their product has been evaluated via the EMVCo Security Evaluation Process.

Note Users (product providers, issuers, mobile han dset providers, etc.) should always check both the status and the date of any EMVCo Compliance Certificate.



In some cases where a vulnerability is found, an EMVCo Restricted Compliance Certificate may be issued. If this happens, the product provider is made fully aware of the details of any such problems through the laboratory evaluation report, and EMVCo will work with the product provider to achieve two things:

• To ensure that the product provider adequately communicates the vulnerability to issuers to enable them to assess their own risks

• To ensure that the product provider (with assistance from EMVCo) establishes a plan to introduce a revised product that reduces the vulnerability

Note EMVCo reserves the right to withdraw or not t o issue an EMVCo Compliance Certificate or EMVCo Restricted Complian ce Certificate when the product does not offer sufficient protecti on.

Each EMVCo Approved IC, Platform, and ICC product is granted a certificate or a restricted certificate with an issue date and expiry date, and is placed on the corresponding EMVCo Approved Products list. Each certificate has a unique ICCN (Integrated Circuit Certificate Number), PCN (Platform Certificate Number), or CCN (Card Certificate Number).

The older a product is, the greater the array of attacks it may be subject to; therefore:

• EMVCo Approved IC and Platform products undergo annual security assessments following the initial assessment.

• EMVCo ICC products begin annual security assessments three years after the initial assessment.

Unless the certificate is withdrawn or the product is superseded by newer products, the product remains on the EMVCo Approved Products list if it passes the annual security review. When a product reaches the six-year limit on the EMVCo Approved Products list, it is removed.

Quite frequently, several product physical characteristics or software security functionalities and mechanisms are transferred without significant changes to new vendor products. As this might allow attackers to reproduce an attack on several devices, it is necessary to monitor and possibly restrict such re-use. In order to minimise risk, EMVCo has established technical requirements, defined in EMVCo Product Certification Policy – Technical Requirements [PCP]. A product must comply with these requirements to be considered new from a security evaluation perspective and to be eligible for a new certificate issue date.

When a composite product is to be renewed on an expired IC or Platform product, it is likely that no fresh evidence is available for the IC or Platform level. In order to avoid this situation, EMVCo has introduced an extension recognition process that enables the IC or Platform product owner to provide fresh evidence to composite evaluations whenever needed.



2.4 Risk Management

The finance industry is a risk management business that has to constantly monitor vulnerabilities and threats. Fraud migrates to the lowest level of defences in a system and the security features of the payment application should provide a number of risk management measures. The EMVCo Security Evaluation Process supplements these efforts by making product Security Evaluation a necessary part of the product provider’s product design and development process. When a product provider sells a product, that product provider should be able to explain the testing that has been carried out in order to verify conformance with EMVCo security guidelines.

The level of testing continuously increases to reflect state of the art attack potential. Consequently, new products should offer a higher level of protection against the latest threats. However, no testing can anticipate all potential future attacks. Security, by definition, is an ongoing process – attack and defence follow one another in a continual race. EMVCo endeavours to be always one step ahead of the attacker.

Issuers should constantly bear in mind that there is no such thing as perfect security. The primary assets on an ICC product are the secret keys and the PIN. There are also secondary assets (i.e., assets that that can be used to compromise a primary asset), such as offline counters. An attack made with sufficient effort (in terms of skills, equipment, and time) will always succeed in compromising those assets. The EMVCo Security Evaluation Process aims to identify vulnerabilities in these terms so as to be usable for risk analysis.

A secure system must implement defences at all levels, and issuers should develop separate strategies for prevention, detection, and recovery. There are essentially two motivations for an attacker: publicity and reward. Incident management procedures should be planned for each, and appropriate security measures should be taken to limit the likely rewards that an attacker may achieve for their efforts.

In the event that an IC, Platform, or ICC product only receives an EMVCo Restricted Compliance Certificate, the product provider should be able to explain the reasons and to offer guidance about the potential risks to an issuer’s implementation plans. Issuers may mitigate these risks – to a level that is acceptable to them – by using other security measures (such as the use of online transactions, limited issuance, etc.).



2.5 Changes to Previously Approved Products

Any change to a previously approved product will require a Security Impact Analysis (SIA) which must be provided to, and approved by, the EMVCo Security Evaluation Secretariat.

Based on the Security Impact Analysis, a delta evaluation may need to be performed before the EMVCo Compliance Certificate can be issued for a changed product.

In cases where the Security Impact Analysis concludes that the changes made to the product are minor and have no security impact (and therefore no additional testing is performed), a Fast Track report review process will be applied, as defined in SEWG Bulletin 10 [BL10]. See also section 3.5.

2.6 EMVCo Approval Renewal Date

The approval for an IC, Platform, or ICC product applies as of the date of the certificate. Unless the certificate is withdrawn or the product is superseded by newer products from the product provider, products with an EMVCo Compliance Certificate are removed from the EMVCo Approved Products list after one year for IC and Platform products and after three years for ICC products, unless approval is renewed. Products that reach the six-year limit will be removed from the list.

Products seeking renewal must comply with current security guidelines. For further details on product approval renewal, please refer to SEWG Bulletins 2 and 6 ([BL2], [BL6]) for IC and Platform products and to Card Type Approval Administrative Process [CTA AP] for ICC products, and contact the EMVCo Security Evaluation Secretariat for any remaining questions.



3 Security Evaluation Process

This chapter describes the EMVCo Security Evaluation Process leading to the issuance of an EMVCo Compliance Certificate.

Figure 1 depicts an overview of EMVCo Security Evaluation.

Figure 1: EMVCo Security Evaluation Overview



3.1 Security Evaluation Roles and Responsibilities

The following sections describe the various EMVCo Security Evaluation sub-processes:

• Maintain Security Guidelines

• Design Product

• Test Product

• Certify Product

• Security Monitoring

3.1.1 Maintain Security Guidelines

EMVCo maintains a set of guidelines (listed in section 1.3) that provide security guidance for the design of IC, Platform, and ICC products. These guidelines are not intended to be exhaustive but rather informative, supporting product providers in the development of their products and supporting laboratories as they assist in the evaluation of IC, Platform, and ICC products within the framework of the EMVCo Security Evaluation Process.

The security guidelines present the basic principles of smart card security to ensure that every product provider has the same understanding of the threats in this environment. They provide basic recommendations for protection against these threats and then refine them step by step up to specific points related to individual security features.

3.1.2 Design Product

The product provider designs its products in accordance with the applicable security guidelines.

No guideline is mandatory. The guidelines draw a comprehensive picture of means to secure IC, Platform, and ICC implementations. A developer may decide not to follow a guideline. In this case, the developer has to demonstrate either that the product provides an equivalent assurance level through another means, or that the guideline is not applicable to the product.

3.1.3 Test Product

The EMVCo recognised laboratory selected by the product provider receives the product design as well as samples, and assesses the product (and where considered necessary, the related processes) independently to determine whether the product provider has sufficiently taken threats and attacks into account.

3.1.4 Certify Product

Upon completion of the evaluation, the laboratory submits an evaluation report to the EMVCo Security Evaluation Secretariat for approval and product certification.

Refer to section 3.3 for further details of the ‘Test Product’ and ‘Certify Product’ processes.



3.1.5 Security Monitoring

The EMVCo Security Evaluation Secretariat operates an ongoing process to check approved products against newly identified attacks and risks by:

• Continuously monitoring threats and security developments within the smart card market.

• Conducting research and development – both itself and with security evaluation laboratories – to identify new threats, attacks, and security evaluation methodologies.

Where it considers this necessary (and where it is able to do so given confidentiality restrictions) the EMVCo Security Evaluation Secretariat may inform product providers about newly discovered vulnerabilities of their approved products, thus enabling the product provider to minimise consequent risks and to support their customers’ risk management. This may also include the withdrawal of an EMVCo Compliance Certificate or an EMVCo Restricted Compliance Certificate.



3.2 Compliance Certificates

Compliance certificates issued by EMVCo confirm that the product provider’s product(s) identified on the certificate have undergone the appropriate security evaluation, and that a risk analysis on any significant residual vulnerability has been performed (where applicable).

3.2.1 Certifiable Products

Following a successful IC Security Evaluation, EMVCo issues an EMVCo Compliance Certificate for the integrated circuit component of an ICC.

Similar variations of the same product – such as an IC core, but with various memory configurations – can be assessed as a single subject and covered by a single certificate.

Following a successful Platform Security Evaluation, EMVCo issues an EMVCo Compliance Certificate for the Integrated Circuit (IC) hardware with its dedicated software, Operating System (OS), and Platform environment on which one or more applications (e.g., CPA) can be executed.

Following a successful ICC Security Evaluation, EMVCo issues an EMVCo Compliance Certificate for the combined IC, operating system, and payment application(s) components of an ICC.

3.2.2 Types of Certificates

A certificate may be issued in one of two variants, depending on whether any significant residual vulnerability was discovered during the evaluation process.

EMVCo Compliance Certificate

If any residual vulnerability discovered during the evaluation process is considered by the EMVCo SEWG to be below the level that EMVCo regards as significant, then EMVCo will issue an EMVCo Compliance Certificate for that product.

EMVCo Restricted Compliance Certificate

If significant residual vulnerabilities are discovered during the evaluation process but are considered a manageable risk by the EMVCo SEWG, are sufficiently explained in the Risk Analysis Report, and are being satisfactorily addressed by the product provider, EMVCo will issue an EMVCo Restricted Compliance Certificate for that product.

EMVCo is entitled to publish non-security related details of restricted compliance certificates. The product provider is required to inform the issuer (or other product provider) to whom that product provider intends to sell the product covered by an EMVCo Restricted Compliance Certificate of the product vulnerabilities so that the prospective purchaser may understand the risk in using the restricted product. This is necessary so that the product provider’s customers can accommodate the remaining risks within their own risk assessments, and introduce appropriate countermeasures against these remaining risks into their own systems.



3.3 Security Evaluation Process

The following sections describe the actions within the EMVCo Security Evaluation Process, as shown in Figure 2.

Figure 2: EMVCo Security Evaluation Process



3.3.1 Sign EMVCo Agreement

EMVCo and the product provider sign an EMVCo agreement covering the EMVCo Security Evaluation Process, including confidentiality and other aspects.

This process step results in both the product provider and the EMVCo Security Evaluation Secretariat receiving a signed version of the agreement.

3.3.2 Complete EMVCo Registration Questionnaire

The product provider completes an EMVCo questionnaire defining details of the product intended for evaluation and related administrative information.

This process step results in the product provider providing the EMVCo Security Evaluation Secretariat with the necessary completed EMVCo Registration Questionnaire:

For IC EMVCo Product Registration Questionnaire for Chip Providers

For Platform EMVCo Product Registration Questionnaire for Platform Providers

For ICC EMVCo Common Payment Application Level 1 & Level 2 Implementation Conformance Statement, as provided for functional approval; for details, see [CTA AP]

3.3.3 Initial Discussion

Initial discussions between the product provider and the EMVCo Security Evaluation Secretariat are conducted to develop a common understanding of the evaluation process and of the underlying information required. The product provider should obtain the relevant EMVCo security guidelines and use them to identify any necessary additional product requirements.

If available, the product provider should submit evidence of any security evaluations already carried out on the product. This will enable the EMVCo Security Evaluation Secretariat’s staff to resolve any questions and concerns in advance. If needed, a conference call or meeting can be organised.

3.3.4 Product Design

The product provider finalises the design of the product (if not completed prior to initiation of the EMVCo Security Evaluation Process) or updates the product in response to the requirements derived from the relevant security guidelines.

This phase may also include conducting (or amending) a self- or third-party evaluation of the security performance of the product and the underlying development and production processes.

This process step results in the product provider producing design documentation and product samples.



3.3.5 Select Laboratory and Decide Evaluation Detai ls

After the EMVCo Security Evaluation Secretariat reviews any security evaluations of the product performed by the product provider or a third party, the product provider and the EMVCo Security Evaluation Secretariat agree on precise details of the EMVCo evaluation, including:

• A list of mandatory evaluations

The EMVCo Security Evaluation Secretariat will take into account the needs of the product provider, as well as any previous evaluation work, but reserves the final decision about the minimum set of evaluation work considered necessary within the EMVCo Security Evaluation Process.

• The laboratory(ies) to be used

EMVCo recognises a number of laboratories and can discuss them with the product provider.

The product provider and the EMVCo Security Evaluation Secretariat will often reach this agreement as part of the initial discussions (discussed in section 3.3.3), provided that they agree that the product has already reached a sufficient maturity to prepare the evaluation.

This process step results in the issue of purchase orders to the laboratories. Where necessary, product providers can agree to appropriate Non-Disclosure Agreements (NDAs) with the laboratories at this stage.

3.3.6 Assess Product and Product Provider Infrastru cture

The evaluation of the IC, Platform, or ICC product includes a threat and vulnerability assessment of identified security assets.

The EMVCo Security Evaluation Process considers security assets to be categorised as follows:

• Primary assets:

o PIN, PIN Try Counter, ATC

o Cryptographic keys

o Operating System (Platform) code, execution context, and registry data

o State machine

• Secondary assets:

o Application code

o Application data (for example, cardholder-specific data, offline counters, and limits)

o Transaction data (for example, log files)

o Design information (for example, layout, process details, and test code)



The vulnerability analysis should, at a minimum, include currently known attacks (threats) as described in JIL Attack Methods for Smartcards and Similar Devices [JIL AM]. At present, these include:

• Physical attacks: reverse engineering, active and passive probing, FIB, etc.

• Overcoming sensors and filters

• Exploitation of test features (re-enter IC test mode)

• Perturbation attacks: laser or EM fault injection, voltage or frequency glitches

• Differential Fault Analysis (using single or multiple faults)

• Side channel analysis (SPA, DPA, EMA, template attacks, etc.)

• Attacks on RNG (operating conditions or physical manipulation, leakage analysis)

• Software attacks (protocol, man-in-the-middle, replay attacks)

• Logical attacks (application segregation, malicious and ill-formed applications)

The laboratories perform the required evaluations and provide evaluation reports documenting the results.

An evaluation may include physical testing of product samples, assessment of the design documentation, or auditing of the product provider’s development and production processes (see section 2.2.2 – Development and Production Site Audit) to ensure that social engineering, coercion, and bribery threats are addressed.

Laboratories are to construct evaluation reports as follows:

• Detail the product and the list of its security features included in the scope of evaluation.

• Describe the product development and production life cycle, including the list of the development and manufacturing sites.

• Include a complete vulnerability analysis against the threats discussed in [JIL AP] and the applicable EMVCo security guideline document, detailing any residual vulnerabilities.

• Base the conclusions of the evaluation on guidance provided in [JIL AP].

• Provide sufficient reporting of penetration testing to prove that the tests were completed as appropriate in order to reach the conclusions on the assurance level.

• Include demonstration of equivalence to CC EAL4+ (especially AVA_VAN.5). This allows product providers to re-use the results of their CC evaluations if they choose.



3.3.7 Submit Reports to EMVCo Security Evaluation S ecretariat

The laboratory prepares an evaluation report package that must include the following:

• The main EMVCo Evaluation Report, plus annex reports if applicable

• For IC or Platform evaluation, the applicable Shared Evaluation Report, as per the template defined and made available to laboratories by EMVCo

• The corresponding product Registration Questionnaire

The laboratory should get the questionnaire from the product provider and ensure that the information it contains is still up to date. If this is not the case, laboratory staff should advise the product provider to update the questionnaire, so that the final version delivered to EMVCo accurately reflects the information in the report.

The laboratory encrypts the evaluation report package and submits it to the EMVCo Security Evaluation Secretariat.

3.3.8 Validate Laboratory Evaluation Reports

The EMVCo Security Evaluation Secretariat reviews the EMVCo Evaluation Report from the security evaluation laboratory.

Based on the review, the EMVCo Security Evaluation Secretariat may require further evaluation to be performed, in which case the process continues, going back to the ‘Select Laboratory and Decide Evaluation Details’ step described in section 3.3.5.

The EMVCo Security Evaluation Secretariat will base its final judgments on current JIL guidance [JIL AM] and [JIL AP].

If the EMVCo Security Evaluation Secretariat considers that the evaluation provides sufficient assurance, the Secretariat prepares an EMVCo Summary Report and, if vulnerabilities have been discovered, a Residual Vulnerability Report as part of the EMVCo Summary Report.

Note EMVCo reserves final authority over the conte nts of the EMVCo Summary Report and any Risk Analysis Report.

The EMVCo Summary Report is submitted to EMVCo SEWG for final approval of the product evaluation.



3.3.9 Risk Analysis

Based on the evaluation results provided by the laboratories and the reports generated as a result of the ‘Validate Laboratory Evaluation Reports’ step (section 3.3.8), the product provider and the EMVCo Security Evaluation Secretariat together – typically during a meeting – perform an assessment of the risks resulting from the vulnerabilities discovered.

The product provider may decide to remedy the vulnerabilities discovered and restart the EMVCo Security Evaluation Process at the ‘Select Laboratory and Decide Evaluation Details’ step (section 3.3.5).

If residual vulnerabilities are discovered that the EMVCo SEWG considers significant enough to result in the issuance of an EMVCo Restricted Compliance Certificate, and the product provider decides not to remedy these vulnerabilities, then the product provider and the EMVCo Security Evaluation Secretariat jointly prepare a Risk Analysis Report containing information for issuing banks (or other product providers) that intend to use the product. Payment System restrictions may apply on the usage of such products.

The EMVCo Security Evaluation Secretariat will attempt to understand – and take into account – the product provider’s wishes with respect to the content of the Risk Analysis Report. However, EMVCo reserves final authority over the content of this Risk Analysis Report in order to provide issuers with reliable information for a valid risk assessment of their ICC projects.



3.3.10 Issue EMVCo Compliance Certificate

If the EMVCo Summary Report prepared by the EMVCo Security Evaluation Secretariat concludes that sufficient assurance has been demonstrated, and is approved by the SEWG, EMVCo will issue the product provider an EMVCo Compliance Certificate for that product.

If the EMVCo Security Evaluation Secretariat concludes that vulnerabilities discovered during the evaluation process are being satisfactorily addressed by the product provider and are sufficiently explained by the Risk Analysis Report, EMVCo may issue the product provider an EMVCo Restricted Compliance Certificate for that product.

Each certificate will contain a unique four-digit reference number using the following convention:

ICCNxxxx – Integrated Circuit Certificate Number – a unique number identifying the integrated circuit that has been approved, and its related devices.

PCNxxxx – Platform Certificate Number – a unique number identifying the Platform that has been approved. Derivatives from the parent platform will be further differentiated with an extension to the certificate number PCNxxxx.yy.

CCNxxxx – Card Certificate Number – a unique number identifying the ICC platform and application that has been approved.

RxCNxxxx – Restricted Product (IC, Platform, or Card) Certificate Number – a unique number identifying the product that has been approved with restrictions. Payment System restrictions may apply on the usage of such products.

A list of all public1 approved products and their associated compliance certificates is available from the EMVCo website: www.emvco.com.

Note EMVCo reserves the right to withdraw or not t o issue an EMVCo Compliance Certificate or EMVCo Restricted Complian ce Certificate if it is clear that the product does not offer sufficient protection against the threats identified in the relevant security guideli nes.

1 The product provider may request that its product not be listed.



3.4 Certificate Renewal Process

This section summarises the steps to be followed for the renewal of a previously issued EMVCo Compliance Certificate.

3.4.1 Send EMVCo Renewal Registration Questionnaire

The product provider first needs to send the EMVCo Security Evaluation Secretariat an up-to-date version of the product Registration Questionnaire, checking the ‘Renewal evaluation’ checkbox and indicating the original certificate reference.

On receipt of the questionnaire, EMVCo will generate a new invoice, as described in section 3.3.2.

3.4.2 Perform Renewal Evaluation with Laboratory

The product provider sends the appropriate material (samples, up-to-date guidance documentation, etc.) to the selected security evaluation laboratory. The laboratory conducts a renewal evaluation process, refreshing the activities described in section 3.3.6 and taking into account the latest identified threats and attacks, as well as EMVCo security guidelines. These activities shall be performed no earlier than six months prior to the expiry date.

Note that if a different laboratory is used for the renewal evaluation, the newly selected laboratory will have to conduct a full evaluation.

3.4.3 Renew Product Certificate

Upon completion of the evaluation, the security evaluation laboratory will deliver a renewal report to the EMVCo Security Evaluation Secretariat, which will examine the report, as detailed in sections 3.3.7 and 3.3.8. The renewal report shall be submitted no earlier than four months prior to the expiry date. If approved, a renewal certificate with an extended expiry date will be issued.

This process can be repeated several times until the product reaches the end of its life cycle, in accordance with the life cycle rules defined by EMVCo.



3.5 Certificate Update Process

This section summarises the steps to be followed for the update of a previously issued EMVCo Compliance Certificate, following changes to the product, its documentation, or the development environment.

3.5.1 Send EMVCo Update Registration Questionnaire

The product provider first needs to send the EMVCo Security Evaluation Secretariat an up-to-date version of the product Registration Questionnaire, checking the ‘Update evaluation’ checkbox and indicating the original certificate reference.


3.5.2 Perform Delta Evaluation with Laboratory

The product provider sends the appropriate material (updated samples, guidance documentation, etc.) to the selected security evaluation laboratory, which runs a delta evaluation process. This process will focus on the changes in the product design or its documentation, and may lead to additional code review and testing activities as described in section 3.3.6. The evaluation also takes into account the latest identified threats and attacks, as well as EMVCo security guidelines.

Note that if a different laboratory is used for the delta evaluation, the newly selected laboratory will have to conduct a full evaluation.

If the laboratory’s Security Impact Analysis (SIA) report concludes that the changes made to the product are minor and have no security impact (and no additional testing has therefore been performed), the laboratory shall clearly indicate this when sending the SIA to the EMVCo Security Evaluation Secretariat. If all prior administrative requirements are fulfilled, the report will be eligible for the Fast Track report review process (review to be performed by the Security Evaluation Secretariat within one working week of receipt of the report). Please refer to SEWG Bulletin 10 [BL10] for more detailed information on this process.

3.5.3 Update Product Certificate

Upon completion of the evaluation, the security evaluation laboratory will deliver a delta evaluation report to the EMVCo Security Evaluation Secretariat, which will examine the report as detailed in sections 3.3.7 and 3.3.8. If approved, an updated version of the product certificate will be issued.

This process can be run at any time during the product life cycle.



3.6 Expired Product Extension Process

Composite products to be submitted for renewal can be built on an expired IC or Platform product. In order to facilitate these composite product renewals, the expired product extension process enables the IC or Platform product owner to provide fresh evidence to composite evaluations whenever needed. This section summarises the steps to be followed for such extension.

Upon completion of extension work, the security evaluation laboratory may submit a report to be examined by the EMVCo Security Evaluation Secretariat. A successful review will result in the private issuance of an Extension Recognition Letter to the vendor for the expired IC or Platform product.

3.6.1 Send EMVCo Extension Registration Questionnai re

The product provider first needs to send the EMVCo Security Evaluation Secretariat an up-to-date version of the product Registration Questionnaire, checking the ‘Extension evaluation’ checkbox and indicating the expired certificate reference.


3.6.2 Perform Extension Evaluation with Laboratory

The product provider sends the appropriate material (samples, up-to-date guidance documentation, etc.) to the selected security evaluation laboratory. The laboratory conducts an extension evaluation process, refreshing the activities described in section 3.3.6 and taking into account the latest identified threats and attacks, as well as EMVCo security guidelines. These activities can be performed whenever needed as they are only intended to provide fresh evidence to renewal composite product evaluations building on expired IC or Platform products. Note that if a different laboratory is used, this extension evaluation must be conducted as a new evaluation.

3.6.3 Extension Recognition Letter

Upon completion of the evaluation, the security evaluation laboratory will deliver a report to the EMVCo Security Evaluation Secretariat, which will examine the report, as detailed in sections 3.3.7 and 3.3.8. A successful review will result in the private issuance of an Extension Recognition Letter to the vendor for the expired product. This letter will feature the expired ICCN or PCN certificate number complemented with an ‘X’ suffix as a reference (e.g., ICCNyyyyX), and will provide the details of the expired IC or Platform product and its security components.

The Extension Recognition Letters will not be published on the website.



Annex A Glossary

The following terms are relevant to the testing process:

Term Definition

API Application Programming Interface

Application Software package intended to be executed on top of a Platform.

Approved product A product that has been issued an EMVCo Compliance Certificate.

Card A payment card as defined by a Payment System; for the purpose of this document, a card comprises an Integrated Circuit, Operating System, Environment, and one (or more) EMV Application(s).

Card Certificate Number (CCN)

A unique four-digit reference number that identifies the EMVCo Compliance Certificate of an ICC.

Card Type Approval Verification by EMVCo that the specified ICC product has demonstrated sufficient conformance to the EMV Specifications for its stated purpose.

Card Type Approval process

The steps necessary for an ICC product to obtain an EMVCo letter of approval.

CC Common Criteria

CCD Common Core Definition

CCN Card Certificate Number

Chip Electronic component(s) designed to perform process and/or memory functions.

Composite Evaluation In the three-layer IC/Platform/ICC model, this term corresponds to the security evaluation of an upper layer (Platform or ICC) building on the underlying one(s), already approved (respectively IC or Platform).

CPA Common Payment Application

DFA Differential Fault Analysis



Term Definition

DPA Differential Power Analysis

EM Electro-Magnetic

EMA Electro-Magnetic Analysis

EMV Application A payment application based on EMV Specifications.

EMV CCD A subset of the EMV Specifications called Common Core Definition (CCD) made available by EMVCo.

EMVCo A Limited Liability Company established to maintain the EMV Specifications and administer type approval against those specifications.

EMVCo Compliance Certificate

A certificate issued by EMVCo when sufficient security assurance has been demonstrated for an IC, Platform, or ICC product.

EMVCo Evaluation Report A report submitted by a testing laboratory to EMVCo, indicating the results of the laboratory’s security evaluation.

EMVCo Restricted Compliance Certificate

A certificate issued by EMVCo when an IC, Platform, or ICC product is found to have a vulnerability that is being addressed by the product provider.

EMVCo Security Evaluation Secretariat

EMVCo designated members who administer the EMVCo Security Evaluation Process.

EMVCo Summary Report A report prepared by the EMVCo Security Evaluation Secretariat, based on its review of the EMVCo Evaluation Report and associated documents.

Environment Any software components and/or applications present on the ICC other than the EMV Application(s) being submitted to testing for Card Type Approval.

Evaluation Any activity that aims at verifying to verify the conformance of a selected product or process to a given requirement under a given set of conditions.

Evaluation report Document provided by a laboratory containing the test results for an IC, Platform, or ICC product, or report pursuant to an evaluation of an IC, Platform, or ICC product.



Term Definition

Extension Recognition Letter

A letter issued to a product provider by EMVCo in recognition of security reassessment work performed on the referenced expired IC or Platform product, in order to facilitate composite product renewal evaluations building on this product.

FIB Focused Ion Beam

GP GlobalPlatform

IC Integrated Circuit

IC Security Evaluation The steps necessary for an IC product to obtain an EMVCo Compliance Certificate.

ICC Integrated Circuit Card

ICC Security Evaluation The steps necessary for an ICC product to obtain an EMVCo Compliance Certificate.

ICCN Integrated Circuit Certificate Number

Integrated Circuit Card (ICC)

See Card.

Integrated Circuit Certificate Number (ICCN)

A unique four-digit reference number that identifies the EMVCo Compliance Certificate of an IC.

Integrated Circuit(s) (IC) See Chip.

JHAS JIL Hardware Attack Subgroup

JIL Joint Interpretation Library

Laboratory A facility that performs security evaluation testing.

Letter of approval Written statement that documents the decision of EMVCo that a specified ICC product has demonstrated sufficient conformance to the EMV Specifications on the date of it being tested.

Multi-application card An ICC that comprises more than one application, one of which being an EMV Application.



Term Definition

On-card representative Software on the card that acts as a representative of the card issuer; for example, a security domain, which holds specific keys and allows a secure communication channel to be established.

Operating System (OS) Set of software components allowing an EMV Application to be executed on a specific integrated circuit.

OS Operating System

Payment System For the purpose of this document, the Payment System is defined as American Express, JCB, MasterCard, Discover, UnionPay, or Visa.

PCN Platform Certificate Number

Platform A platform product is the collective name for the Integrated Circuit (IC) hardware with its dedicated software, Operating System (OS), Run Time Environment (RTE), and Platform environment on which one or more applications (e.g., CPA) can be executed.

Platform Certificate Number (PCN)

A unique four-digit reference number that identifies the EMVCo Compliance Certificate of Platform.

Platform Security Evaluation The steps necessary for a Platform product to obtain an EMVCo Compliance Certificate.

Product Provider The entity that submits an IC, Platform, or ICC product to EMVCo for Card Type Approval.

RCCN Restricted Card Certificate Number

Residual Vulnerability Report

A report prepared by the EMVCo Security Evaluation Secretariat to accompany the EMVCo Evaluation Report, when the Secretariat considers that the evaluation provides sufficient assurance although the product vulnerabilities have been identified.

Restricted Card Certificate Number (RCCN)

A unique four-digit reference number that identifies the EMVCo Restricted Compliance Certificate of an ICC.

Restricted IC Certificate Number (RICCN)

A unique four-digit reference number that identifies the EMVCo Restricted Compliance Certificate of an IC.



Term Definition

Restricted Platform Certificate Number (RPCN)

A unique four-digit reference number that identifies the EMVCo Restricted Compliance Certificate of a Platform.

Risk Analysis Report A report prepared by the product provider and the EMVCo Security Evaluation Secretariat regarding residual vulnerabilities that are significant enough to result in the issuance of an EMVCo Restricted Compliance Certificate.

RNG Random Number Generator

RTE Run Time Environment

Run Time Environment (RTE)

Functionality on a card which provides a secure environment for multiple applications to operate; e.g., Java Card.

Sample A representative of a specific IC, Platform, or ICC product provided to a laboratory for testing.

Security Impact Analysis (SIA)

Analysis of the impact of product changes on the product’s security level; created by the product provider and supplied to the EMVCo Security Evaluation Secretariat.

SER Shared Evaluation Report

SEWG Security Evaluation Working Group

Shared Evaluation Report (SER)

Evaluation report including restricted information on test activities and dates, intended to be shared between EMVCo recognized laboratories in the context of a composite evaluation.

SIA Security Impact Analysis

SPA Simple Power Analysis

Documents

EMVCo Security Evaluation Process V5€¦ · 3.5.1 Send EMVCo Update Registration Questionnaire ... For CCD/CPA ICC products, ... EMVCo Security Evaluation Process v5.1 Page 10