ODA for Transactions: What to Know for U.S. Payment Infrastructures
The payment card industry continues to evolve as authenticating card data is top of mind to help reduce counterfeiting of cards and protect cardholder data. Because of this, the U.S. payment industry continues to see adoption of EMV cards as a way to combat fraud and increase security for card present transactions. But, there are still some susceptibilities using chip cards when it comes to unique environments (e.g. transit) that in many cases cannot achieve sub second real-time authorization. For these types of environments, it is important to understand an EMV security feature known as offline data authentication.
The U.S. payment infrastructure is a real time online only environment – authenticating cards through terminals in real-time via a cryptogram that the issuer host validates. With the ongoing migration to EMV, one of the benefits offered is the ability to authenticate the card when a real-time online infrastructure is not available. This feature is known as offline data authentication (ODA).
Although ODA has not been a common practice among many of the issuers and some of the payment brands in the U.S., some merchants continue to indicate that they are still experiencing some volume of offline transactions. ODA means that transactions can be authenticated offline – between the card and terminal when real-time online connectivity to the issuer is not available.
An example of why ODA is increasingly being discussed in the U.S. includes transit agencies – which are evolving and moving toward implementing open payment infrastructures. Many transit agencies cannot go online in real-time as they need to have sub second transactions to allow passengers through the points of entry.
ODA is not necessarily complex and has been used all around the world – currently being mandated in Europe. There are essentially three levels of offline data authentication – Static Data Authentication (SDA), Dynamic Data Authentication (DDA), and Combined Data Authentication (CDA).
• SDA protects against counterfeitand is the basic level of ODA. SDA validates that the card data has not been fraudulently altered since the personalization of the card and a digital signature is created using certain card data, which is personalized on the card. As SDA is static it is no longer supported as a valid offline data authentication option.
• DDA protects against counterfeit and skimming. DDA is more secure than SDA as it is dynamic. With DDA, the card has a key that creates a dynamic digital signature, valid only for one authentication, using card data and unique one time terminal data.
• CDA protects against counterfeit, skimming and man-in-the-middle attacks. CDA allows for the highest level of security. For CDA, the generation of the digital signature is combined with the generation of the card’s application cryptogram to ensure that in addition to the card authentication we also ensure that the data exchanged between the terminal and card is not altered.
ODA necessitates some preliminary steps on the issuing side, including requiring the issuer to get public key certificates and create ICC public key certificates, which is typically done by the Issuer’s Personalization Bureaus. On the acceptance side, every device that has offline capabilities (most terminal types in the US are online with offline capabilities) comes with ODA standard out of the box, and all that is required is to add the payment brand’s public keys to the other parameters that EMV requires – including terminal capabilities, terminal action codes, etc.
When using ODA (like any other security feature) it’s always crucial to use a dynamic form of ODA (DDA/CDA) – which does require a chip card that supports RSA cryptographic functions. ODA requires building a public key infrastructure so that any card from any issuer can work at any payment terminal. To achieve this, the payment brands play a role as the Certificate Authority (CA) and share their public keys with acceptance infrastructure while they use their private keys to create issuer public key certificates for each Issuer BIN that will be personalized to use ODA. Once the terminals have the CA Public Keys (CAPKs) from all the payments brands they support, any card that has an Issuer public key certificate issued by payment brands can be authenticated using ODA.
To learn more about ODA, B2 can help walk you through the key elements, differences in ODA, and best practices. or walk you through an in-depth EMV Workshop to get you there. Contact us today to learn more about this, or visit our eLearning site.