Handling of card data in conformance with PCI DSS

Transcription

1 Handling of card data in conformance with PCI DSS Version 2 June 2010 Objective MasterCard, Visa, American Express, Diners and JCB have together created the framework PCI DSS (Payment Card Industry Data Security Standard). The purpose of PCI DSS is to ensure that card data is handled in a proper way. The PCI DSS framework stipulates among other things, that all companies' handling card data must be annually audited. For larger companies this is a relatively burdensome and costly process. One way to reduce this cost is to reduce the number of systems that handle card data. This document describes a number of technical solutions to protect card data. These can be applied to a large number of systems that currently use card data for purposes other than payment, such as loyalty schemes and check-in/check-out. Important This document is not intended to be a specification; it is intended to display a number of possible solutions for: Minimize the work to achieve PCI certification Increasing the protection of card data when used for other purposes than payment The PCI Security Standards Council (PCI SSC) has not yet specified the requirements for encrypted card data and its impact on the PCI requirements, therefore, this document is only a best guess based on Visa's best practice for the encrypted card data ref [vbestpr]. Page 1 of 19

2 Version History Date Version Change By: New Document Martin Svenns Updated key structure based on Martin Svenns information from the terminal supplier Added handling of fuel Martin Svenns transactions as well as Clearing & Settlement Updated Local Encrypt Card Data Martin Svenns Contents 1 REFERENCES LIMIT THE SCOPE OF PCI TYPES OF CARD DATA CARDHOLDER DATA SENSITIVE AUTHENTICATION DATA THE ENCRYPTION OF CARD DATA FOR CLEARING AND SETTLEMENT MANAGEMENT OF CARD DATA IN PETROL PUMPS ENCRYPTION OF CARD DATA FOR PURPOSES OTHER THAN AUTHORISATION AND CLEARING KEY MANAGEMENT OF KEYS FOR ENCRYPTION OF CARD DATA TRANSFORMING CARD DATA INTO CARD NUMBER ALIASES CONLON CARD TOKENISATION ALGORITHM Schematic description of the Conlon Card Tokenisation Algoritm DISTRIBUTION OF KEYS FOR THE PROTECTION OF CARD DATA, (NOT PAYMENT) DISTRIBUTION TO TERMINALS DISTRIBUTION OF KEYS TO OTHER SYSTEMS LOAD GSALT LOAD UENC4CRD LOAD GENC4CRD LOCAL ENCRYPT CARD DATA RE-ENCRYPT CARD DATA FOR AUTHORISATION ENCRYPT CARD DATA GENERATE CARD NUMBER ALIAS Page 2 of 19

3 1 References [EFTPOS] [PPL] [PCI] ref [vbestpr] ref [salt] ref [sha-256] ref[bitmap] BCA Security Requirements for an EFTPOS Terminal Babs and CEKAB Program and Parameter Loading https: / / (cryptography) 2 Limit the scope of PCI Each computer that stores or processes card data will be subject to PCI DSS. The PCI DSS regulation requires that the sales company undergoes a comprehensive certification process every year. The aim of the PCI DSS certification process is to ensure that the card data is handled in a safe manner. The cost for PCI certification for a sales company can be very high, if card data is handled in many systems. One way to reduce the cost of this is to minimize the scope of PCI DSS certification by minimizing the number of systems and computers that contain or handle card data. This paper tries to describe a number of methods for removing the clear text handling of card data. For more information about PCI see ref [PCI]. 3 Types of card data PCI DSS regulations have defined two types of card data Cardholder Data Sensitive Authentication Data 3.1 Cardholder Data The following card data is defined as Cardholder Data: PAN (card number) Name of cardholder Expiry date Service Code All systems that handle Cardholder Data are subject to PCI regulations regardless of the system's task. PCI DSS certification will cover the entire system and all systems connected to it. Page 3 of 19

4 If any system on a computer handles Cardholder Data, then all systems that runs on the computer are subject to the PCI certification, regardless of whether they handle cardholder data or not. At present, there are two methods for converting Cardholder Data to something else and thus ensuring that the regulations' effect on the system is minimized. Encryption of card data Conversion of the card data to a card number alias, also called tokens or CNA (Card Number Alias). Proposals for solving this are described later in this document. 3.2 Sensitive Authentication Data The following card data is defined by PCI SSC as Sensitive Authentication Data: Full magnetic stripe Encrypted PIN-block CVV (card verification value) Sensitive Authentication Data must never be stored in any form and should not be used in any system for any purpose other than payments. 4 The encryption of card data for clearing and settlement Swedbank has updated the clearing interface to accept encrypted card data for clearing and settlement, see ref [bitmap] for technical info, this to enhance security and minimize the scope of PCI. To ensure that no one modifies the sensitive data in the clearing transaction and minimize the possibility of sabotage a digital signature is also included in the encrypted field. Note that the encryption operation must be conducted in a secure unit, to protect the cryptographic key. The field is structured as follows: Stripe 2 through and including the Service code Signed Amount Check Sum Encrypt ( ) Page 4 of 19

5 If the final amount of the purchase is known at the moment of authorization it must be entered as the signed amount. If the final amount is not known when the item is created the field must be set to 0. For more information on how encryption is implemented see ref [bitmap]. The checksum field is created as follows: ( Check sum (SHA-1) (SHA-1) ) Stripe 2 including Service code (Not CVV) Babs no. Amount Currency Code New terminals that use single message transaction must send this field in the authorisation transaction, so that the party who creates the clearing file can minimize the handling of card data in clear text. New integrated terminals that use separate messge for authorisation and settlement (dual message) can choose to: Send the field with the encrypted card data for clearing in the authorisation message Transfer data in the cash register integration protocol Both of the above options. If the clearing token is sent in the authorisation message, the clearing message can be created in more ways than if it takes place in the cash register integration protocol. If the authorisation transaction is re-encrypted (i.e. zone changed to HISO) before it is sent to SCS the clearing data must also be reencrypted in the same manner as the authorisation. 5 Management of card data in petrol pumps In most solutions for automated fuel dispensers a refuelling is performed in accordance with the following scenario; the customer puts the card into the payment terminal and performs an authorization. When the authorization is completed the customer takes out the card from the terminal and refuels the vehicle. After the refuelling is performed the right amount for the purchase is communicated to the card issuer. The messages between the payment terminal and the host system are: 1. An authorisation message for a fixed amount is sent before the customer starts to refuel. Page 5 of 19

6 2. An advice message that informs of the actual amount for the purchase is sent to the card issuer. This message is sent after the refuelling is completed and the card is no longer present in the reader. Both messages must contain encrypted card data, and a MAC (Message Authentication Code). Encryption and calculation of the MAC is carried out with a unique sequential key for each transaction. In order to meet safety requirements a key that has been used previously may not be reused in a subsequent transaction, i.e. there must be an ascending sequence. To keep the cost of technical equipment down, petrol companies often have several pumps connected to one payment terminal. This means that there may be several transactions where the authorisation message is sent but not the advice message. Therefore the MAC for advice messages cannot be calculated using the same key that the card data was encrypted with in the authorisation message. In order to manage this safely SCS proposes the following solution. 1. The customer puts the card into the terminal 2. The authorisation message is created 3. The card number is encrypted using a session key derived from UNC4CRD The session ID and encrypted card data is stored in the open area of the terminal or in the ECR. 4. When fuelling is completed and the purchase amount known, the following should be performed: 5. The encrypted card data is sent into the secure unit together with the amount purchased and clearing data and is identified with the session ID. This is used internally in the secure unit to re-encrypt the card data for the advice and clearing messages. The above procedure is in full compliance with PCI as card data is not stored in clear text and can not be re-created in clear text in the terminal. UENC4CRD will be distributed to the terminal via the IKFS file instead of being generated locally. To: Minimize requirements on the terminal, if it must be generated locally then the random number generator in the secure unit must be certified for key generation. If a safe unit fails, the encryption key can be reproduced centrally and the data decrypted. One unique key per transaction is used to ensure that an exhaustive search cannot Page 6 of 19

7 be done. The terminal/cash register must delete the locally encrypted card data when it is no longer needed. 6 Encryption of card data for purposes other than authorisation and clearing If a central system, for example a loyalty scheme, absolutely must deal with card data in clear text, the extent of PCI certification still can be limited to the terminal and the central system if the card data is encrypted in the secure unit of terminal and only the central system has the ability to decrypt the data for further processing. Note that card number alias is a safer and better model than encrypted card data if the system can be adapted to it. For intermediate systems that only handle encrypted card data, the scope of PCI certification may be limited, as the encrypted card data is not considered to be as sensitive as clear text data. If the central system handles card data in clear text, the system is subject to PCI DSS certification regardless of the input format. For the encrypted card data not to be considered sensitive from a PCI perspective the following rules must be fulfilled: Card data in clear text must not be available at any stage other than at the end points where it is encrypted/decrypted. All key management must be under the control of the acquirer Encryption must be carried out with a key whose sole purpose is to protect card data All storage and use of the cryptographic keys must be take place in a TRSM (PED or HSM). Encryption must be carried out with the DES algorithm, to be compatible with Swedbank's key distribution. If another approved algorithm is selected, the cost of adjusting the key system increases and the risk that the project is delayed increases. This model for protecting card data complies with VISA as best practice, which is today the only document regarding how card data must be securely handled, see ref[vbestpr]. Page 7 of 19

8 6.1 Key management of keys for encryption of card data PCI DSS requires that the keys that protect storage of card data are replaced annually. To avoid having to replace the key in the terminal annually, the encrypted block from the terminal must not be stored in a central system. If the central system needs to store the data in encrypted form the data shall be encrypted with a key dedicated for storage in the central system. The key used for protection of transport between the terminal and the central loyalty system may be the same for all terminals at the same sales company. The ideal solution utilises unique keys for every terminal but this is quite demanding and is not expected at present. 7 Transforming card data into card number alias Systems that need to connect a card number to an individual cardholder or an event For outer purposes than payment may choose to work with card number aliases instead of card number. Card number alias will probably become very popular and already has several names: CNA, short for Card Number Alias Token. Hashed card data The transformation of card data to a card number alias is performed by cryptography. The calculation will always generate the same CNA for the same card if the same crypto graphical key is used. The algorithm is a one way function so there will be no possibility to translate from a CNA to a card number. The algorithm used to generate a card number alias uses a DES key in to create a unique salt value. Thereafter a hash value is calculated over the salt value concatenated with the card number, the result from this operation is the card number alias. The key for this must be unique to every sales company/store chain, which means that the card number alias will be unique to each chain of stores. See ref [salt] for more information. One sale company may use more than one key. The salt value is used to make it impossible to conduct Brute Force attacks by compiling a database of all card number aliases. If the card number alias is used instead of the card number, both in the shop and in the central system then prerequisites exist for simplification of PCI certification of these systems. Card data converted to a card number alias with the algorithms below has the Page 8 of 19

9 prerequisites to not be deemed sensitive card data at a PCI audit. 7.1 Conlon Card Tokenisation Algorithm An algorithm that meets the above requirements is the Conlon Card Tokenisation algorithm. It has several advantages for Swedish solutions as only one extra DES key is distributed to the terminal. Mechanisms for distributing DES keys to the terminals and other systems exist today and can be reused. The Conlon Card Tokenisation algorithm requires: 1. That the DES key GSALT01 must be distributed to the terminal. The Conlon Card Tokenisation algorithm is as follows: 1. An 8-byte long MAC is calculated according to ISO over the card number with the key GSALT01 IV= Padding of card numbers in accordance with ISO , (Padding with zeros at even multiples of 8 bytes. If the card number is an even multiple of 8 bytes, no padding should be carried out). 2. The eight bytes long MAC value and the card number are merged in the following order: MAC, card data. 3. A hash value is calculated with the algorithm SHA-256 over the merged data byte KCV for 2 GSALT01 and the hash value are merged in the following order KCV, hash data. 5. The combined value is exported. Requirements: The entire operation must be carried out as an atomic function in a secure unit. If the secure device is a PED it must be approved in accordance with PCI PED If the secure unit is an HSM it must be approved in accordance PCI HSM More information about this approval see ref [pci]. 1) Note that ISO9797 requires that all the 8-bytes of the MAC calculated are not published. Here an exception is made to ensure that the salt value is not so short that 'brute force' attacks can be easily implemented. As the salt value is hashed together with the card data before it is published, this also poses no security risk. 2) Note that there is some probability that two keys may have the same KCV. When a new key is created, it must be verified that it does not collide with previously generated keys for generating SALT values. Page 9 of 19

10 7.1.1 Schematic description of the Conlon Card Tokenisation Algorithm KCV(GSALT01) 3 bytes Key:GSALT01 Card data IV= ISO method 3 and padding version 1 MAC 8 bytes Card data SHA-256 Card Token Hash 8 Distribution of keys for protection of card data Distribution of cryptographic keys to the terminal Distribution of cryptographic keys to a payment terminal that will connect to Swedbank is done via the PPL system. This relates to the distribution of additional keys to a terminal in production as well as the distribution of keys to a terminal that is not yet in production. Keys for the protection of card data with another purpose than payment must be distributed to the terminal in the IKFS file according to the following structure, see ref [EFTPOS] and ref [PPL] for more info: BKLK4SA BKLK4POS BKLK4BNK Page 10 of 19 GSALT01 UENC4CRD GENC4CRD

11 When the keys are to be distributed to the terminal the following constants must be used as key variants. GSALT GENC4CRD UENC4CRD The function of how the key variants are to be used is described in Ref [EFTPOS] chapter 8.3. The IKFS file with the cryptographic keys for the respective terminals is generated in a Key Management System. Swedbank's system for this (KMF) has support for generating IKFS files with the key for CNA. 8.2 Distribution of keys to other systems Other systems that use cryptographic keys to generate a card number alias must use an HSM to protect the keys. Under certain circumstances, a PCI PED can be approved as HSM. Distribution of the key to these occurs in the same manner as for the distribution of other cryptographic keys, i.e. a transport key is exchanged between the Babs KMF system and the receiving HSM system, the operational key is thereafter distributed in an encrypted file with a control vector for use according to ref [bcasecreq]. Page 11 of 19

12 Appendix A: Extended functions in PED application 8.3 Load GSALT01 Loads the GSALT key that comes in the IKFS file Function parameters: GSALT01 encrypted with the current version of BKLK4BNK with the variant for (GSALT01) applied. KCV for GSALT01 Processing: If the KCV for the existing GSALT is the same as the KCV for the key in the IKFS file, no further processing is to be done, return OK. Apply the version for GSALT of the current BKLK4BNK Decrypt GSALT01 with BKLK4BNK according to ref[etpos] Verify KCV for GSALT01 Store the key if proper verification of GSALT01 has been completed Update the flag for GSALT to indicate that GSALT01 is stored. Response parameters: OK. Possible Errors: Incorrect input Incorrect KCV BKLK4BNK not loaded at the terminal The version constant for the GSALT key is: Page 12 of 19

13 8.4 Load UENC4CRD Loading the UENC4CRD key that comes in the IKFS file Function parameters: UENC4CRD encrypted with the current BKLK4BNK with the variant for (UENC4CRD) applied. KCV for UENC4CRD Processing: If the KCV for the existing UENC4CRD is the same KCV as for the key in the IKFS file, no further processing is to be done, return OK. Apply the version for UENC4CRD of the current BKLK4BNK Decrypt UENC4CRD with BKLK4BNK according to ref[etpos] Verify KCV for UENC4CRD Store the key if proper verification of UENC4CRD has been completed Update the flag for UENC4CRD to indicate that UENC4CRD is stored. Response parameters: OK. Possible Errors: Incorrect input Incorrect KCV BKLK4BNK not loaded in the terminal The version constant for the UENC4CRD key is: Page 13 of 19

14 8.5 Load GENC4CRD Loading the GENC4CRD key that comes in the IKFS file Function parameters: GENC4CRD encrypted with the current BKLK4BNK with the variant for (GENC4CRD) applied. KCV for GENC4CRD Processing: If the KCV for the existing GENC4CRD is the same as for the key in the IKFS file, no further processing is to be done, return OK. Apply the version for GENC4CRD of the current BKLK4BNK Decrypt GENC4CRD with BKLK4BNK according to ref[etpos] Verify KCV for GENC4CRD Store the key if proper verification of GENC4CRD has been completed Update the flag for GENC4CRD to indicate that GENC4CRD is stored. Response parameters: OK. Possible Errors: Incorrect input Incorrect KCV BKLK4BNK not loaded in the terminal The version constant for the GENC4CRD key is: Page 14 of 19

15 8.6 Local Encrypt Card Data This function is used to encrypt card data (stripe 2 until and including service code) to be re-encrypted to the current DUKPT data encryption key, for the advice, adjustment and clearing message. Function parameters: Stripe two truncated after the service code, i.e. CVV value must never be included. Length of data. Requirements: To protect the terminal from brute force attacks there must be a barrier to these attacks, e.g. through limiting the number of calculations per unit of time. CardEncCounter is a 32 bytes long counter stored in the PED, CardEncCounter must be initialised to a random value when the terminal is first run. The counter must roll over when the maximum value is reached. Processing: Increase the previous CardEncCounter with 0x1 Calculate SHA-256 over CardEncCounter Save the first 24 bytes of the previous calculation as session ID. Encrypt the first 24 bytes of the session ID with UENC4CRD to calculate the session key ECB Mode. Pad the data as follows: Append a 1 byte length indicator Thereafter pad to even multiples of eight with 0x00, (including the length indicator). If the data + length indicator is an even multiple of 8 no padding is done. Set the length indicator to the number of pad bytes (0-7). Encrypt in CBC mode with IV = Response parameters: Encrypted data KCV Session ID (24 bytes) Possible Errors: Incorrect input. UENC4CRD not available Page 15 of 19

16 8.7 Re-encrypt Card Data for Authorisation The function re-encrypts the data that was previously encrypted with the function Local Encrypt Card Data, with the current DUKPT key for data encryption. This function creates an encrypted block of card data for: Advice or Adjustment Function parameters: Card data previously encrypted with the Local Encrypt Card Data function. Session ID Requirements: The whole operation must be completed as one call to ensure that the card data does not come to the open part of the terminal in clear text. Processing: Calculate the current key by encrypting the session ID with UENC4CRD ECB-mode Decrypt card data with the current session key, IV = , CBC-mode. Encrypt card data for advice/adjustment message as per the SPDH specification. Response parameters: Card Data for advice/adjustment messages encrypted with the current data encryption key. The KSN that the crypto block was calculated with Possible Errors: Incorrect input KSN used 255 times for data encryption UENC4CRD not available Page 16 of 19

17 8.8 Re-encrypt Card Data for Clearing The function re-encrypts the data that was previously encrypted with the function Local Encrypt Card Data with the current DUKPT key for data encryption. This function creates an encrypted block of card data for: Clearing Function parameters: Card data previously encrypted with the Local Encrypt Card Data feature. Babs no. Amount Currency Code Session ID Requirements: The whole operation must be completed as one call to ensure that the card data does not come to the open part of the terminal in clear text. Processing: Calculate the hash signature for the clearing message, as specified for clearing. A functional description can be found earlier in this document. Calculate the current key by encrypting the session ID with UENC4CRD. ECB-mode Decrypt card data with the current session key, IV = , CBC-mode. Encrypt card data for the clearing message as per the SPDH specification. Create the crypto block for the clearing transaction according to the BITMAP format. Response parameters: Card data for clearing encrypted with the current data encryption key. The KSN that the crypto block was calculated with. Possible Errors: Incorrect input KSN used 255 times for data encryption UENC4CRD not available Page 17 of 19

18 8.9 Encrypt Card Data This function must be used to encrypt card data for other purposes than purchase transactions. Normally the Card Data is encrypted, but other data may also be encrypted. Function parameters: Data for encryption. Length of data. Requirements: To protect the terminal from brute force attacks, there must be a barrier to these attacks e.g. through limiting the number of calculations per unit of time. Processing: Add 8-bytes with random data before the data that is to be encrypted. Pad the data to an even multiple of eight with zeros. If the data is divisible by eight from the beginning, no padding is to be done. Encrypt in CBC mode with IV = and the key GENC4CRD Parameters in the response: encrypted data 3-byte KCV can be used by the receiving system to select the correct key. Possible Errors: Incorrect input. GENC4CRD not available Page 18 of 19

19 8.10 Generate Card Number Alias This function generates a card number alias according to the Conlon Card Tokenisation algorithm described above. Function parameters: Card number Requirements: To protect the terminal from brute force attacks, there must be a barrier to these attacks e.g. through limiting the number of calculations per unit of time. Processing: Pad the card number to an even multiple of eight with zeros. If the data is divisible by eight from the beginning, no padding is to be done. Calculate an 8-byte long MAC in accordance with ISO , CBC mode IV= Concatenate the MAC and the card number Calculate a hash with the SHA-256 algorithm of the concatenated data Develop a three-byte long KCV (0) value Generate the card number alias by concatenating the KCV with the hash value <KCV + HASH> Response parameters 35-byte long card number aliases Possible Errors: Incorrect input. GSALT01 not loaded. 1) Note that ISO9797 requires that all the 8-bytes in the MAC calculated are not published. Here an exception is made to ensure that the salt value is not so short that 'brute force' attacks can be easily implemented. As the salt value is hashed together with the card number before it is published, this also poses no security risk. Page 19 of 19