Imagine you are making an online purchase. Your shopping cart is full and you can’t wait to place the order and have all of your chosen items delivered to your door. You click the “Checkout”’ button and are presented with the following prompt:
Please provide all the information we need to withdraw money from your bank account and make payments on your behalf whenever we want. You can trust us.
What would you do? We at Garantir would like to think that most people would be suspicious of this and would choose not to provide their information.
Now, imagine you are given the following prompt instead:
Please enter the following information:
- Credit Card Number
- Account Holder Name
- Expiration Date
- CVV
- Billing Address
The latter is probably much more familiar and most people are comfortable submitting all of this information. The interesting thing is that, outside of presentation and choice of words, there is no real difference between the two prompts.
That is, by providing your financial information to the merchant, you are providing them the information they need to make payments on your behalf whenever they want. You’re also trusting them to be good stewards of this information. From a security perspective, this is a very poor design.
In-Person Payments vs. Online Payments
Payments completed in person may have the benefit of leveraging cryptographic chips built into the payment card to enhance security (at least for modern cards). This is often referred to as EMV or Chip-and-PIN.
It’s important to note that the Chip-and-PIN method isn’t widely used in all places. Some countries, such as the United States, seem to prefer Chip-and-Signature. The Garantir team has its own opinions on the reduced security offered by Chip-and-Signature rather than Chip-and-PIN, the value of hand signatures in general, and other related topics, but we will save those for another post. In this post, we will focus on online payments, sometimes referred to as Card Not Present (CNP) transactions, as they make up a large portion of the total amount of payments made today.
While there have been attempts to make Chip-and-PIN available for CNP transactions— mainly by making chip readers available on end-user’s devices— these attempts have failed to garner widespread adoption. As a result, users have been left entering their financial information into websites and mobile applications. Due to the cost of getting a chip reader into every device, it is likely that Chip-and-PIN will not be a viable solution for CNP transactions for quite some time, if ever.
Preventative & Detective Security Controls
Financial institutions employ a number of security controls to secure CNP purchases. Some of these controls are enacted before the purchase is made. These are known as preventative controls because they can prevent a fraudulent transaction from happening before it occurs. Other controls happen after the purchase is complete. These are known as detective controls, as they detect that a fraudulent transaction has occurred once the transaction is complete.
Preventative controls are preferred because they stop a fraudulent transaction from occurring. This stands in contrast to detective measures, which discover the fraudulent transaction only after the fact and leave both customers and merchants to deal with the consequences. However, preventative controls must be balanced with the speed that we have all come to expect when making an online purchase.
An Overview of the Online Payment Process
A very high-level flow of how a purchase is made is shown below. The actual details are more complicated— involving the Issuing Bank, Acquiring Bank, Processor, etc.— but we are lumping these altogether as the “Financial Processor” for the sake of simplicity.
- Customer enters financial information into website / mobile application
- Merchant receives financial information and forwards it along with the purchase amount to the Financial Processor
- Financial Processor verifies financial information
- Financial Processor verifies funds
- Financial Processor performs threat assessment
- Financial Processor notifies the Merchant the transaction is successful
- Merchant finalizes the transaction with Customer (e.g., notifies order complete, delivers product, etc.)
In Step 1, the customer enters their financial information. This usually means a credit card number, expiration date, and so on, but could also be a bank account number and routing number, or some other form of payment information. This data is often accompanied with some personal information like the customer’s name, address, and phone number. The important thing to know is that, under normal circumstances, this data is static. That is, it doesn’t change on a transaction-to-transaction basis and can therefore be used to make illegitimate transactions at some point in the future.
In Step 2, the merchant relays the financial information to the financial processor, along with the payment amount and the merchant’s own information (e.g., Merchant Identification Number). In some cases, the merchant will save this financial information for audit purposes and/or future purchases. The major security issues here are:
- The financial processor receives the total payment amount from the merchant, not the customer.
- The merchant has to be trusted to not share the sensitive financial information with anyone else or otherwise use it nefariously.
- If the merchant saves the financial information, the merchant has to be trusted to implement proper security controls (e.g., encryption/tokenization, access controls, etc.) to safeguard the information from unauthorized third parties.
In Steps 3 and 5, the financial processor performs its security checks. At the most basic level, the processor verifies that the financial information is valid (e.g., account number, expiration date, and name all match). In some advanced cases, the financial processor will do further verification with the end-user before finalizing the transaction. Some examples of this include:
- 3-D Secure – The user is redirected to a login page on their bank’s website to authenticate themselves and approve the transaction.
- Push Notification Confirmation – The user is sent a notification, typically via SMS or an in-app push notification, about the transaction and asked to confirm its authenticity.
While these additional security controls are good, they are not used everywhere and they have their own issues. Most notably, both controls still result in the merchant being trusted with the customer’s sensitive financial information.
SET: A Better Way To Process Payments
What if there were a way to conduct a transaction with the following qualities:
- Sensitive financial information is not sent to the merchant (or any other entity)
- The merchant cannot alter the agreed upon transaction terms (e.g., cost)
- The merchant cannot replay the transaction to trigger another financial transaction
- Anyone can verify the validity of a valid transaction
- Anyone can detect an invalid transaction
- The security controls can be executed in real-time (i.e., verification is completed in sub-second time)
- The security controls are backwards compatible with most of the existing infrastructure for financial processors
Does this all sound too good to be true? It’s not. The solution has actually existed for years— it was just far ahead of its time.
Before we discuss the solution, it’s important to establish some background information. Those that have been following the Garantir blog know that we are strong advocates for using digital signatures. Here are the important points to know about a digital signature:
- The signature is unique to the transaction.
- Anyone can verify a signature with the public key.
- Only the holder of the private key can generate the signature (i.e., it is resistant to forgery).
- Signatures can be generated and verified in sub-second time.
- If the message changes then the signature will be invalidated.
It is for these reasons that the Secure Electronic Transaction (SET) protocol was designed to use digital signatures to ensure the security of online financial transactions. Here is an excerpt from the standard:
“An important innovation introduced in SET is the dual signature. The purpose of the dual signature is to link two messages that are intended for two different recipients. In this case, the customer wants to send the order information (OI) to the merchant and the payment information (PI) to the bank. The merchant does not need to know the customer’s credit-card number, and the bank does not need to know the details of the customer’s order. The customer is afforded extra protection in terms of privacy by keeping these two items separate. However, the two items must be linked in a way that can be used to resolve disputes if necessary. The link is needed so that the customer can prove that this payment is intended for this order and not for some other goods or service.”
Unfortunately, SET did not gain widespread adoption. There are a number of reasons why it didn’t gain traction, including:
- Initiated in 1996, SET was ahead of its time and came long before the advent of smartphones. At that time, browsers were incapable of implementing the cryptographic functionality that SET required and would’ve needed a great deal of work to support SET.
- Implementing this advanced cryptography back then was expensive.
- There were rumors that some companies may try to get a per-transaction fee for their part in implementing the advanced SET protocol.
With the prevalence of smartphones and rich browsing experiences today, we can now move past these hurdles and provide a more secure method of processing financial transactions. Additionally, one can extend on SET by encrypting the currently-used financial information (such as credit card number, CVV, etc.) and embedding the result in the consumer’s certificate. Then, once the signature is verified, the encrypted financial information can be extracted from the certificate, decrypted by the Issuing Bank (who is the only holder of the decryption key), and the transaction can be processed just as it currently is today. In other words, you get the security and privacy of SET without having to completely change the existing infrastructure that financial institutions have in place.
Conclusion
Digital signatures have myriad applications, even outside of payment processing. Other use cases include code signing, document signing, SSH, TLS, S/MIME, and more.
Interested in learning how to better apply digital signatures throughout your environment? The Garantir team can help. GaraSign, Garantir’s flagship product, is a cryptographic operations platform that makes operations like digital signatures more secure by enabling you to keep the private keys in hardware security modules at all times. A client-side hashing architecture keeps performance top-notch while a multitude of client integrations makes deploying GaraSign easy.
