VeriFone VeriShield Total Protect Technical Assessment White Paper

VeriFone VeriShield Total Protect Technical Assessment White Paper Prepared for: September 4 th, 2013 Dan Fritsche, CISSP, QSA (P2PE), PA-QSA (P2PE) dfritsche@coalfiresystems.com

Table of Contents EXECUTIVE SUMMARY... 3 OVERVIEW... 3 SUMMARY FINDINGS... 6 PCI DSS VALIDATION REDUCTION... 8 SCOPE REDUCTION FOR MERCHANTS... 12 DEPLOYMENT SCENARIOS... 12 SUMMARY PCI DSS SCOPE REDUCTION... 16 DETAILED PCI DSS SCOPE REDUCTION... 17 TECHNICAL ASSESSMENT... 18 SCOPE OF ASSESSMENT... 18 VERISHIELD TOTAL PROTECT ENCRYPTION ASSESSMENT... 21 VALIDATION OF DECRYPTION AT VERISHIELD DECRYPTION ( VSD )... 22 KEY LOADING AND DISTRIBUTION... 26 APPENDIX A: PCI DSS SCOPE REDUCTION RISK MAPPINGS... 34 DETAILED PCI DSS SCOPE REDUCTION... 34 2013 Coalfire Systems, Inc. Page 2

Executive Summary Overview VeriFone engaged Coalfire Systems Inc. (Coalfire), as a respected Payment Card Industry (PCI) Qualified Security Assessor Point to Point Encryption (QSA P2PE) company, to conduct an independent technical assessment of the VeriShield Total Protect (VTP), secured by RSA security solution. Coalfire conducted assessment activities including technical testing, an architectural assessment, industry analysis, a compliance validation and peer review. In this paper, Coalfire will describe how the VeriShield Total Protect security solution can nearly eliminate the current risk of payment card data compromise within a merchant s retail environment and can dramatically reduce the scope of PCI DSS validation when properly deployed. This scope reduction will be based on evaluating the risk of each of the PCI DSS 2.0 requirements and how the VTP security solution applies to each control within the context of the current PCI P2PE standards released in 2012. VTP is a component of a P2PE solution program and as such, not eligible to obtain a PCI P2PE validated solution listing on its own. VTP can be used by service providers to provide a P2PE validated solution to their merchants; however, there are P2PE requirements that are not addressed. These include requirements such as the implementation of physical security controls in accordance with the PIM (P2PE Instruction Manual) that will be the responsibility of the service provider. NOTE: VeriShield Total Protect (VTP) is the latest version and name for VeriShield Protect (VSP) and includes all VSP functionality plus additional encryption methods and tokenization. VSP will be referenced in many places for clarification purposes, but the focus of this assessment is on the most recent features VTP offers. About VeriShield Total Protect VeriShield Total Protect is a comprehensive, modular and flexible solution designed to provide merchants with strong encryption of payment card data from the point of capture to the point of decryption at their gateway, payment processor, or acquirer. VTP includes everything from VeriShield Protect (VSP) and now includes Format Preserving Encryption (FPE) using a symmetric derived key management system along with RSA encryption and tokenization to merchants. The VTP security solution includes these VSP components: 1. Capture Point Encryption The VeriShield Crypto Library (VCL) component is deployed within the VeriFone Tamper Resistant Security Module (TRSM). The TRSM is considered part of the payment device s operating system from a security perspective. Regardless of the payment origin: magnetic stripe, manual entry, tapped via NFC phone or contactless card, or EMV chip, this component encrypts payment card data at the point of capture. 2. Service provider Interface Decryption The VeriShield Decryption Service (VSD) is the end point of the encrypted transaction that resides at the merchant processor, PCI DSS compliant service provider, or at the merchant s switch (depending on merchant requirements). No sensitive cardholder data is stored during the decryption process. 2013 Coalfire Systems, Inc. Page 3

3. VTP Front End and Web Service The single point of integration for all service requests made by external integration hosts. 4. VeriFone Merchant Boarding (VMB) This web-based user interface provides the ability to board merchant/store locations as well as delete merchant/store/device locations. In addition, this tool provides features to do key creation and import services through an interface with the HSM, and device configuration creation services. No sensitive cardholder data is stored in VTP, so none is available in the VMB user interface. A user is also not able to view key data that is stored in a HSM through this interface. 5. Device Monitoring The VeriShield Monitoring and Compliance console (VMC) is a centralized monitoring and reporting platform that provides web-based visibility into transaction health and encryption for each POI device, and as such, is implemented as a centralized management server. No sensitive cardholder data is stored in VTP, so none is available in the VMC user interface. 6. Key Management Platform The VeriShield Key Management (VKM) component is an optional integrated component that provides the full key management lifecycle for the solution including synchronization, remote management of BIN tables and device settings such as eparms. VeriShield Total Protect provides an additional software component to assist in HSM operations: 1. HSM Utility -- Enables key custodians to manage HSM resident keys and retrieve key components. This enables the merchant to utilize the derived key functionality. The VeriShield Total Protect security solution is focused on reducing the risk of a merchant data breach while supporting processing requirements and minimizing the operational impact to existing systems and environments. Our assessment reviewed both current and planned deployment scenarios. This assessment included the above components in PCI compliant testing labs and focused on the new VTP components and the symmetric derived key management system. Audience This assessment report has four target audiences: 1. Merchants: This audience is evaluating the VeriFone VeriShield Total Protect security solution for deployment in their payment card environment. Merchants will be able to clearly understand what benefits they can receive from using VTP in their environment, including risk and scope reduction. 2. Acquirers and Service Providers: This audience is evaluating the VeriFone VeriShield Total Protect security solution for deployment in their service provider environment. Acquirers and service providers can use this assessment to evaluate how VTP can enable them to offer a P2PE solution leading to specific scope reduction for merchants, and even to help them to achieve a PCI P2PE validated listing. 3. QSA s and the Internal Audit Community: This audience may be evaluating the VeriFone VeriShield Total Protect security solution to determine the impact of P2PE on PCI DSS compliance in general on behalf of their merchant. 2013 Coalfire Systems, Inc. Page 4

4. VeriFone and Partners: The final target audience is the product and engineering teams of VeriFone and its technology partners. The purpose of including this audience is to provide an independent evaluation of their solution and help them identify any areas for improvement. Assessment Scope The scope of our assessment focused on the critical elements that validate the security and effectiveness of the security solution. Coalfire incorporated in-depth analysis of compliance fundamentals that are essential for evaluation by merchants, service providers and the QSA community. In addition, Coalfire utilized reviews and feedback obtained from members of the PCI community; however, the opinions and findings within this evaluation are solely those of Coalfire and do not represent any assessment findings, or opinions, from any other parties. This assessment is not a replication of the previous 2010 VSP assessment and whitepaper, but rather an update focusing on how the VTP security solution can be understood and leveraged in the context of PCI DSS v2.0 and the current PCI P2PE standards released in 2012. This assessment will specifically focus on the new Derived Symmetric Key Mode functionality. Methodology Coalfire has implemented industry best practices in our assessment and testing methodologies. Standard validation methods were used throughout the assessment. Coalfire conducted technical lab testing in both the Coalfire Labs located in Louisville, Colorado and the VeriFone labs in San Diego, CA. This included complete POS installation, integration, transaction testing, device assessment, encryption evaluation and forensic analysis. A previous validation assessment was performed in 2010 for some VTP components; that work was not reproduced, but instead it was leveraged and should be referred to for an understanding of Classic Key Mode functionality. Merchant PCI DSS Compliance Scope Even the best encryption technologies do not completely eliminate the scope of PCI DSS compliance validation, as some in the industry have claimed. In fact, if a merchant is accepting a payment card, the entirety of the PCI DSS always applies to them. However, a properly implemented, and thoroughly evaluated, encryption solution can satisfy a significant portion of the PCI DSS controls; thereby significantly reducing the scope of what PCI DSS requirements a merchant is still responsible for validating. In 2012, the PCI SSC released an official P2PE standard detailing what controls must be in place for a service provider to become listed using a given data security solution. This program works best for level 4 merchants. For encryption solutions not listed with the PCI SSC (which would include most level one merchant solutions), the Council has stated that the acquirer or payment brand should be consulted to determine how an encryption solution can be used. This assessment can be used by a service provider using the VTP security solution to pursue a PCI P2PE validated listing or to interact directly with an acquirer or payment brand to understand what reduction of applicable controls is acceptable. 2013 Coalfire Systems, Inc. Page 5

To that end, a risk evaluation for each control is included to justify a corresponding reduction of applicability, based on the PCI P2PE standards. Coalfire has reviewed each deployment scenario to assess its impact on the cardholder data environment that would be considered in scope for PCI DSS validation. We have leveraged our experience as a veteran QSA(P2PE)/PA-QSA(P2PE) firm in applying technologies such as network segmentation, tokenization, and various encryption solutions to provide guidance on appropriate PCI DSS reduction of applicable controls. Technical Security Assessment The flexible and modular solution design of VeriShield Total Protect presented Coalfire with at least three core deployment architectures and a number of merchant integration and configuration options. Our assessment covered core deployment architecture and all available configuration options. The assessment included testing a comprehensive set of administrative, technical and physical controls. This included the definition of control roles and responsibilities between the merchant and connected entities. Applicable compliance control requirement adherence from the PCI DSS, PCI PA-DSS, PCI P2PE and PCI PTS were validated within the scope of our security assessment. Where control gaps or vulnerabilities were identified, remediation guidance was communicated to responsible parties and follow-up testing was performed to validate gap closure. Coalfire evaluated and tested the complete VeriShield Total Protect security solution within the context of the applicable controls in the 6 domains as described in Solution Requirements and Testing s: Encryption, Decryption, and Key Management within Secure Cryptographic Devices Version 1.1 published by the PCI SSC in April 2012, as well as other related documents including updates to the standard. The evaluation included verification of encryption methods, key length, algorithms, key management methods, and physical and logical protection. Security and Risk Profile The greatest value of P2PE solutions for merchants is the reduction in risk of payment card data compromise. Using our extensive experience with threat analysis, computer forensics, data breach investigations and security incident response we validated the critical aspects of risk mitigation that the VeriShield Total Protect security solution can provide for merchants. Summary Findings The following are important highlights of Coalfire s technical evaluation: A properly deployed VeriShield Total Protect security solution can provide significant risk reduction of data compromise and is one of the most effective data security controls available to merchants today. VeriShield Crypto Library meets encryption best practices and standards for cryptographic algorithms and key strength. VCL format-preserving methods meet industry standards and VISA best practices guidance. The format-preserving VeriShield Crypto Library provides successful integration with existing payment applications, POS systems and back-office servers. 2013 Coalfire Systems, Inc. Page 6

A payment application or POS system not running on the POI, and that is not PA-DSS validated can be taken out of PA-DSS scope if all payment data is captured through the VeriShield Total Protect security solution and the system is cleansed of all legacy card data. A merchant should have ownership rights to the decryption keys, but not have access to, or possession of these keys to achieve the greatest PCI DSS reduction of applicable controls. A merchant can dramatically reduce the PCI DSS controls they are responsible for validating in their retail and corporate environments if all electronic card data is captured in a VeriShield Total Protect TRSM and the merchant is not capable of decrypting captured data and decryption keys do not exist within their environment. VMC provides effective compliance and security auditing for the merchants and their QSAs. Compliance reporting over time is easily evidenced for assessors through VMC. The VeriShield Total Protect security solution integrates securely with PC-based POS systems or cash registers without exposing card data, encryption keys or authentication data to these platforms. The derived key management processes of the VeriShield Total Protect security solution remove most of the challenges of key management for the merchant that are present in many other P2PE technologies. Specific benefits of this method include unique keys per device per card, automated key management functions, increased key strength, and streamlined integration to HSM devices. A VeriFone PTS validated terminal should be the only point in a merchant retail environment that captures card data through any supported input method: swipe, manual, EMV or contactless. To achieve the greatest PCI DSS scope reduction, Coalfire and VeriFone recommend the use of a PTS 2.x with SRED or 3.x with SRED device. VCL will run on any of these devices. The tested version of VeriShield Total Protect security solution encrypts more types of cards than previous versions, thus increasing the encryption rate while still providing BIN exclusion ranges and maintaining integration value with existing POS systems. Assessor Comments Our assessment scope put a significant focus on validating the PCI DSS compliance control reduction impact of the VeriShield Total Protect security solution. The VeriShield Total Protect security solution can nearly eliminate risk of payment card data compromise for a merchant s retail environment. There can be very clear and dramatic reduction of the PCI DSS scope of validation with a properly deployed solution. However, ignoring the PCI DSS and security best practices, even if they are out of scope for PCI DSS compliance validation, can introduce many other security or business continuity risks to the merchant. Security and business risk mitigation should be any merchant s goal and focus for selecting security controls. The VeriShield Total Protect security solution can benefit merchants by helping reduce the cost of PCI DSS compliance validation and allow them to invest more of those resources into business risk mitigating controls. With the current PCI P2PE standard, merchants have an increased expectation for vendors and service providers to offer a more secure environment utilizing the latest encryption technologies. The VeriShield 2013 Coalfire Systems, Inc. Page 7

Total Protect security solution leverages a longstanding experience and commitment to provide cutting edge encryption technology to merchants and service providers. The VeriShield Total Protect security solution can be used by service providers and acquirers seeking to provide merchants with a secure encryption solution that will reduce their risk and the applicability of several PCI DSS controls. PCI DSS Validation Reduction The Payment Card Industry has developed the PCI Data Security Standard (DSS) to mitigate the risk of compromise to a specific data set. The standard is focused only to the system components that are within scope of PCI. For all system components, all PCI DSS controls apply. The PCI DSS is based on industry security best practices but is not focused on the overall information security of merchants. To reduce PCI DSS compliance scope you must reduce the potential security risk and access to payment card data. The PCI Security Standards Council has incorporated scope reduction guidance within the PCI DSS framework and through FAQ guidance on specific technologies or architecture. Scope reduction has most commonly been addressed through the implementation of network segmentation where systems and environments that process, store or transmit card data are isolated from other non-payment environments. This approach is not focused on reducing the applicability of any specific DSS control to a merchant s environment but rather reducing the validation expectations of the environment that the DSS controls apply to. As most of the DSS controls are designed to manage risk to card data from specific threat scenarios, it is therefore possible to reduce their applicability by securing the card data in the merchant environment, so that the threat scenarios are no longer a viable risk. By strongly encrypting card data at the point of capture in a secure and restricted device, where no ability to decrypt the card data exists, you can effectively isolate the majority of the merchant s environment from scope. If specific deployment scenarios are adhered to, the merchant environment can be treated as an untrusted environment similar to a public network when using strong transmission encryption. In 2012 the PCI Security Standards Council released 2 P2PE documents. The first was for a hardware/hardware solution, the second for a hardware/hybrid solution. For the purposes of this paper, the former will be the focus of all interpretations and comments. This standard can be found at PCI s document library, under the P2PE section, along with supporting documentation. https://www.pcisecuritystandards.org/security_standards/documents.php These documents, along with the PCI DSS 2.0 are the reference points used for all comments and conclusions in this assessment. Additionally, PCI has updated some relevant FAQ s: FAQ of the Month - UPDATED Is encrypted cardholder data in scope for PCI DSS? 2013 Coalfire Systems, Inc. Page 8

August, 2012: This FAQ has been updated to reflect the evolving security landscape surrounding the use of encrypted payment card data, and to eliminate inconsistencies in how the scope of PCI DSS is determined with respect to the presence of encrypted data. With the release of the PCI Point-to-Point Encryption (P2PE) Program, the Council is providing additional guidance on the security of encrypted cardholder data through this updated FAQ, as well as two additional FAQs: "Are third-party storage providers storing only encrypted cardholder data in scope for PCI DSS?" and "Are merchants using Council-listed P2PE solutions out of scope for PCI DSS?" These FAQs are intended to clarify that storage of encrypted data without access to the decryption keys does not automatically result in the data, or the merchant, being out of scope. Encryption of cardholder data with strong cryptography is an acceptable method of rendering the data unreadable in order to meet PCI DSS Requirement 3.4. Because encrypted data can be decrypted with the right cryptographic key, encrypted cardholder data remains in scope for PCI DSS. Generally, the encrypted data is the responsibility of the entity (that is, the corporation, organization or business being reviewed) that controls and/or has access to the encrypted data and the decryption keys. It is possible that encrypted data may be deemed out of scope for a particular entity if, and only if, it is validated that the entity in possession of the encrypted data does not have the ability to decrypt it. This means the entity does not have decryption keys anywhere in their environment, and that none of the entity's systems, processes or personnel have access to the environment where decryption keys are located, nor do they have the ability to retrieve them. Furthermore, all applicable PCI DSS requirements apply if any of the following conditions are met: Encrypted cardholder data is stored on a system or media that also contains the decryption key, Encrypted data is stored in the same environment as the decryption key, Encrypted data is accessible to an entity that also has access to the decryption key. For information about how a merchant may receive scope reduction through use of a validated P2PE solution, please see the FAQ: "Are merchants using Council-listed P2PE solutions out of scope for PCI DSS?" This FAQ reference states: Are merchants using Council-listed P2PE solutions out of scope for PCI DSS? A. No. While use of a validated, listed P2PE solution can help to reduce the scope of a merchant s cardholder data environment, it does not remove the need for PCI DSS in the merchant environment. The merchant environment remains in scope for PCI DSS because cardholder data is always present within the merchant environment. For example, in a cardpresent environment, merchants have physical access to the payment cards in order to complete a transaction, and may also have paper reports or receipts with cardholder data. As another example, in card-not-present environments (such as mail-order or telephone-order), payment 2013 Coalfire Systems, Inc. Page 9

card details are provided via other channels that need to be evaluated and protected according to PCI DSS. Only Council-listed P2PE solutions are recognized as meeting the requirements necessary for merchants to reduce the scope of their cardholder data environment through use of a P2PE solution. Merchants using encryption solutions that are not included on the Council s List of Validated P2PE Solutions should consult with their acquirer or payment brand about use of these solutions. Another important FAQ: Can merchants use P2PE solutions not listed on the Council s website for PCI DSS scope reduction? A. Only Council-listed solutions are recognized as meeting the requirements necessary for merchants to reduce the scope of their cardholder data environment (CDE) through use of a P2PE solution. In addition to using a validated, Council-listed P2PE solution, merchants wishing to reduce the scope of their CDE must meet certain characteristics, as documented in the Merchants Using P2PE Solutions section of the P2PE Standard. SAQ-eligible merchants can review the P2PE-HW SAQ on our website for eligibility criteria and applicable PCI DSS requirements. Merchants using encryption solutions that are not included on PCI SSC s list of Validated P2PE Solutions should consult with their acquirer or the payment brands about the use of these solutions. Based on this guidance, one of the intentions for this assessment is to provide guidance for Merchants wishing to use the VeriFone VeriShield Total Protect Solution to be able to easily demonstrate to their acquirer or payment brands how the solution addresses various PCI DSS controls. In addition to this formal guidance from the Council, Coalfire has also utilized the following to formulate our guidance on PCI DSS reduction of applicable controls for P2PE: Dialogue with Council members regarding P2PE to understand their current position and future intent Reference and review of the FAQ released by the Council Dialogue with respected QSA s from other QSA companies in the industry Coalfire s experience in implementing other PCI DSS scope reduction programs Clarification of Compliance Clearly, PCI DSS scope reduction cannot remove a merchant from the requirement to be compliant. PCI DSS scope reduction does not eliminate a merchant s responsibility to validate compliance to their Acquirer as PCI DSS always applies to merchants who accept card data. Traditional PCI DSS scope reduction is only focused on addressing the applicability of specific controls to a merchant s environment based on isolation of data, systems and networks from security risks to payment card data. PCI DSS scope reduction s biggest payoff for merchants is the opportunity to eliminate the cost of control deployment for the sole purpose of meeting compliance obligations. The second major benefit is the reduction of cost and effort to validate PCI DSS compliance of the merchant environment. Many merchants have sensitive data assets other than payment card data in their environment that have a risk 2013 Coalfire Systems, Inc. Page 10

of compromise. Reducing PCI DSS scope for payment card data does not mean the PCI DSS controls are not justified to protect the merchants other information assets. 2013 Coalfire Systems, Inc. Page 11

for Merchants Each merchant s environment is different. Differences in card data capture processes or deployment decisions could easily impact a merchant s ability to achieve maximum reduction of applicable controls. Coalfire has presented the most common deployment scenario for a merchant implementing VeriShield Total Protect to reduce PCI DSS scope. Additionally, we have identified important deployment constraints that are critical to adhere to for maximum reduction of controls. A number of deployment scenarios offered with the VeriShield Total Protect solution were assessed by Coalfire. All scenarios have a positive impact that reduces the number of PCI DSS controls for the merchant; however, there are significant differences if a merchant chooses a deployment scenario where they host decryption services or key management within their environment. Coalfire can support any merchant or QSA inquiry regarding the impact to PCI DSS controls from other deployment scenarios. Deployment Scenarios The VeriShield Total Protect solution is designed with flexible component architecture and distributed communication methods that can facilitate a number of deployment scenarios. Deployment scenarios can include deployments where both end points of the encryption/decryption process are under merchant control or outsourcing of the decryption endpoint to a service provider. The merchant may have a number of service provider options available to them that range from VeriFone, Network Aggregators (TNS) or Processor/Acquirers. Coalfire has defined two general deployment scenarios for the purpose of PCI scope assessment in this white paper. Regardless of the deployment scenario a number of deployment assumptions are required to achieve the full PCI DSS reduction of applicable controls for retail environments identified later in this white paper. The following assumptions are: Transaction locations only capture payment card data within the VeriShield Total Protect payment device. Payment applications and registers disable or procedurally restrict card swipe or card entry outside of the VeriShield Total Protect payment device. Only format preserving data is provided back to any payment application, register or downstream system No decryption capabilities of card data encrypted with VeriShield Total Protect are accessible to the merchant. The merchant does not possess or have access to decryption keys in their retail or corporate environments. All decryption services are contracted with a compliant service provider that has been assessed by a QSA to deliver the VeriShield Total Protect Decryption Services. Chargeback and other customer support and payment research processes do not include or require access to the full primary account number. 2013 Coalfire Systems, Inc. Page 12

Public facing web applications for e-commerce or other payment transactional systems not using the VeriShield Total Protect solution must be addressed with your QSA to determine PCI DSS requirements. There are two versions of the derived key management system available unique key per device and shared key. 1. Unique Key per Device this derived key method creates a separate device derivation key (DDK) unique to each payment device so that card data is encrypted differently on every device the device derivation keys are derived from a unique master derivation key (MDK). 2. Shared Key this derived key method shares the device derivation key (DDK) across a set of payment devices so that card data is encrypted the same on each device in the set the device derivation key is derived from a unique master derivation key(mdk). This paper is focused solely on the use of the unique key per device derived key management system. Scenario #1 - VeriFone Hosted Decryption Service Deployment In this first scenario, a merchant deploys the VeriShield Total Protect payment device as the only capture end point in their retail environment and subscribes with VeriFone directly for decryption services. Figure 1: VeriFone Decryption Diagram This scenario is based on a merchant s selection of a VeriShield Total Protect payment device that is deployed in the retail environment that replaces any other platforms for card data capture. When card data is swiped or keyed into the VeriShield Total Protect solution, the VCL component encrypts the card data and sends it to a processing end-point where the decryption services reside. VeriFone manages the decryption service in a PCI DSS compliant environment. Scenario #2 3 rd Party Service Provider Decryption Service Deployment The second scenario is basically the same from a merchant s perspective, except for using a third party other than VeriFone for decryption. As with the previous scenario, a merchant deploys the VeriShield Total Protect terminal as the only capture end point in their retail environment and then subscribes with 2013 Coalfire Systems, Inc. Page 13

a processor/acquirer/service provider for decryption services. Coalfire has labeled this as the Outsourced Decryption deployment scenario. Figure 2: Outsourced Decryption Diagram The outsourced decryption scenario is based on a merchant s selection of a VeriShield Total Protect payment device that is deployed in the retail environment that replaces any other platforms for card data capture. When card data is swiped or keyed into the VeriShield Total Protect solution, the VCL component encrypts the card data and sends it to a processing end-point where the decryption services reside. The decryption service could be hosted by a gateway service provider or processor/acquirer. This end-point service provider would deploy and manage the decryption service in a PCI DSS compliant environment. Merchant PA-DSS Requirement Reduction Merchants who have payment applications that are currently not validated to the PCI Payment Application Data Security Standard (PA-DSS) are now required to only use applications which are validated to the PA-DSS 1.2 or higher standard. Not doing so introduces a significant risk, especially if a breach were to occur. While there are now a large number of options for validated Payment Applications, un-validated versions are still in use and affordable quality solutions are often limited in some industries. If a merchant follows either deployment scenario presented above, where they integrate the VeriShield Total Protect terminal with their payment application and no longer capture card data in the payment application, they can remove the requirement to use a PA-DSS validated application. Merchants must effectively purge any legacy card data from the existing applications and restrict any card capture whether through card swipe or key entry. The application would only prompt the VeriShield Total Protect solution for tender and pass transaction information. The payment application would never receive payment card data in return. The application then would no longer store, process or transmit cardholder data, which would effectively remove the application from PA-DSS eligibility based on PCI s Applications Eligible for PA-DSS Validation: 2013 Coalfire Systems, Inc. Page 14

https://www.pcisecuritystandards.org/documents/which_applications_eligible_for_padss_validation.pdf This document states: For the purposes of PA-DSS, a payment application eligible for review and listing by the PCI SSC is defined as an application that: a) stores, processes, or transmits cardholder data as part of authorization or settlement; and b) is sold, distributed, or licensed to third parties 2013 Coalfire Systems, Inc. Page 15

Summary PCI DSS The following summary chart provides a quick view of the impact to PCI DSS control requirements for a merchant s retail environment assuming the VTP solution has been properly implemented. Merchant environments or payment processes can differ and it is important to work with your QSA and acquirer to validate appropriate PCI DSS control reduction before making any assumptions on scope reduction. If a merchant has deployed the VTP solution in their environment it is assumed that it is the only payment channel within the merchant s retail and corporate environments. Paper based processes discussed within the justifications below would be in support of the VTP payment channel only. All recommended risk reductions are based on the assumption that a QSA has fully validated that the VTP solution has been properly implemented in the merchant s environment. Summary Chart of Merchant PCI DSS PCI DSS Area Major Impact Moderate Impact Minor/No Impact Section 1 Section 2 Section 3 Section 4 Section 5 Section 6 Section 7 Section 8 X X X X X X X X Section 9 X Section 10 Section 11 X X Legend: Section 12 X Major A significant number of controls are either removed from scope or a reduction in the number of IT assets requiring the controls Moderate A reduced number of controls are required and a significant reduction in the number of IT assets requiring the controls 2013 Coalfire Systems, Inc. Page 16

Minor Either no controls are removed from scope or minor impact to the scope of IT assets requiring the controls Detailed PCI DSS A table in Appendix A was created as a general guideline for determining the PCI-DSS scope within a merchant environment utilizing the VTP solution. This risk-based guidance indicates Coalfire s recommended PCI-DSS scope reduction for Merchants that have compliantly implemented the VTP solution. Scroll down to Appendix A to review the detailed PCI DSS risk guidance. 2013 Coalfire Systems, Inc. Page 17

Technical Assessment Scope of Assessment VeriFone VeriShield Total Protect was assessed for compliance relative to current PCI DSS 2.0 standards and PCI P2PE 1.1. The assessment testing focused on the following functional areas: 1. Verification of Point-to-Point Encryption from the point of encryption to the point of decryption a. Point-of-Encryption included VeriFone MX 915, MX 925 and VX820 Terminal Card Entry Devices with Tamper Resistant Security Module ( TRSM ) b. Point-of-Decryption was a VeriShield Decryption Service ( VSD ) Test System hosted by VeriFone. 2. Use of robust key management a. Direct Testing of key management via command cards b. Review of remote key management via VKM web interface c. Direct testing of key management via VCL API integration 3. Key-length and Cryptographic Standards 4. Alternate account or transaction identifier for recurring payments a. Note: recurring payment processing is not part of the VeriShield Total Protect system due to increased vulnerability of storing data b. VeriShield Total Protect is a transaction pipeline system c. Non-storage of any transaction data was verified by disk forensics 5. PCI DSS reduction of applicable controls Note: Coalfire s assessment concentrated on functional aspects of VeriFone VeriShield Total Protect, where tamper resistance is addressed by the PTS certification of the VeriFone terminal itself. Glossary Acronym FPE HSM KIF PAYware Connect TRSM SRED VCL VKM VMB VMC VSD VTP Description Format Preserving Encryption Hardware Security Module Key Injection Facility VeriFone Payment Gateway, with integrated VSD Tamper Resistant Security Module Secure Reading and Exchange of Data VeriShield Crypto Library VeriShield Key Management VeriShield Merchant Boarding VeriShield Monitoring & Compliance VeriShield Decryption Service VeriShield Total Protect Copyright 2013, Coalfire Systems Inc. Page 18

Figure 1: Test Lab Configuration Diagram The diagram below illustrates configuration used to test VeriShield Total Protect system. All encryption takes place at the VeriFone MX or VX device. Decryption takes place at the VeriShield Decryption Service. Status and alerts are centrally managed by the VeriShield Monitoring & Compliance console. Assessment Environment The VeriFone VeriShield Total Protect system was installed in Coalfire s Lab for the duration of the testing. A VeriFone VX 820 device was serially connected to a Coalfire provided Windows 7 machine. A VeriFone MX 915 devices was connected via USB and an MX 925 was connected via Ethernet; both to another Windows 7 machine. The Windows 7 machine hosted VeriFone s Form Agent application. Form agent simulates the logical POS interface to the VX and MX terminals, thus emulating a merchant s environment. The assessment included: Running payment card transactions using four test cards (American Express, Discover, Visa and MasterCard); Copyright 2013, Coalfire Systems Inc. Page 19

Monitoring interfaces for transmitted card data over a serial connection, USB and Ethernet. All transmitted card data was encrypted when leaving the VX or MX devices. Scanning the disk for unencrypted Track and PAN data both manually and using automated forensics tools. No card data was found on disk either encrypted or decrypted. The test equipment and software consisted of: 1. Serial Port Sniffer to monitor card data transferred from the VX 820 to the Form Agent application on the Windows machine; 2. USB Sniffer to monitor card data transferred from the MX 915 to the Form Agent application on the Windows machine; 3. Wireshark Ethernet port sniffer to monitor card data transferred from the MX 925 to the Form Agent application on the Windows machine; 4. Wireshark Ethernet port sniffer to monitor traffic from Windows machine to VSD hosted by VeriFone; 5. Magnetic card reader to verify Track 1 and Track 2 of test cards; 6. Remote access to VSD hosted by VeriFone to provide a feedback loop from the VSD to verify that the decrypted Track 1 and Track 2 data matched the unencrypted Track 1 and Track 2 data; 7. FTKCapture to create Disk Imaging application to capture the disk image of the Windows machines. Assessment testing used credit card transactions from four test cards (MasterCard, American Express, Discover, and Visa) and; scanning the system and database tables for Track 2 and unencrypted PAN data both manually and using automated forensics tools. Copyright 2013, Coalfire Systems Inc. Page 20

Figure 2: Test Configuration and Data Flow Diagram The diagram below illustrates the system as set up in the Coalfire labs. This dataflow diagram illustrates all test flows of cardholder data and the location of capture tools for analyzing data flows. VeriShield Total Protect Encryption Assessment The following charts show the results of the intercepted traffic from the MX and VX devices and the Windows machines. Note: The original full Track data was gathered independently using a magnetic card swipe device. Shown below are single specific examples, multiple examples were collected over the course of testing, across the 3 VeriFone devices, key rotation and via different methods including Serial sniffing, USB sniffing and Ethernet sniffing methods. Table 1: AMEX Track 2 Data vs. Encrypted Track 2 Data AMEX Test Card Source Ethernet Sniffer Full Original Track Data 347247137165329=1103101331063? Copyright 2013, Coalfire Systems Inc. Page 21

Full Track Encryption at MX 925 347247442085329=5503101713901? Table 2: VISA Track Data vs. Encrypted Track Data VISA Test Card Source Serial Sniffer Full Original Track Data %B4916870291537109^SEMTEK/TEST VISA CARD ^11051015218100 00024021000? ;4916870291537109=11051015218102402100? Full Track Encryption at VX 820 %B4916873076827109^SEMTEK/TEST VISA CARD ^55051011160605 77648588628? ;4916873076827109=55051019572262175128? Table 3: MasterCard Track Data vs. Encrypted Track Data MasterCard Test Card Source USB Sniffer Full Original Track Data %B5587442275354896^SEMTEK/TEST CARD MC ^1101101000100000000000690000000? ;5587442275354896=11011010001006900000? Full Track Encryption at MX 915 %B5587447007624896^SEMTEK/TEST CARD MC ^5501101155439894003235598825650? ;5587447007624896=55011015845422563496? These results demonstrate the encryption that is performed by the VeriShield Total Protect VCL on the device and all output is encrypted before any attached system, such as a POS, has received the data. The encrypted PANs pass the Luhn (mod 10) test. Error State and Out-of-Band Encryption The VeriShield Total Protect solution is configured to securely encrypt the greatest number of transactions possible at the point of swipe while managing a number of out-of-range and error conditions. Encryption rules have been enhanced in VTP. There are two transactional scenarios where encryption would not occur: 1. Expiration Out-of-Range If a card is swiped with an expiration date beyond 2054 the encryption function will not be executed. 2. BIN exclusion table A table to define BIN ranges to not encrypt is available. This can be used for fleet card and other gift or reward card type programs and no valid Card-branded ranges should ever be included. Specific encryption rules that will be encrypted include: Cards that do not pass the Luhn check (Mod 10). Cards that have expired. Cards where Track 1 PAN and Track 2 PAN does not match. Validation of Decryption at VeriShield Decryption ( VSD ) The following results were obtained using VeriFone s FormAgent PC test tool. FormAgent simulated a POS transaction prompting the MX and VX devices to accept the input of a card for a magnetic swipe transaction and also demonstrated the results of what was received. This data could then be used to send the encrypted data to the remote VSD server hosted by VeriFone. This feedback loop allowed a look into the Point-to-Point Encryption process. The process for verifying the Encryption was as follows: 1. Encrypted Track 1 or Track 2 data from the MX or VX device was captured by the serial, USB or Ethernet sniffer. Form agent also displayed the same encrypted data. Copyright 2013, Coalfire Systems Inc. Page 22

2. The captured Track 1 or Track 2 data was entered into the VSD by a remote connection and using a web browser and running the DecryptV04 API. 3. The VSD sent the decrypted Track 2 or Track 1 data back to the Coalfire monitoring workstation. Since the clear text track data was known, a comparison could be made between the Track 2 or Track 1 data sent by VSD and the known Track 2 or Track 1 data. The capture of data at serial, USB and Ethernet interfaces demonstrates that data flowing from the MX and VX devices is encrypted. The format of the encrypted data is valid. Any application, computer, network equipment, or transmission media cannot compromise card holder data since the card data is encrypted at the MX or VX device with VeriShield Total Protect. The following are a few examples of Form agent output, sniffer outputs and the VSD decryption responses: Figure 3: Form Agent Example Figure 4: Serial Capture Example Figure 5: USB Capture Example Copyright 2013, Coalfire Systems Inc. Page 23

Figure 6: Ethernet Capture Example Figure 7: VSD Decrypt Form Example Copyright 2013, Coalfire Systems Inc. Page 24

Figure 8: VSD Decrypt Result Example Disk Analysis The technical assessment included a forensic examination of the Windows workstation hard disk drive as well as the VSD hard disks. The process for examining the disk was as follows: 1. A complete workstation disk image and VSD server image was captured by FTK Image application on an external USB-hard drive; 2. The captured disk images were verified using a hashing algorithm; and 3. EnCase was used to search the disk images for all test card PANs and Tracks. There was no PAN or track data on any disk. The disk forensic analysis demonstrates that storage of any track data, encrypted or in the clear, is not taking place. The POS system does not handle any cardholder data, nor does it ever have access to it. The VSD servers are actually in scope under a service provider PCI DSS ROC, but images were taken to validate encrypted storage and to compare encrypted values throughout the entire process. The VeriShield Total Protect solution integrates securely with PC based POS or cash registers without exposing card data, encryption keys or authentication data to these platforms. WAN Traffic Assessment A Wireshark Ethernet port sniffer was used to monitor traffic from test POS machine to the VSD Servers. In a production scenario, traffic from the POS is encrypted using SSL. While not required, this encryption adds an additional layer of security at the transport layer. Copyright 2013, Coalfire Systems Inc. Page 25

Key Loading and Distribution With derived key only one key is loaded into the device; the MDK (Master Derivation Key). Once loaded the MDK is used to generate the DDK (Device Derivation Key) within the device. Once the DDK s are created, the MDK is securely deleted. There are two ways to load the MDK into the VeriFone devices: 1. Master Key Component Cards The HSM utility is used to create the files which are used to burn the Master Component cards for a specific KEK. The KEK is entered into the HSM utility and it creates the files that are used to burn the Master Component Cards. The Master Component Card swipes at the device cause VCL to fetch the wrapped MDK from the vcl_settings file and to unwrap it with the KEK that is derived from the data on the Master Component cards. Once the MDK has been successfully injected into the device, VCL uses it and other info to generate 90 DDKs. Then the MDK is deleted. VCL points to the 0 th DDK. 2. VeriShield Remote Key (VRK) A VRK Payload is created that will enable the device to unwrap the MDK that is wrapped in the Remote KEK. Once VCL has injected the MDK the process is the same as above. Copyright 2013, Coalfire Systems Inc. Page 26

Updating Keys There are three ways to advance the DDK within the VeriFone devices: 1. VCL Direct Interface A merchant can integrate directly to VCL to do the Advance DDK command. A merchant Point of Sale (POS) system will enable this feature so that the key can be advanced by direct interface from the POS. Once the advance DDK command is received, VCL will advance the DDK index to the next available DDK. The old DDK is deleted. VCL will create a command response which, when received by VSD, causes VSD to increment the DDK index portion of the derivation data for the virtual device that represents that physical device in the VSD database. No key data is exchanged. If no virtual device exists yet, one is created. Figure 9: Advance DDK - Key Management using VCL Direct Interface Copyright 2013, Coalfire Systems Inc. Page 27

2. VKM VeriShield Key Management The user may use VKM (VeriShield Key Management) to create Advance DDK jobs for selected devices. Once the device has fetched the job package via kmailman, VCL will advance the DDK index to the next available DDK. The old DDK is deleted. VCL will return status (via kmailman) back to the VKM service which will communicate to VSD. This causes VSD to increment the DDK index portion of the derivation data for the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data in the job package. Note that the user may create the job for already existing devices only. Figure 10: Advance DDK - Key Management using VKM Copyright 2013, Coalfire Systems Inc. Page 28

3. Command Cards VMB is used to generate a file that is used to burn a merchant specific Advance DDK command card. When the Advance DDK command card is swiped at a device, VCL will advance the DDK index to the next available DDK. The old DDK is deleted. VCL creates a command response which, when received by VSD, causes VSD to increment the DDK index portion of the derivation data for the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data on the Advance DDK command card. If no virtual device exists yet, one is created. Figure 11: Advance DDK - Key Management using Command Card Copyright 2013, Coalfire Systems Inc. Page 29

Key Management via Command Cards, VKM, and VCL Direct Interface The Command Card method is primarily used to load keys to a device during a pilot or proof of concept. Command cards are not used for production key management procedures, other than rare cases where some service providers choose to use them to advance the DDK from one key to the next. VKM requires either TCP/IP connectivity or a mechanism to push a file to the PIN pad device. Most merchants choose to use the VCL Direct Interface method of key management so they don t have to manage the creation and distribution of command cards, thus creating the most favorable operational environment for managing the changing of encryption keys. Command cards were necessary for our test system, but it replicates the use of how a KIF (Key Injection Facility) combines keys from the HSM into the device. A Command Card has a magnetic stripe card that contains an encrypted string of information used to load the necessary keys on the PIN pad device. There are five different types of command cards (or integration methods): 1. RegiStart: This enables encryption and all transactions are then encrypted based on the current DDK. 2. Stop Command Card: Used to turn encryption off. 3. Registart SRED: This is identical as the regular RegiStart, except that once this is run, encryption cannot be turned off. The Stop command card was tested after use of this card and it failed. 4. Advance DDK: This is used to move from one DDK to the next. This is the one item that can be done via a command card or via VKM in production, although most service providers to not use the command card option. 5. Update Settings: This is used to update a configuration parameter in VCL or to update a BIN exclusion file. There are also master key cards: Master Key Component Cards: Two cards are used, replicating the two components of that a KIF receives. These two values are XORed and used to inject the MDK from the vcl_settings file. 90 DDK s are generated at this point and the MDK is then deleted. VCL Direct Interface and Key Management A merchant POS vendor will work with the merchant to build the interface to VCL for the Registart command. After the integration is complete, the RegiStart command can be triggered at the POS and VCL will set the encryption state to ON. VCL creates a command response containing derivation data and the encryption on state which, when received by VSD, causes VSD to apply the derivation data and encryption state to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data in the RegiStart command. If no virtual device exists yet, one is created. This command card will fail at the device if the device is in SRED mode and the command response will contain the failure info. A merchant POS vendor will work with the merchant to build the interface to VCL for the Registart SRED command. When the RegiStart SRED command is triggered at the POS, VCL will set the encryption state to ON and SRED mode to enabled. VCL creates a command response containing derivation data, the encryption on state, and SRED on state which, when received by VSD, causes VSD to apply the derivation data, encryption stat, and SRED on mode to the virtual device that represents that physical device in the VSD database. No key data is exchanged. There is no key data in the RegiStart SRED command. If no virtual device exists yet, one is created. A merchant POS vendor will work with the merchant to build the interface to VCL for the Stop command. When the Stop command is triggered at the POS, VCL will set the encryption state to OFF. VCL creates a command response Copyright 2013, Coalfire Systems Inc. Page 30