You are on page 1of 4

Visa Europe’s Best Practices for Data Field Encryption, Version 1.

0
Visa Europe’s best practices for data field encryption are designed to further the industry’s efforts by developing a common standard that is open and interoperable, while also providing guidance to encryption vendors and organisations currently contemplating encryption solutions. These best practices should be viewed as high level guidance to be considered for any such solution and represent the first step in an on-going communications programme from Visa Europe, which will include a more detailed set of requirements for the validation of the secure implementation of data field encryption solutions. These best practices are based on the following security goals: Security Goals 1. Limit cleartext availability of cardholder data and sensitive authentication data to the point of encryption and the point of decryption 2. Use robust key management solutions consistent with international and/or regional standards 3. Use key-lengths and cryptographic algorithms consistent with international and/or regional standards 4. Protect devices used to perform cryptographic operations against physical/logical compromises 5. Use an alternate account or transaction identifier for business processes that require the primary account number to be utilised after authorisation, such as processing of recurring payments, customer loyalty programmes or fraud management Environment • Visa Europe’s best practices for data field encryption pertain to systems used to acquire payment transactions in physical locations such as: o o o o o o o Payment terminals Merchant point-of-sale systems In-store controllers Corporate transaction aggregation systems Payment gateways Core processing systems Acquirers or acquirer-processors

1

Part 1–Using Factoring-Based Public Key Cryptography Unilateral Key Transport (to be published) or equivalent should be used. TDES). mutual authentication of the sending and receiving devices should be performed.24 (all parts) or equivalent within Secure Cryptographic Devices (SCD) such as a PED. etc. Should you choose to follow them. Limit cleartext availability of cardholder data and sensitive authentication data to the point of encryption and the point of decryption i. • Must only be used to encrypt cardholder data and sensitive authentication data and cannot be used for any other purpose. HSM. Use robust key management solutions consistent with international and/or regional standards i. regional or international laws or regulations in place for displaying cardholder data. the key distribution method described in ANSI X9/TR-34 Interoperable Method for Distribution of Symmetric Keys using Asymmetric Techniques. iii.g. 2 . For example. Documentation describing the set-up and operation of the key management solution must be made available on request for evaluation purposes. NOTE: Keys used for PIN encryption must never be used for data field encryption (per PCI PIN Security Requirements). ii. AES. in settlement reports. ii. Data should be encrypted using only ISO or ANSI X9 approved encryption algorithms (e. iv. Sensitive authentication data must not be stored after authorisation even if encrypted (per PCI DSS). 2. you must comply with the following: 1.Best Practices The following are best practices for data field encryption to protect cardholder data and sensitive authentication data. This does not supersede national. Keys should be conveyed or transmitted in a secure manner.. v. Keys should be managed per ISO 11568 (all parts)/ANSI X9. All cardholder data and sensitive authentication data should be encrypted with the following exceptions: • The first six digits of the PAN may be left in the clear for routing purposes in authorisation processing.97 (all parts) or equivalent. Keys used in the data field encryption process: • Must be unique per device. iii. iv. etc. as defined in ISO 13491 (all parts)/ ANSI X9. • If remote key distribution is used. All keys and key components should be generated using an approved random or pseudo-random process such as NIST SP 800-22. Cleartext cardholder data and sensitive authentication data should only be available at the point of encryption and at the point of decryption. used for selection of account on file. • The first six and last four digits of the PAN may be displayed by the payment terminal and/or printed on the transaction receipt.

such methods shall also be implemented following all guidelines of said evaluation and peer review including any recommendations for associated key management. Use key-lengths and cryptographic algorithms consistent with international and/or regional standards i. This key size is stronger than needed. three key TDES (168-bits) or AES should be used. ii.g. two key TDES (112-bits) should not process more than one million transactions. see ISO TR-14742 Recommendations on Cryptographic Algorithms and their Use – Technical Report (to be published 2009). such as Derived Unique Key Per Transaction (DUKPT) can be used to ensure that any individual key is used only a limited number of times. The following table summarises equivalent bit strengths for commonly used approved algorithms: Algorithm TDES AES RSA ECC SHA Bit Length 112 1 128 2 2048 224 224 For details on equivalent bit strengths. Any methods used to produce encrypted text of the same length and data type as the original cleartext shall be evaluated by at least one independent security evaluation organisation (e. but if AES is to be used. Protect devices used to perform cryptographic operations against physical/logical compromises i. a standards body) and subjected to a peer review. 4. ii. Note: The smallest key size usable with AES is 128 bits. Encryption keys should have strength of at least 112 equivalent bit strength.Formatted: TOC 6 3. (Longer keys may of course be used if so desired. 1 For the purposes of these best practices. In cases where the number of transactions potentially processed through the system using a “single” 112 bits TDES key greatly exceeds one million.) 2 3 . Public keys should be protected from substitution and their integrity and authenticity should be ensured. Symmetric and private keys should be protected against physical and logical compromise. it is the smallest available. Devices used to perform cryptographic operations should undergo independent assessment to ensure that the hardware and software they are using is resilient to attack. Note that key management schemes that greatly limit the number of transaction processed by a single key.

o A multi-use transaction ID may be used if there is the need to maintain correlation (of the account) across multiple transactions. A salt should have a minimum length of 32-bits.g. if a salt is used. encrypting the PAN with an approved algorithm using a transaction-unique key.g. the salt must be kept secret and appropriately protected. 4 . the PAN) cannot be reproduced.5. or equivalent. a single-use or multiuse transaction ID or token should be used instead. • A single-use transaction ID is preferred. • Acceptable methods for producing a multi-use transaction ID include hashing of the cardholder data using a fixed (but unique per merchant) salt value. or equivalent. The single-use transaction ID can be produced by other methods provided that the resulting reference data is unique per transaction and the original cardholder data (e. o Acceptable methods for producing a single-use transaction ID include hashing of the PAN with a transaction-unique salt value. If cardholder data (e. NOTE: Irrespective of whether the transaction ID is a single use or multi-use. such as processing of recurring payments. the PAN) is needed after authorisation. customer loyalty programs or fraud management i. Use an alternate account or transaction identifier for business processes that require the primary account number to be utilised after authorisation.