The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard to prevent credit card scams and numerous additional security threats & vulnerabilities.
Payment Card Industry Data Security Standard
Credit/Debit card provider companies/corporations, such as MasterCard and Visa, implement the mechanism and security controls specified and suggested in the PCI DSS. The entities that store, process and transmit the card information also implement PCI DSS. A governing body named PCI SSC (Payment Card Industry Security Standards Council), established in 2006, holds the mandate of managing the development in PCI and alignment of policies to PCI DSS. The PCI DSS latest version (3.2) of was released in April 2016.
PCI Data Security Standard stipulates 12 requirements for compliance which includes further sub-requirements. Each requirement and sub-requirement are further defined into 3 parts.
- PCI DSS Requirements: It actually describes the requirement. PCI DSS compliance is validated against these requirements.
- Testing Procedures: It defines the methods to be followed by the evaluator to validate that the requirement has been implemented.
- Guidance: It illustrates the main fundamental objective of the requirement. It may also contain the helping material in contribution to the proper thoughtfulness of the requirement.
EMV is an international standard for debit & credit payment cards which incorporate a cryptographic microprocessor chip. The standard got the name from the companies which designed it, Europay, MasterCard & Visa. It includes technical workflows & mechanisms for smart payment cards for the machines and POS (point of sale) terminals that can accept them. EMV technology not only protects data stored on the card but also it makes much harder for malicious entities to use it in a negative way. Countries around the world use EMV cards for secure identity, payment, and healthcare applications. In addition, public corporations use smart employee ID cards to secure access to physical facilities and computer systems and networks.
EMV & MFA (multi-factor authentication)
Multifactor authentication (MFA) is a security mechanism that requires more than one method of authentication from independent categories of credentials to verify the user's identity for a login or other transaction. For example, something you have (possession of the card), something you know (card PIN) and something you are (Fingerprint). Traditional magnetic tape cards only require the card to be swiped. If the card has got in wrong hands, it can be used for business transactions. EMV cards require a PIN (a thing you know) before a transaction which belongs to the owner achieving 2-factor authentication.
Public Key Infrastructure (PKI) is a comprehensive and composite set of hardware, software, people, policies and procedures all put together with an aim to create, manage, store, distribute and revoke cryptographic keys and digital certificates. A digital certificate is an electronic document used to prove ownership of a public key. The certificate includes the public key, information about its owner's identity and associated permissions. Certificates provide the foundation of a public key infrastructure. Certificates are electronic representations of users, computers, network devices, or services, issued by a certification authority (CA), that are associated with a public and private key pair.
Protocols/technologies using PKI
Following protocols and technologies incorporate PKI and digital certificates:
- EMV cards
- TLS web servers.
- Secure Shell (SSH)
- Code Signing
- Secure Mail (S/MIME)
- Secure LDAP
- Microsoft Kerberos Smart Card Login
- Microsoft Active Directory Terminal Servers
- Secure POP/IMAP Protocols
- Digital Signed Trusted Drivers
- EFS (Encryption File System)
PKI for EMV cards
Businesses are becoming ever more dependent on digital information and electronic transactions, and as a result, face stringent data privacy compliance challenges and data security regulations. With the enterprise increasingly under threat of cyber-attacks and malicious insiders, business applications and networks are now dependent on the use of digital credentials to control how users and entities access sensitive data and critical system resources. PKIs go way beyond the use of user IDs and passwords, employing cryptographic technologies such as digital signatures and digital certificates to create unique credentials that can be validated beyond a reasonable doubt and on a mass scale.
Components of PKI
A PKI consists of more than just technology. It includes a security policy, certification authority, registration authority, certificate distribution system and PKI-enabled applications. PKI comprises of various components, understanding of each of these is necessary to develop a correct technical appreciation for those who have to operate an organization’s setup as shown in the figure.
Figure 1: PKI Integral Components
- Certificate Authority (CA): CA is responsible for following tasks regarding keys & certificates on EMV cards:
- Secure storage
- Registration Authority (RA): RA verifies the binding between a public key and the identity of EMV card holders. RAs conduct the initial verification of a potential EMV card user is issued a certificate.
- PKI-Enabled Entities: Entities that use the PKI technology are referred to as PKI-enabled entities. These include POS terminals, e-payment systems, EMV card users, computers, network devices and software agents. Certificate Authority certificate has to be distributed to all PKI-enabled entities for the establishment of trust.
- Certificate Store: It is an encrypted and secure database that stores issued certificates and pending or rejected certificate requests etc.
- Certificate Policies: A certificate policy (CP) is a document which aims to state what are the different actors, their roles and their duties in the execution workflow of a PKI.
- CRL (Certificate Revocation Lists): The CA publishes a CRL at regularly scheduled intervals. The CRL contains a list of serial numbers of EMV card certificates that are revoked and the reason codes for each revocation. The CRL Distribution Points (CDP) field in an EMV card certificate tells us where the CRL for that certificate can be downloaded typically an HTTP address.
- OCSP (Online Certificate Status Protocol): Defined in RFC 6960, OCSP is a protocol used for obtaining the revocation status of an X.509 digital certificate. OCSPs return an encrypted response about a single certificate. Authenticating party determines the OCSP responder’s URL by inspecting the certificate’s Authority Information Access (AIA) extension. If the extension contains an OCSP responder URL and the client supports OCSP, the client can proceed with sending an OCSP request to the OCSP server.
PKI recommendations for EMV cards
PCI DSS describes the requirements about cryptographic mechanisms as “Strong Cryptography” for all the key and certificate management. With respect to PKI, the recommendation for the use of PKI can be enlisted as:
- The standard for Digital Certificates: PKI setup must issue the digital certificates according to the RFC 5280. The standard currently in use by all well-known corporations for digital certificates is X.509 Version 3.
- The standard for CRL: PKI setup must issue the CRL according to the RFC 5280. The standard currently in use by all well-known corporations for CRL is X.509 Version 2. Revocations in case of EMV cards are very important because millions of EMV cards are being used at national/international level by state departments, corporate organizations, and banks. Hence the revocation rate is very high.
- Generation & Size of Public/Private Keys: The RSA/ECC public and private keys should be generated securely and should be equal to or higher than 2048/224-bits respectively.
Deliverables compliant to requirements of PCI DSS
PKI is one of the possible options which can help/assist in the following requirements of PCI DSS.
- Requirement 2.3 - Encrypt all non-console administrative access using strong cryptography.
Solution: HTTPS should be used to secure all sorts of remote administrative access. For HTTPS, TLS versions 1.2 & server certificates with RSA keys >= 2048 bit should be used. Legacy SSL protocols should not be used. Some servers also use SSH for secure logging, they must also use RSA keys >= 2048 bits.
- Requirement 3.5 - Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.
Solution: Digital signing and encryption keys should be stored in hardware security modules (HSMs), where they are protected from intentional and accidental attacks such as duplication and disclosure. Secure storage of keys requires them to be stored encrypted. The entire key and the data associated with the keys should be encrypted by well-known cryptographic algorithms 3DES and AES which are approved by NIST. The integrity of stored data and keys should also be maintained by standard hashing algorithms such as SHA-224, SHA-256, SHA-384, and SHA-512. EMV card key/certificate management is mostly done by using PKCS11 standard. HSMs are used for the secure storage of the CA key and all cryptographic operations such as random number generation (RNG) for certificates of EMV cards. The HSM should be at least FIPS 140-2 Level 3 certified. If the keys are being in software applications then they must be stored in password protected PKCS12 bundles.
- Requirement 3.6 - Fully document and implement all key management processes and procedures for cryptographic keys used for encryption of cardholder data.
Solution: PKI should define a detailed and comprehensive certificate policy. The RFC 3647 proposes a framework for the writing of certificate policies and Certification Practice Statements (CPS). The CP is responsible for generation, secure storage, distribution, modification, renewal, backup/archival, revocation/suspension and destruction of keys & certificates. The whole personalization & key management procedures/workflows are the part of certificate policy. Other attributes of a CP are architecture, certificate uses, operational controls and technical controls etc.
- Requirement 4.1 - Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.
Solution: TLS and IPsec (Internet protocol security) have to be used for the protection of sensitive CHD (cardholder data) during transmission over public or open networks. The practice of strong security protocols and cryptographic mechanisms fulfill this requirement. NIST Special Publication 800-52 “Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations” can help in detail to cater this requirement.
- Requirement 6 - Develop and maintain secure systems and application.
Solution: PKI can help in developing and maintaining secure application and systems by Code Signing. It is the technique of using digital signature based on X.509 certificates to digitally sign applications and software. A single bit of modification in the application will result in signature verification failure. System administrators can identify the unsigned and untrusted applications. Hence code signing provides two important assurances.
- Integrity: Application is modified or tampered by some malware.
- Authentication: The software belongs to a trusted publisher.
- Requirement 8.2 - Use passwords or strong authentication.
Solution: Strong authentication can be by two and three-factor authentication. The third factor for authentication may be the X.509 certificate stored on the EMV card. If a card has been stolen and the certificate serial number is published in CRL then authentication will fail.
- Requirement 8.4 - Send and store passwords securely.
Solution: PKI allows enabling encryption on the authentication servers by using TLS, IPSEC, SSH certificates etc. for securely logging and transmitting the password and important credentials over the network.
The need for key management
For systems that use PKI (and other cryptographic techniques) in compliance with PCI DSS, there are specific sections of requirement 3 that defines the expected behavior in relation to ‘key management’ processes and procedures.
While it is possible to implement key management as a manual process, performed by human beings following written procedures – these schemes typically scale badly, are vulnerable to errors and compromise and expensive to maintain to the required auditable level.
In contrast – centralized and automated key management systems are designed provide integrity and proof-of-behavior (audit) to processes; reduce risks and cost, and scale economically to the needs of a business.
Such key management systems can meet all the relevant PCI-DSS requirements around crypto key management and can help with both a confident compliance to the standard and a general improvement in the protection of business-critical data.
The worldwide adoption of EMV chip cards has contributed to the increase of e-commerce & online transactions. The risks and threats are also associated with the increasing use of EMV cards. The best defense strategy in this situation is proactive approach. This proactive approach can include many hybrid and layered defense mechanisms. PCI compliance considerably supports making systems more secure eventually minimizing the business risks.
PKI can address some requirements of PCI DSS and can also provide design/security recommendations with regards to the workflows and processes of key management.
1. Card-Not-Present Fraud Around the World (2017) by US Payments Forum
2. Selected articles on Key Management (2012-2016) by Ashiq JA, Asim Mehmood, Dawn M. Turner, Guillaume Forget, James H. Reinholm, Martin Eriksen and more
3. EMV Key Management – Explained (2015) by Cryptomathic