Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

NS EMV Report1v4

VIEWS: 19 PAGES: 14

									             EMV CHIP & PIN APPROVALS & IMPLICATIONS FOR UK
[See Appendix A for Doc. Refs]

1. Summary

It is well understood that the introduction of EMV Chip & PIN requires that all card readers must be
type approved (EMV level 1). Less well understood however are the implications of the security
requirements and specifically the APACS Common Criteria Protection Profile. Typical integrators
and terminal manufacturers will no longer have the expertise nor the resources to integrate a „bare‟
card reader to create a secure Pin Entry Device (PED). Most individual projects will not be large
enough to pay for the significant cost for development and obtaining the required level of approval
of a proprietary PED.

The security requirements may also have a direct impact on the card reader design in order to
prevent probing via the card insertion slot and also to minimise the risk and cost of readers being
disabled via the insertion of foreign bodies.

As a direct result the only route to a significant proportion of the market will be through partnership
with experienced PED manufacturers (e.g. Hypercom, Dione) that will enable the Neuron reader to
be marketed as available within an off-the-shelf approved PED.

In order to have an opportunity of retaining existing business with Vbi (Meggitt) the type approved
motor driven reader must be made available without further delay. Without a significant project like
this it will prove very hard to get the development work done at an acceptable cost, thus making it
hard to compete later for other smaller contracts.

Neuron can add value to their products by including some of the additional functionality (e.g.
encryption services, tamper protection, Level 2 S/W kernel?) that is required to implement the PED
and by doing so this may lower the cost of integrating a more generic secure enclosure.

A successful partnership would enable Neuron to compete in a higher value market that would, at
least for motor driven readers, have a limited number of competitors.

It remains possible that the rules governing the security related approvals may be relax to enable a
secure reader to be approved for use with any approved PIN pad. Indeed it is hard to image how the
Unattended Payment Terminal (UPT) market will develop unless this occurs.

2. EMV

2.1 What is EMV Chip and Pin
See in particular doc ref. 2.3.4 as this covers similar ground as this document and goes into more
detail in some areas.

EMV (Europay, Mastercard & Visa) is a joint working group (ref. www.emvco.co.uk) that has defined
a set of technical specifications – now at version 4 - for the use of IC („smart‟) cards (ICC) by the
payment industry.

The EMV standards provide a framework to enable the interoperability of card acceptance through
common security and payment functions for use by different card schemes.
The EMV standard is defined by the following:-

1a.    EMV2000 v4.0 Book 1, Part 1: Electromechanical Characteristics, Logical interface,
       Transmission Protocols
1b.    EMV2000 v4.0 Book 1, Part 2 : Files, Commands & Application Selection
2.     EMV2000 v4.0 Book 2 : Security Functionality
3.     EMV2000 v4.0 Book 3 : Application
4.     EMV2000 v4.0 Book 4 : Interfaces

These standards define a multi-layered model, starting with the electro-mechanical interfaces
between the card (ICC) and the card acceptor (CAD)/interface device (IFD), through the low level
transport protocols to file structures, commands and the minimum software functionality that enable
the implementation of a payment application.

The move to chip card has been largely motivated by a requirement to improve card security, unlike
a magnetic card data stored on chip card is hard (if not impossible, or at least uneconomic) to copy
(„skim‟). In addition, the ICC actively participates in the transaction process to enforce security, for
example by enabling card data to be verified by the terminal as unaltered (Offline Data
Authentication provides for both static and dynamic methods, though only static is currently used)
and for the card to perform risk analysis. Refer to “VISA Chip Card Acceptance Device Reference
Guide” (doc ref. 2.3.2) Sec 2.3 for description of a transaction‟s processing steps. Also EMV200
book 2 (doc ref. 2.2.2) sec 5 for details on data authentication.

The introduction of PINs in general use enables the cardholder to be verified objectively by the card
itself, rather than the shop assistant, as the pin is stored securely on the card itself.

The standards include a number of options that may vary between card schemes and indeed
between national markets. As an example the method of cardholder verification (CVM) relies on a
prioritised list of alternatives that enables the card to specify the methods (e.g. off line pin, signature
etc) to be used. (see doc ref. 3.1.6) The PIN part of Chip & PIN comes from the fact that the normal
CVM will now be PIN entry, instead of signature. The latter as part of „Chip & Signature „ has been
used for a number of years in the UK.

Similarly EMV allows for three methods of pin verification – off-line encrypted, off-line plain text
& on-line: in the UK off-line plain text will be used. This means that the pin is not encoded when
the card reader transmits it to the card.

The EMV standards do not cover issues such as risk management rules, “on-line” security between
card and issuer, personalisation functions or other value added services.

Documents (refs 2.3.1 & 2.3.2) exist on both the Visa (www.visa.com) and MasterCard
(www.mastercard.com) web site that detail the schemes particular requirements for terminals to accept
Visa / Mastercard branded cards. These documents reference the EMV standards and although they
are easier to read than those documents, some of the information detailed within them may not
always be applicable to the UK market.

For example both documents subdivide CAT / UPT terminals into types dependant on transactional
value, with the type associated with low value transactions (<40$ for VISA, <$50 Mastercard) not
requiring CVM i.e. no pin. It has been stated (at post trial conference) that the aim will be that all
UPTs must have PIN entry. (see also doc ref. 3.1.11).

It is argued that this is required to prevent fraudsters using low value UPTs that do not have PIN
entry (but which rely on-line authorisation – „zero floor limit‟) to check whether a stolen card has
been stopped.

However in “Programme Recommendation No 11: CAT & UPTs Operational Principles” (ref.
3.1.11) the use of off-line PIN verification is “strongly preferred” rather than mandatory (ref. Sec
2.4 in that document). It also states (with reference to charge backs in sec 3.4) that “Non PIN
transactions (including chip & No CVM and magstripe cards as well as fallback transactions) will
not benefit from this payment guarantee and will continued to be processed under current rules”.

Clearly therefore accepting magstripe payment or chip based payment without pin (and hence
avoiding the associated costs and technical issues) remains available in theory and may be the best
option for low value transactions, at least in the short to medium term. It will be a business decision
to evaluate the potential cost of fraud and higher bank charges against the additional costs
associated with using full Chip & Pin solution.

In certain markets the move to chip&pin will be very much a political decision and chip&pin will
be specified as part of the requirements specification almost irrespective of cost e.g. local and
national government contracts.

Since the major driving force for the introduction of EMV is the prevention of fraud, security is a
key element of EMV. Security is implemented at a number of levels ranging from the physical
enclosures to the use of data encryption techniques to prevent the disclosure of sensitive
information (e.g. PINs). The encryption techniques [e.g. digital signatures] are also used to validate
data and the data source. (doc ref. 2.1.2).

The physical security specified by EMV requires that the terminal is „Tamper Evident‟ i.e. an
attempt to compromise the physical enclosure must be obvious to any cardholder. This is a
minimum standard and in the UK it has been extended by the adoption of Common Criteria and an
APACS protection profile. These require that the terminal is Tamper responsive. [see section 3
below on Security]. Although this is a UK specific requirement it is likely to be used or recognised
in other mature markets and in Europe especially.

The security requirements, although not part of EMV level 1, when combined with the fact that
PINs will be transmitted to the ICC in plain text format, has significant implications for the
integration of level 1 approved readers. These are explored further in sections 3&4.

The timescale for introduction of chip & pin remains officially on track with the liability shift
occurring Jan 1st, 2005 in the UK. Although there remains resistance amongst the middle tier
retailers, the larger organisations (Tesco, Safeway and Govt bodies) have now committed.

For example both the local Tesco store and a small corner shop PoS equipment near the
author’s office have already been updated. The latter because it uses a Bank Owned Terminal
(‘BOT’)
The liability shift will mean that if fraud occurs at a retailer that has not switched to Chip & Pin
then if Chip & Pin would have prevented the fraud the retailer will need to accept the cost of the
fraud.

2.2 EMV Approvals

The nature of the chip technology means that although logically more secure, it is in certain ways
physically less robust and more demanding in terms of operating conditions. In order to ensure that
any EMV chip card can operate securely in any EMV terminal and to do so without damage the
EMV standards cover the following areas: -

1a.    EMV2000 v4.0 Book 1, Part 1: Electromechanical Characteristics, Logical interface,
       Transmission Protocols
1b.    EMV2000 v4.0 Book 1, Part 2 : Files, Commands & Application Selection
2.     EMV2000 v4.0 Book 2 : Security Functionality
3.     EMV2000 v4.0 Book 3 : Application
4.     EMV2000 v4.0 Book 4 : Interfaces

Prior to the EMV2000 v4.0 the standard tested against was version 3.1.1 and while testing may be
carried out against either version, the v4.0 is a more precise specification and should be used when
ever possible. Testing against 3.11 will in any event be stopped on 1 March, 2004.

To enforce compliance to these standards terminals & applications must be tested and certified to
comply with the EMV standards by an approved test house. Compliance is divided between level 1
(hardware) and level 2 (software).

In effect level 1 is defined by 1a (above) and level 2 by 1b, 2, 3 & 4. (Doc refs 2.1.6 & 2.1.7).

Lists of approved hardware and software are maintained on the EMV Co. website.

The level 2 functionality can be encapsulated into a software black box (or kernel ) that can be
tested & approved and later re-used as a building block in many different systems. This kernel may
reside embedded in a dedicated control board or equally can run on a back office server or the POS
terminal itself. It will retain its approval essentially provided it does not require to be re-compiled.

It would appear that there are (at least) two types of level 2 approval. As previously indicated it is
possible for a software kernel to obtain level two approval and yet the level 2 test cases (Doc Ref.
2.1.7) include terminal specific cases that clearly can not apply to a software only kernel.

It is not clear if, or when, the test cases not applied in obtaining level 2 approval for a kernel would
be applied when the kernel is integrated into a system. Some of these issues associated with
integration are to do with security and these would be tested as part of the PED testing – see section
3 below.
3. Security: Common Criteria & VISA PED
(General Doc Refs: 3.1.9, 3.1.10, 3.3.2, 2.2.1 - 2.2.6, 2.2.3)

Security is required to protect information that if replicated by a criminal could compromise the
payment system. Information can be protected both by physical barriers and by encryption.

Encryption is used both to protect data (e.g. PIN numbers and messages) and to validate data as
authentic and unaltered. It is required whenever sensitive data is transmitted outside of secure
components.

Associated with encryption are keys that must in turn be protected and managed. Similarly the
cardholder‟s PIN is quite literally the key to the payment card and the PIN Entry Device (or PED)
must protect the PIN at all times. At the current time the UK implementation requires that the PIN
be transmitted to the card in plain text and so to prevent access to the PIN the same physical
security requirements apply to the card reader enclosure as to the pin pad itself.

There are at least two architectures for the PED (Doc ref. 2.2.1 p16)

(a) Card reader fully integrated with a PIN pad in a single secure box or terminal

(b) Card reader is separate from but connected in some manner to the PIN pad. Both devices must
then be enclosed in separate secure boxes, with the pin transmitted to the IFD Triple DES encrypted
according to the standards defined in ISO-9564-1. The secure box containing the reader must
contain sufficient functionality to decrypt the PIN and manage the associated keys.

Where the PED comprises physically separate components (as in b above) the security requirements
apply to each component individually. In addition to the technical requirements (associated with
both the physical protection and the encryption) this imposes significant additional costs associated
with obtaining the necessary security approvals.

At the moment every combination of secure reader and pin pad creates a new PED device which
must be tested and approved. Until it is accepted by the relevant authorities that a secure reader can
be tested either in isolation or with a suitable pin pad and for that approval to be applicable to the
reader irrespective of the pin pad used, there will be limited availability of approved solutions at
reasonable cost.

Until that time it is anticipated that many UPT systems will remain magnetic card based or possibly
EMV but without PIN – with on-line authorisation of every transaction. The cost of fraud and
possibly higher bank charges will be factored in to the price of the service or product served.

3.1 VISA PED
As indicated in 2.1 above although the EMV standards cover security, type approval testing does
not necessarily test all aspects. Clearly a level 2 approved software kernel can not be tested for
physical security. Therefore there is a need for further testing of the physical device(s) that will
store, transmit or process sensitive data.

The minimum standard to be met is defined by VISA in “VISA Pin Management Requirements:
Security Requirements Manual” (Doc Ref. 2.2.6, see www.visa.com/pin). MasterCard & American
Express do not yet have separate requirements, however discussions have been started in order to
define common worldwide standards.
Indeed there is reference on the EMVCo. website to the development of a EMV protection profile,
though it is not known yet how it will relate to the current VISA PED standards or the APACS
Common Criteria protection profile.

The VISA standards essentially duplicate those given in the EMV standards (ref. EMV 4.0 book 2,
sec 11.) and indeed the „Visa PIN Entry Device Testing & Approval Program Guide v2.3‟ (Doc
Ref. 2.2.6) states in sec. 2.0 that „the requirements for Offline POS PEDs are identical to current
EMV specifications and ISO standards‟.

The physical security required is for the terminal to be ‘Tamper Evident’ – that is any attempt
to gain access to sensitive data or to compromise the terminals operation will cause obvious damage
or is obvious in some other way. Any attempt to dismantle the unit (unscrewing the case) must
result in automatic clearing of sensitive data.

Note that although not specifically tested as part of the VISA PED approvals process the VISA
requirements do cover the logistics of ensuring that terminals that require initial or master keys to
be injected are securely transported from the manufacturer to the secure key injection site.

3.2 APACS PIN Pad Evaluation
For the UK market the APACS member banks have a requirement that all pin pads installed must
be evaluated against a protection profile in accordance with Common Criteria (ISO15408-1:1999)
procedures. For information on Common Criteria see www.commoncriteria.com

APACS has developed a protection profile (Doc ref. 2.2.1) which has been certified under Common
Criteria and it defines the security requirements for PEDs deployed in the UK. All new devices
installed on or after Jan. 1, 2004 must have gone through testing against it or something similar.

The protection profile details the threats that the PED must resist:-
T.Manipulation – An attempt to gain unauthorised access to elements of the PED by some sequence
of inputs or by an unauthorised use of a service,
T.Modification – An unauthorised attempt to modify services or information (e.g. code, encryption
keys)
T.Monitoring – Use of passive methods to probe the PED to infer or reveal design or operational
content (e.g. PINs, keys). Probing uses existing holes entry points in PED.
T.Penetration – Physical action e.g. perforation or opening device in an effort to compromise PED.
T. Stress – An attempt to gain unauthorised access to information by subjecting PED to
environmental stressing (e.g. changes to temperature, voltage or EM radiation.)

And have security objectives that include: -
O.Confidentiality – PED must provide functionality to protect the confidentiality of critical data
O.Probe – PED must protect itself and assets from probing
O.Stress – the PED must protect itself and assets from environmental stress
O.Tamper - the PED must protect itself and assets from unauthorised tampering

The profile, in the section on Security Functional Requirements, further details that the PED must
provide functionality to detect methods of physical compromise (this covers stressing, tampering
and probing) and it must be highly unlikely that the PED can be put back into service without the
physical tampering being noticed.
The PED must resist the attacks by responding automatically which must at least erase – master
keys, PIN encrypting keys, seed values and PIN values as well as sufficient memory so that it is
impossible to recover sensitive information.

To simplify further, the PED must be both tamper evident and tamper responsive.

3.3 Security Approvals
In the PMO „Programme Guideline G6‟ (Doc ref. 3.2.6) it is estimated that the evaluation of
terminals against the APACS Protection Profile will take approximately 4-8 months, at a cost of
£50,000 - £80,000. This compares to the 1 month and £12,500 estimates for VISA PED testing.

At the moment it is not possible to mix and match a pin pad and card reader that have been
separately tested without having to re-submit the pair for formal testing as if they created a new
PED.

As from Jan 1st, 2004 all new PEDs must have both VISA & APACS approval. All existing
installed PEDs to be compliment by 2010.

The deadline for Common Criteria has been relaxed so that terminals currently going through the
approval process can be installed after Jan 1, provided no significant reservations have been noted
in testing to date.
4. Approvals Summary
The Approvals process is well documented in the PMO document „Programme Guideline G6‟(Doc
Ref. 3.2.6) In summary the approvals required are: -

Phase                   Description                        Responsibility
1                       EMV Level 1: Hardware              Card Reader Vendor
2a                      EMV Level 2: Software Kernel       Software Vendor
2b                      Pin Pad Security                   Pin Pad or Pin Pad & Card
                                                           Reader Vendor
3a                      Mastercard Environment of Use      Retailer with system
                                                           vendor/integrator help
3b                      Visa End to End                    Retailer with system
                                                           vendor/integrator help
3c                      AmEx Device Testing                Retailer with system
                                                           vendor/integrator help
3d                     Other Scheme tests as required
4                      Aquirer (system) Testing            Retailer
See approvals flow chart.
5. Impact

By definition communication with an ICC is significantly more complicated than that with a
magnetic card and when combined with the requirement for level 2 approval it is unlikely that any
non-specialist company would have the in house expertise to develop their own level 2 solution.
Indeed IBM use a kernel developed by STS Ltd called EMVELINK. Similarly Vbi are in discussion
with both Hypercom and STS.

The availability of level 2 software kernels, designed to be used as a building block when integrated
with any level 1 hardware ensures that there is a degree of flexibility and competition in this market
with kernels available from a range of companies e.g. STS, CreditCall, Hypercom. In many ways it
represents a logical extension of the existing position with regard to EFT, which is not normally
developed in-house, but rather purchased from a third party specialist supplier.

One of the significant differences between kernels is where it is deigned to reside and run. Some
will run in proprietary control boards closely integrated with the Level 1 reader while others will
run in a host terminal, physically remote from the reader. The latter offers flexibility in that future
upgrades to the kernel will be easier to introduce, as would expanding the functionality to include
new applications. The former on the other hand offers greater flexibility for terminals that have
limited resources (e.g. vending machines).

Providing sufficient number of different kernels are developed – and this appears to be happening -
that offer a range of capabilities and options at a reasonable cost then one of the benefits should be
that developers of new terminals will be able to focus more on the application itself.

Similarly the requirement for level 1 type approval does not appear to be a significant hurdle as the
majority of reader suppliers have approved readers already available. Those that do not are in
danger of being excluded from bidding for the major contracts that will be settled during 2004
before the liability shift occurs in 2005. Exclusion from these may prevent or delay the integration
of their readers into approved Pin Entry Devices (PEDs).

Since both the hardware and the layer of software above it are standardised there is by definition a
much closer relationship between these two components than has been the case until now. It does
not mean that the level 2 kernel can work out of the box with any level 1 reader: there clearly
remains the need for drivers that will link a particular kernel to a particular reader. There will be an
advantage to the supplier of the kernel to ensure that their product supports different readers and to
the manufacturer in ensuring their reader is supported by a number of kernels.

This support need not necessarily mean that work is done prior to business being won, though in
some instances this may be desirable, but rather the work is assessed and costed.

The main technical challenge is the integration of the level 1 reader and PIN into a secure PED unit
[be that as a single module or as a pair of interconnected devices]. The need to meet the Common
Criteria /VISA PED requirements will impose significant additional development costs both
financial and in time, and will prevent the development of customised solutions for small-scale
projects.

Consideration must be also given in card reader design, be that manual or motor driven, to minimise
the potential disruption and cost that would be caused by a reader being easily disabled due to the
insertion of objects (broken cards, coins) into the slot. The use of shutters even on manual units
should be considered. Card readers that minimise this risk and in particular permit the removal of
foreign objects without breaching security enclosure will have an advantage.(doc ref. 3.1.12)

The T.Monitoring & O.Probe in the Protection profile require the PED to resist passive probing via
the normal openings, including that for the card itself. This clearly has potential implications for the
design of the card reader itself, and not just the secure enclosure.

It is unlikely that many CAT/UPT (if any) projects/applications will be of sufficient size to be
able to justify the cost associated with the development of a proprietary PED [card reader
enclosure and Pin Pad]. Those that are may not in any event have the in-house capability to
do the development.

Consequently the direct market for Neuron’s readers at this point in time will be limited to
those companies that manufacture PEDs. e.g. Hypercom, Dione, Ingenico.

In practice it is unlikely that these companies will specify their system with a single card reader.
Indeed Hypercom have already worked with both Omron and Magtek in order for these companies
to be able to submit bids to (for example) Vbi and Cubic. It will then be up to the end customer to
evaluate the readers and select the most appropriate one for their application. Given the costs
involved in the development of a finished approved product, that will only be done against a
specific project.

The use of encryption introduces the requirement for key management both within the PED and
within the manufacturing process. Whatever system is used for key management there will be a
requirement to inject keys into the PED and the injection of master or initial keys must be done at a
certified secure installation. Where the card reader is separate from the PIN pad then clearly the
same key management system (e.g. Derived Unique Key Per Transaction) must be used by the two
components.

Neuron must therefore now be willing and able to: -
1. Supply Level 1 Approved Readers
2. Co-operate with at least one PED manufactures.

With the ability to download scripts to the ICC it is possible for a card to be disabled and hence the
perceived need to be able to retain cards is greatly reduced. However it remains a requirement that
for magnetic card based transactions the capability to capture cards will be mandatory – only
terminals that accept only chip&pin transactions will be permitted not to be able to capture cards.
As such terminals will only be permitted when there is an alternative payment option nearby it is
predicted that card capture will remain a requirement for the foreseeable future. However it is quite
possible that there will be market pressure to move away from card capture and allow greater use of
lower cost readers (both manual and motor driven).

Advantages:
While EMV introduces many requirements that appear to have a negative impact on our
competitive position, it is worth noting that it has the potential of adding huge value to the card
reader product. This could occur through the integration of certain functions e.g. encryption into the
reader interface itself.
Also the requirements act as a significant barrier to market entry that may limit competition from
lower cost suppliers. The benefit from the experience gained in the UK market will then be
applicable as EMV is adopted across the rest of Europe and the world.

Fraud and lack of confidence in non-ATM terminals has been blamed for the slow acceptance of
kiosk and other UPT terminals e.g. fuel vending. It has been predicted that this market will double
over the next five years with the introduction of Chip & Pin.
Appendix A: Documentation

A.1      Web Sites
www.emvco.com
www.visa.com
www.visa.com/pin
www.mastercard.com
www.commoncriteria.com
www.chipandpin

Public Documentation
Ref.     Title                                                        File
2.1.1    Book 1: Application Independent ICC to Terminal Interface    Book1.pdf
         Requirements, Version 4.0
2.1.2    Book 2: Security and Key Management, Version 4.0             Book2.pdf
2.1.3    Book 3: Application Specification, Version 4.0               Book3.pdf
2.1.4    Book 4: Cardholder, Attendant, and Acquirer Interface        Book4.pdf
         Requirements, Version 4.0
2.1.5    EMV Issuer and Application Security Guidelines Version 1.2   EMV-SWG-
                                                                      N323IssuerandApplicationSecurityGuideli
                                                                      nesJuly2003.pdf
2.1.6    EMVCo Type Approval Terminal Level 1 Test Cases              T1_TC_V20.pdf
2.1.7    EMVCo Type Approval Terminal Level 2 Test Cases              L2_TC_V20_020131_ToBOM.pdf

2.2.1    PIN Entry Device Protection Profile                          PED_PPv1_37.pdf
2.2.2    Common Criteria Part 1: Introduction and general model       CCPART1V21.pdf
2.2.3    Common Criteria Part 2: Security functional requirements     CCPART2V21.pdf
2.2.4    Common Criteria Part 2: Security assurance requirements      CCPART3V21.pdf
2.2.5    Visa PED Evaluation FAQ (Technical)                          VISA PED
                                                                      Technical_FAQs_May_2003.pdf
2.2.6    Visa PIN Entry Device Testing & Approval Program Guide       PED_Program_Guide_May_2003
2.2.6    VISA Pin Management Requirements: Security Requirements      Visa_PED_Security_Requirements_Manu
         Manual                                                       al_August_2003.doc

2.3.1    MasterCard Chip-Business/Functional Requirements for Debit   Business.pdf
         and Credit Version 2.1
2.3.2    VISA Chip Card Acceptance Device Reference Guide             ChipCardAcceptanceDeviceRefGuide6.0-
                                                                      revA.pdf
2.3.3    Recommended Cryptographic methods                            recommended_crypto_methods_030129.p
                                                                      df
2.3.4    Redpay Consultants: SelfService Terminal EMV Upgrade         SelfServiceTerminalEMVUpgradeConsid
         Considerations                                               erations.pdf

Notes:-
2.1.n = EMVCo documentation
2.2.n = Security documentation
2.3.n = Other documentation

PMO Restricted Documentation
This documentation is available from the PMO web site (www.chipandpin.com) to program
participants [to register as a participant incurs a charge – please refer to web site for details].

Ref.     Title                                                        File
3.1.6    Programme Recommendation No 6: CVM List Settings             Recommendation 6 CVM List v1_0.pdf
3.1.9    Programme Recommendation No 9: PINpad Certification and      Recommendation no 9 - PIN encryption
         Evaluation                                                   V1_1.pdf
3.1.10   Programme Recommendation No 10: PINpad Certification and     Programme Recommendation 10 - PINpad
         Evaluation                                                  certification V1_3.pdf
3.1.11   Programme Recommendation No 11: CAT & UPTs Operational      Recommendation No 11 – CATsUPTs
         Principles                                                  Operational Principles V 1_1.pdf
3.1.12   Programme Recommendation No 12: Security At Point of Sale   Recommendation 12 Security at POS
                                                                     V1_1.pdf
3.2.6    Programme Guideline G6 – End to End Certification Process   Guideline G6 - Certification Process
         For POS Equipment                                           Description V1_1.pdf
3.3.1    Approvals road-map FAQs                                     Approvals road-map FAQs v0_1.pdf
3.3.2    APACS Security Evaluation FAQs                              PED Security FAQs V0_3.pdf

Notes:-
3.1.n = Programme Recommendation No n
3.2.n = Programme Guideline Gn
3.3.n = TOSC Working Papers

								
To top