Terence Spies of Voltage Security provided Thursday's second talk, discussing the regulatory agencies and standards for the credit card sector. There are roughly 144 billion credit cards in use currently, handling $\$$3.6T of transactions each year, of which around $\$$12B are believed to be fraudulent. With such a valuable market then, there is a clear need for security, and the data we care most about is the credit card number, known as the PAN in the industry.
As users you or I certainly care about our credit card details not being stolen or misused, but what does the company want? Well, any security tool must provide a qualified feature that can be presented to users or regulators, and so unsurprisingly the main drivers for change and improvement are standardisation bodies. Alongside national governments, the lead organisations in the sector are X9, PCI-SSC and EMV, run respectively by ANSI, the industry and a collaboration of Credit card companies lead by Europay-Mastercard-Visa. Not conforming to the appropriate standards can lead to a company being sanctioned, having its transaction fees increased, or even being disconnected from the payment network.
One of the key points that make this area most interesting is that the hardware is entrenched, a concept Terence referred to as "Brownfield Research". As such, any new schemes or techniques must be compatible with hardware up to 50 years old. These devices often have very specific (and unchangeable) database fields. In particular, this means that whilst we are no longer happy storing credit card numbers in the clear, the encrypted version must still look like a credit card number, or it would not be possible to store in the database. This is the driving force behind the use of Format Preserving Encryption (FPE), an encryption mechanism that ensures the message and ciphertext spaces are the same (roughly speaking, by wrapping a secure encryption scheme in an efficient de/encoding scheme).
The more interesting problem (from a technical point of view) is what can we do if you don't actually need to store the value itself? Certainly this is appealing from a security perspective, since if the card number is not stored, it cannot be stolen if the database is compromised. For example, a companies customer database might only be interested in what a particular card user has bought in the past. This requires just a unique identifier for the card, which need not be the card number. Preferably, possession of this identifier (the token) should not allow one to recalculate the card number. Initially this appears trivial (use a hash function), but this misses an important issue: the space of credit card numbers is (by cryptographic standards) very small. As a result, the security guarantees of modern symmetric primitives are often not relevant.
The upshot of this is that we require a more specialised primitive. In contrast to traditional block ciphers, which are developed to be efficiently implementable constructions for expanding a small key into a much larger permutation, we wish to use a secret static lookup table, which can be thought of as simply a very large key. These objects (sometimes referred to as big key encryption schemes) are so large that, even with such small message/ciphertext spaces, it is impractical for the adversary to learn about their content. Combining this with the tweak techniques of [LST12], the presentation explains, forms a viable tokenisation scheme.
Once we have a viable tokenisation method, we can extend this to create restricted tokens, that could be used instead of a card number, under certain restricted circumstances. For example, when visiting a hotel, rather than authorising your credit card for the institution to make an arbitrary transaction, it is (theoretically) possible to generate a specific token that only the hotel could use, and only within a certain time window. Indeed, ApplePay works in a similar manner, whereby a token is generated that is tied to your phone. Token revocation is possible (for example if your phone is stolen), but this is implemented in a decidedly non cryptographic manner: it is simply deleted from the list of valid tokens.
Overall then, this was a succinct introduction to the state of the payments industry, outlining some of the challenges and solutions that arise in this most real world of crypto problems.
As users you or I certainly care about our credit card details not being stolen or misused, but what does the company want? Well, any security tool must provide a qualified feature that can be presented to users or regulators, and so unsurprisingly the main drivers for change and improvement are standardisation bodies. Alongside national governments, the lead organisations in the sector are X9, PCI-SSC and EMV, run respectively by ANSI, the industry and a collaboration of Credit card companies lead by Europay-Mastercard-Visa. Not conforming to the appropriate standards can lead to a company being sanctioned, having its transaction fees increased, or even being disconnected from the payment network.
One of the key points that make this area most interesting is that the hardware is entrenched, a concept Terence referred to as "Brownfield Research". As such, any new schemes or techniques must be compatible with hardware up to 50 years old. These devices often have very specific (and unchangeable) database fields. In particular, this means that whilst we are no longer happy storing credit card numbers in the clear, the encrypted version must still look like a credit card number, or it would not be possible to store in the database. This is the driving force behind the use of Format Preserving Encryption (FPE), an encryption mechanism that ensures the message and ciphertext spaces are the same (roughly speaking, by wrapping a secure encryption scheme in an efficient de/encoding scheme).
The more interesting problem (from a technical point of view) is what can we do if you don't actually need to store the value itself? Certainly this is appealing from a security perspective, since if the card number is not stored, it cannot be stolen if the database is compromised. For example, a companies customer database might only be interested in what a particular card user has bought in the past. This requires just a unique identifier for the card, which need not be the card number. Preferably, possession of this identifier (the token) should not allow one to recalculate the card number. Initially this appears trivial (use a hash function), but this misses an important issue: the space of credit card numbers is (by cryptographic standards) very small. As a result, the security guarantees of modern symmetric primitives are often not relevant.
The upshot of this is that we require a more specialised primitive. In contrast to traditional block ciphers, which are developed to be efficiently implementable constructions for expanding a small key into a much larger permutation, we wish to use a secret static lookup table, which can be thought of as simply a very large key. These objects (sometimes referred to as big key encryption schemes) are so large that, even with such small message/ciphertext spaces, it is impractical for the adversary to learn about their content. Combining this with the tweak techniques of [LST12], the presentation explains, forms a viable tokenisation scheme.
Once we have a viable tokenisation method, we can extend this to create restricted tokens, that could be used instead of a card number, under certain restricted circumstances. For example, when visiting a hotel, rather than authorising your credit card for the institution to make an arbitrary transaction, it is (theoretically) possible to generate a specific token that only the hotel could use, and only within a certain time window. Indeed, ApplePay works in a similar manner, whereby a token is generated that is tied to your phone. Token revocation is possible (for example if your phone is stolen), but this is implemented in a decidedly non cryptographic manner: it is simply deleted from the list of valid tokens.
Overall then, this was a succinct introduction to the state of the payments industry, outlining some of the challenges and solutions that arise in this most real world of crypto problems.
No comments:
Post a Comment