White Paper: Reducing Certification Cycles for Chip EMV Application

Transcription

1 2014 White Paper: Reducing Certification Cycles for Chip EMV Application Nitin Mittal

2 Introduction White Paper: Reducing Certification Cycles for Chip EMV Application In past and even today, lot of incidents are heard about card skimming and card cloning with magnetic stripe technology. To combat this situation, EMV came into picture which has substantially reduced such type of frauds. EMV is a global standard for interoperable operations of ICC, ATMs and POS worldwide which is being evolved against latest vulnerabilities. Worldwide EMV Deployment and Adoption Adoption Rate 81.60% 24.40% 54.20% 38.90% 17.40% Canada, Latin America, and the Carribbean Asia Pacific Africa & the Middle East Europe Zone 1 Europe Zone 2 As on 6 th May, 2014 (EMVCo), there are 2.37 billion EMV payment cards in circulation and 36.9 million EMV terminals active worldwide. This figure is witnessing the level of acceptance of EMV technology worldwide. Below chart shows the adoption rate of EMV payment cards regionally. Figure 1: Figures reported in Q and represent the latest statistics from American Express, Discover, JCB, MasterCard, UnionPay, and Visa, as reported by their member institutions globally. (Source: EMVCo) With increasing demand for EMV technology, many players are coming up with their card products in market. These products must go through Card Type Approval process which is established by EMVCo. Separate Card Type Approval process has been defined for CCD (Common Core Definitions) and CPA (Common Payment Application) specifications. EMVCo defines two levels of certification for type approval i.e. Level 1 and Level 2. The Level 1 Type Approval process tests compliance with the electromechanical characteristics, logical interface, and transmission protocol requirements defined in the EMV Specifications. Level 2 Type Approval tests compliance with the debit/credit application requirements as defined in the EMV Specifications. EMV chip payment applications are neither easy to develop nor getting certified from accredited laboratory. Certification of EMV chip payment application is a prolonged process which may take more than two or three iterations which is sometimes more than a year or two in terms of duration. This situation arises due to lack of maturity in developing chip payment application and qualifying them inhouse. This document highlights the areas for Level 2 where in-house testing must put its maximum emphasis in order to identify potential defects in chip payment application, in turn, which will expedite the certification process at accredited lab as maximum number of issues would have been dealt with already. This document may also serve a kind of Defect Taxonomy for chip payment application. 2

3 EMV Transaction Flow Image shown below illustrates the EMV transaction flow in a simpler way. Based on these transaction steps, this document will address the type of defects that may be a potential issue in the respective step. Application Selection May be more than one application. Terminal and chip agree on common supported applications. Cardholder may choose if more than one common application. Initiate Application Processing and Read Application Data Selected application is initiated and terminal read the necessary data from the chip. Offline Data Authentication Offline data authentication via SDA, DDA or CDA. Processing Restriction Checks are performed to confirm the chip is allowed to do the Transaction. Cardholder Verification Signature, online PIN, Offline enciphered PIN, Offline plaintext PIN or no CVM. Terminal Risk Management Terminal performs checks such as Floor Limit to determine if online processing is required. Terminal Action Analysis Based on offline data auth, processing restriction, CVR, TRM and rules in terminal and chip, the terminal application requests a result of decline offline, approve offline or go online. Card Action Analysis Based on issuer defined rules and limits, the card will respond With ARQC, AAC or TC. Completion and Script Processing Online Processing If the chip requests to go online, then the terminal builds an online request to the issuer host for authorization and online card Authentication. If ARPC is received, the terminal will send the data to card to chip for Transaction completes. If online processing occurred the chip will be requested to confirm with a TC or AAC and will apply any script commands. 3

4 Potential Area to Detect Defects After understanding the EMV transaction and its processing steps, now let s see the areas where potential defects could be identified. Although defects could be present in any processing step, yet this white paper is intended to focus on the most erroneous part of transaction processing. Application Selection SELECT Selection of ADF with partial name Selection of next occurrence of ADF with partial name, if another ADF exists with same partial name Selection of next occurrence of ADF with partial name, if no other ADF exists with same partial name Selection of next occurrence of an ADF with complete AID Selection of next occurrence of ADF with partial name before the selection of first occurrence Selection of a non-existent application Selection of ADF with Alias AID Initiate Application Processing GET PROCESSING OPTIONS Increment ATC for each transaction initiated No ATC increment, if error occurs during initiate application processing Initiate Application Processing must be stopped, if ATC reached its maximum limit. (Issuer option) Incorrect PDOL provided in data field Missing tag 83 in data field Inconsistent length of PDOL related data in data field Profile Selection processing (if supported) Profile Selection Table consistency AFL consistency 4

5 Offline Data Authentication SDA, DDA and CDA INTERNAL AUTHENTICATE Terminal must perform Offline Data Authentication, if supported by terminal and ICC both Manipulation in data required for Offline Data Authentication Data required for Offline Data Authentication not TLV encoded Data required for Offline Data Authentication, if in range SFI 1 to 10, must not include tag 70 and length of data for processing Data required for Offline Data Authentication, if in range SFI 11 to 30, must be include tag 70 and length of data for processing If Static Data Authentication Tag list exists, it must contain only the tag of Application Interchange Profile Tag and length of Application Interchange Profile must not be included in data required for Offline Data Authentication ICC does not contain DDOL or ICC contains DDOL but does not include Unpredictable Number Different RSA keys are used at ICC and terminal Response must be in format 2 and length of response equals ICC RSA key modulus length ICC must return error SW if Unpredictable Number is personalized in DDOL or no DDOL related data present in APDU Two successive Internal Authenticate command are not possible ICC returns error SW if no prior GPO command or failed GPO command ICC returns error SW if DDOL is not personalized ICC returns error SW if RSA key not personalized Cardholder Verification VERIFY ICC must verify the PIN (plaintext / enciphered) Counter must decrease for each unsuccessful PIN verification attempt PIN counter must be reset to its limit after successful PIN verification attempt When PIN counter reaches to 0, ICC must send back error SW (PIN blocked) PIN data not in EMV format PIN not personalized but used Scope of PIN verification is limited to current transaction 5

6 Card Action Analysis GENERATE APPLICATION CRYPTOGRAM ICC must check the content of Card Risk Management Data Object List (CDOL1) ICC response for each type of requested cryptogram i.e. TC, ARQC and AAC Cryptogram Information Data (CID) must be checked if correct bits are set according to transaction status Card Verification Results (CVR) must be checked if correct bits are set according to transaction status ICC must return AAC for blocked application Check the behavior of ICC based on Card Issuer Action Code (CIAC) for denial, online and default Check the behavior of ICC in current transaction if some flags were set during previous transaction Check the behavior of ICC based on velocity checking Updating counter in accordance with Card Status Unit (CSU) or Issuer Authentication Check the behavior of ICC for different cases of Issuer Authentication (Performed, Failed, Passed, Not Performed) Check the behavior of ICC is Issuer Script failed in previous transaction Check the behavior of ICC if it is a new card Check the behavior of ICC for online capable or no online capable terminal Check the behavior of ICC in case terminal sends erroneous status of Cardholder Verification Results Check the behavior of ICC in case terminal sends erroneous status of Offline Data Authentication Verify CDA signature returned in response Cryptogram must be validated Check the behavior of ICC in case Authorization Response Code is Y3 or Z3 (terminal is unable to go online) Check if transaction log file is being updated for transaction 6

7 Script Processing APPLICATION BLOCK Check if ICC application is blocked after a successful Application Block command Selection of blocked ICC application must return warning SW Transaction must be declined for block ICC application must be allowed only in application script state APPLICATION UNBLOCK Check if ICC application is unblocked after a successful Application Unblock command must be allowed only in application script state PIN CHANGE/UNBLOCK Check if ICC application PIN is unblocked after a successful PIN Change/Unblock command with P2 = 00 Check if ICC application PIN is changed after a successful PIN Change/Unblock command with P2 = 01 using current PIN Check if ICC application PIN is changed after a successful PIN Change/Unblock command with P2 = 02 without using current PIN ICC must return error if tag 87 is not present for enciphered data block (PIN change case) ICC must return error if padding indicator 01 is not present for enciphered data block (PIN change case) ICC must return error is PIN block is not in EMV format must be allowed only in application script state 7

8 PUT DATA Check if ICC application is able to update allowed tag Check if ICC application is able to decline to update the non allowed tag ICC must return error if first byte of secured command data field is not equal to 81 ICC must return error if supplied data length if greater than the reserved data length of the tag must be allowed only in application script state UPDATE RECORD Check if ICC application is able to update the record Check if ICC is able to decline updating a record if length of new value is greater than the reserved length of record ICC must return error if first byte of secured command data field is not equal to 81 must be allowed only in application script state 8

9 Conclusion White Paper: Reducing Certification Cycles for Chip EMV Application As depicted in Figure 1, it is clearly shown the scope of EMV deployment across the globe. On continuous approach to improve functioning and security of EMV chip application, EMVCo and other associated parties are evolving and publishing their chip application specification. This increases the demand of new applications, with additional features, that need to be certified by a laboratory which charges handsome amount of money for certification. Hence, this makes in-house testing essential in order to reduce the cost attached to certification. This can be achieved only if application under certification has been tested robustly during in-house testing. Moving to more standardized and established in-house testing will require right direction, right inputs and right solutions. This white paper will contribute its little yet significant role towards establishing a robust chip application test framework and test suite. In today s dynamic and challenging and regulatory environment, organization must ensure the least certification cycles should be practiced in order to minimum turnaround time for product launch and reducing cost attached to this. 9