VeriFone VeriShield Total Protect Technical Assessment White Paper

(1)

VeriFone VeriShield Total Protect

Technical Assessment

White Paper

Prepared for:

September 4th, 2013

Dan Fritsche, CISSP, QSA (P2PE), PA-QSA (P2PE) [email protected]

(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

(4)

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

(5)

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.

(6)

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

Procedures: 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.

(7)



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

(8)

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

(9)

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

(10)

card-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 Scope Reduction

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.

(11)

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.

(12)

Scope Reduction 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.

(13)



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

(14)

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

(15)

https://www.pcisecuritystandards.org/documents/which_applications_eligible_for_pa-dss_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

(16)

Summary PCI DSS Scope Reduction

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 Scope Reduction

PCI DSS

Area

Major Impact

Moderate Impact

Minor/No Impact

Section 1 X

Section 2 X

Section 3 X

Section 4 X

Section 5 X

Section 6 X

Section 7 X

Section 8 X

Section 9 X

Section 10 X

Section 11 X

Section 12 X

Legend:

(17)



Minor – Either no controls are removed from scope or minor impact to the scope of IT assets

requiring the controls

Detailed PCI DSS Scope Reduction

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.

(18)

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

Description

FPE

Format Preserving Encryption

HSM

Hardware Security Module

KIF

Key Injection Facility

PAYware Connect

VeriFone Payment Gateway, with integrated VSD

TRSM

Tamper Resistant Security Module

SRED

Secure Reading and Exchange of Data

VCL

VeriShield Crypto Library

VKM

VeriShield Key Management

VMB

VeriShield Merchant Boarding

VMC

VeriShield Monitoring & Compliance

VSD

VeriShield Decryption Service

(19)

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:

(20)



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.

(21)

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.

(22)

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

(23)

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

(24)

Figure 6: Ethernet Capture Example

(25)

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.

(26)

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.

(27)

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.

(28)

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.

(29)

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.

(30)

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

(31)

containing the encryption off state which, when received by VSD, causes VSD to apply the 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 Stop command. If no virtual device exists yet, one is created – but it will have no derivation data at all.

This command 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 Advance DDK

command. When the Advance DDK command is triggered at the POS, VCL will advance the DDK index to the very

next value. VCL creates a command response containing the new derivation data, when received by VSD, causes

VSD to apply the new derivation data 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 Advance DDK command. If no virtual device exists yet, one is

created. This command will fail at the device if the device is on the last DDK and the command response will contain

the failure info.

VKM and Key Management



The user may use VKM (VeriShield Key Management) to create RegiStart jobs for selected devices. Once the device

has fetched the job package via kmailman, VCL will set the encryption state to ON. VCL will return status (via

kmailman) back to the VKM service which will communicate to VSD. VCL will return encryption status and derivation

data (via kmailman) back to the VKM service which will communicate to VSD. This 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 job that is created by VKM. There is no key data in the

response that is returned by VCL. This job will fail at the device if the device is in SRED mode and VKM will receive

the failure info.



The user may use VKM (VeriShield Key Management) to create RegiStart SRED jobs for selected devices. Once the

device has fetched the job package via kmailman, VCL will set the encryption state to ON and SRED mode to

enabled. VCL will return encryption and SRED status and derivation data (via kmailman) back to the VKM service

which will communicate to VSD. This causes VSD to apply the derivation data, SRED state, 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 job that is created by VKM. There is no key data in the response that is returned by VCL.



The user may use VKM (VeriShield Key Management) to create Stop jobs for selected devices. Once the device has

fetched the job package via kmailman, VCL will set the encryption state to OFF. VCL will return status (via kmailman)

back to the VKM service which will communicate to VSD. VCL will return encryption status and derivation data (via

kmailman) back to the VKM service which will communicate to VSD . This 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 job that is created by VKM. There is no key data in the response that is

returned by VCL. This job will fail at the device if the device is in SRED mode and VKM will receive the failure info.

(32)

return status (via kmailman) back to the VKM service which will communicate to VSD. This causes VSD to apply the

new derivation data 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 job that is created by VKM. There is no key data in the response that is

returned by VCL. This job will fail at the device if the device is on the last DDK and VKM will receive the failure info.

Command Cards and Key Management:



VMB is used to generate a file that is used to burn a merchant specific RegiStart command card. When the RegiStart

command card is swiped at a device, 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 on the RegiStart command card. 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.



VMB is used to generate a file that is used to burn a merchant specific RegiStart SRED command card. When the

RegiStart SRED command card is swiped at a device, 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 state, 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 on the RegiStart SRED command card. If no virtual device exists yet, one is created.



VMB is used to generate a file that is used to burn a merchant specific Stop command card. When the Stop

command card is swiped at a device, VCL will set the encryption state to OFF. VCL creates a command response

containing the encryption OFF state which, when received by VSD, causes VSD to apply the 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 on the Stop command card. If no virtual device exists yet, one is created – but it will have no derivation data at

all. This command card will fail at the device if the device is in SRED mode and the command response will contain

the failure info.

(33)

SRED Information

Here are some guidelines for how SRED mode works:

 SRED is specific to Derived Unique Key Mode

 Encryption may NOT be stopped on a Derived Unique Key encrypting device that is in SRED mode.

 Once in SRED mode, a Derived Unique Key encrypting device may NOT be taken out of SRED mode.

 Encryption may ONLY be stopped on a Derived Unique Key encrypting device that is NOT in SRED mode.

 A new command card may be created that will start encryption and place the Derived Unique Key encrypting device in SRED mode.

 A new VKM job may be selected that will start encryption and place the Derived Unique Key encrypting device in SRED mode.

Specific to derived key mode:

 Derived Shared Key encrypting devices may NOT be placed in SRED mode.

 Start SRED command cards may NOT be made for Classic Mode devices.

 A Start SRED job may NOT be assigned to a Classic Mode device.

During testing, each of the devices was placed into each mode using the command cards. Encryption was turned back on

after the regular encryption mode was enabled and then put into the SRED encryption mode. The encrypted values were

observed to be the same, validating that the same DDK was in use regardless of mode. SRED mode is simply a one way

version of the encryption enablement on a device. Advance DDK was also used and new encrypted values were

observed. Swiping of track 1 and track 2, as well as manual entry of PAN and expiration date was done on each of the

devices to ensure no method of entry was ever output from the device in clear text.

Use of VKM

VKM is intended for use by service providers to enable key advancement remotely, as well as manage other basic

administrative functions. Access to VKM is structured based upon users, groups, and access rights. Service Providers

need to follow all standard PCI DSS practices in allowing access and use of VKM in support of their merchants.

Merchants using VTP should not have access to VKM in order to maintain the maximum reduction of applicable controls.

Summary

VTP is a robust P2PE solution that, if implemented correctly, can be used by merchants and service providers to

dramatically reduce both risk and scope for PCI DSS controls. VTP can be used to achieve a full PCI P2PE listing by service

providers to achieve maximum scope reduction to provide to merchants, and it can also be used in a non-listed manner

to achieve dramatic reduction of applicable controls as detailed above. Service Providers should follow all guidance on

how to use VTP properly and fully secure their back end decryption processes to PCI DSS standards. Merchants can use

VTP and this document to demonstrate how the technology works and enable QSA’s or other interested parties to be

able to evaluate their proper implementation of VTP into their environment.

(34)

Appendix A: PCI DSS Scope Reduction Risk Mappings

Detailed PCI DSS Scope Reduction

The information contained in the 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 reduction of applicable controls for merchants that have properly implemented the VTP solution.

Merchants should work with their QSA and acquirer to validate proper implementation and appropriate PCI DSS control

reduction before making any assumptions on scope reduction.

It’s important to note that the risk reduction values and their associated mapping to PCI DSS requirements below are

intended to address the applicability of each PCI testing procedure. The risk values are not intended as a

recommendation from Coalfire or VeriFone to remove existing security systems and controls from a merchant

environment. Merchant’s need to be aware of the principle of defense in depth; even though many of the

requirements in the table below are designated as “Not Applicable” for the purposes of obtaining a PCI DSS

validation, the associated security system and processes are still needed to meet industry best practices and protect

the merchant’s environment as a whole.

The information within the table is broken into the following columns:

PCI-DSS Testing Procedures: The PCI-DSS requirement testing procedure as outlined in the PCI-DSS v2.0.

Scope Reduction Risk Value: This is the associated risk value (1-4) associated with each PCI-DSS testing procedure. The

value indicates whether or not the scope for a PCI-DSS requirement can be reduced or eliminated. They are as follows:

1. Properly implemented, the VTP solution will completely eliminate the requirement from the scope of a

merchant’s PCI-DSS assessment.

2. Properly implemented, the VTP solution can significantly reduce or eliminate the requirement from the scope of

a merchant’s PCI-DSS assessment. Depending on the merchant’s cardholder data environment, some validation

from the QSA may be required.

3. Properly implemented, the VTP solution may reduce the testing associated with this requirement; however, the

control will need to be validated by the merchant’s QSA.

4. This requirement is fully in-scope for the merchant’s PCI-DSS assessment.

Note

: The risk rankings associated with each PCI DSS requirement relate to the VTP payment channel only. If the

merchant maintains other payment channels and processes they will need to be evaluated for scope separately.

Merchant Documentation: Mapped against the PCI-DSS ROC Reporting Instructions v2.0, the documentation a

Merchant is responsible for maintaining if a requirement is deemed in-scope for their PCI-DSS assessment.

Requirements with a Scope Reduction Risk value of 1 will not have any associated documentation expectations.

(35)

PCI-DSS v2.0 Testing Procedure

Scope Reduction Risk Value

Merchant Documentation Justification

1.1 Obtain and inspect the firewall and router

configuration standards and other documentation specified below to verify that standards are complete. Complete the following:

1.1.1 Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router

configurations.

1 Not Applicable When implemented properly, the VTP solution will remove the PCI DSS validation requirements for the merchant’s host network.

1.1.2.a Verify that a current network diagram (for example, one that shows cardholder data flows over the network) exists and that it documents all

connections to cardholder data, including any wireless networks.

3 Network Diagram Even with the significant reduction of applicable controls the VTP solution obtains, Coalfire feels that merchants should still diagram the data flow of the retail locations where VTP will be utilized.

1.1.2.b Verify that the diagram is kept current.

3 Network Diagram Even with the significant reduction of applicable controls the VTP solution obtains, Coalfire feels that merchants should still diagram the data flow of the retail locations where VTP will be utilized.

1.1.3.a Verify that firewall configuration standards include requirements for a firewall at each Internet connection and between any DMZ and the internal network zone.

1.1.3.b Verify that the current network diagram is consistent with the firewall

3 Network Diagram Coalfire feels that a network diagram is still appropriate for the merchant environment; however, it will not need to be compared to

(36)

PCI-DSS v2.0 Testing Procedure

Scope Reduction Risk Value

Merchant Documentation Justification

1.1.4 Verify that firewall and router configuration standards include a

description of groups, roles, and responsibilities for logical management of network components.

1.1.5.a Verify that firewall and router configuration standards include a

documented list of services, protocols and ports

necessary for business—for example, hypertext transfer protocol (HTTP) and Secure Sockets Layer (SSL), Secure Shell (SSH), and Virtual Private Network (VPN) protocols.

1.1.5.b Identify insecure services, protocols, and ports allowed; and verify they are necessary and that security features are documented and

implemented by examining firewall and router

configuration standards and settings for each service.

1.1.6.a Verify that firewall and router configuration standards require review of firewall and router rule sets at least every six months.

VeriFone VeriShield Total Protect Technical Assessment White Paper