I have to admit, I like the direction it's headed in. Any organization's goal (unless you are a payment processor) should be to reduce your PCI scope as much as possible, not try to bring PCI to your entire organization. This is a perfectly viable option to addressing risk that is often overlooked: ditch the asset. If you cannot afford to properly protect an asset, and you can find a way to not have to care for the asset anymore, then ditch it.
The questions I have about this specific implementation that are certainly going to have to be answered before anyone can use this to get a PCI QSA off of their back are:
1) What cryptographers have performed cryptanalysis on this "proprietary" design? Verifone's liberty to mingle the words "Triple DES" into their own marketing buzz format, "Hidden TDES", should at least concern you, if you know anything about the history of information security and the track records of proprietary encryption schemes. Since the plaintext and the ciphertext are exactly 16 digits (base 10) long and it appears that only the middle 6 digits are encrypted (see image below), this suggests that there might exist problems with randomness and other common crypto attacks. Sprinkle in the fact that credit card numbers must comply with the "Mod 10" rule (Luhn alogirthm), and I'm willing to bet a good number theorist could really reduce the possibilities of the middle 6 digits. If only the middle 6 digits are encrypted, and they have to be numbers between 0 and 9, then the probability of guessing the correct six digit number is one in a million. But the question is (and it's up to a mathematician or number theorist to answer), how many of the other 999,999 combinations of middle 6 digits, when combined with the first 6 and last 4 digits, actually satisfy the Mod 10 rule? [Especially since the "check digit" in the mod 10 credit card number rule is digit 14, which this method apparently doesn't encrypt.] I'm no mathematician, but I'm willing to bet significantly fewer than 999,999 satisfy the mod 10 rule. It's probably a sizeable cut-down on the brute-force space. If there are any other mistakes in the "H-TDES" design or implementation, it might be even easier to fill in the middle 6 gap.
It would be great to know that Verifone's design was open and peer-reviewed, instead of proprietary. I'd be very curious for someone like Bruce Schneier or Adi Shamir to spend some time reviewing it.
2) How are the keys generated, stored, and rotated? I certainly hope that all of these devices don't get hardcoded (eeprom's flashed) with a static shared key (but I wouldn't be surprised if they are). It would be nice to see something like a TPM (secure co-processor) embedded in the device. That way, we'd know there is an element of tamper resistance. It would be very bad if a study like the one the Light Blue Touchpaper guys at Cambridge University just published would detail that all of the devices share the same key (or just as bad, if all of the devices for a given retailer or bank share the same key).
It would be great if each device had its own public keypair and generated a session key with the bank's public key. This could be possible if the hardware card-swipe device sent the cardholder data to the bank directly instead of relying on a back office system to transmit it (arguably the back-end could do the transmission, provided the card swipe had access to generate a session key with the bank directly).
3) Will the PCI Security Council endorse a solution like this? (Unfortunately, this is probably the most pressing question on most organizations' minds.) If this does not take the Point of Sale system out of PCI scope, then most retailers will not embrace the solution. If the PCI Security Council looks at this correctly with an open mind, then they will seek answers to my questions #1 and #2 before answering #3. In theory, if the retailer doesn't have knowledge or possession of the decryption keys, POS would not be in PCI scope any more than the entire Internet is in PCI scope for e-tailers who use SSL.
...
Many vendors (or more accurately "payment service providers") are using "tokenization" of credit card numbers to get the sticky numbers out of e-tailers' databases and applications, which is a similar concept for e-commerce applications. A simple explanation of tokenizing a credit card number is simply creating a surrogate identifier that means nothing to anyone but the bank (service provider) and the e-tailer. The token replaces the credit card number in the e-tailer's systems, and in best-case scenarios the e-tailer doesn't even touch the card for a millisecond. [Because even a millisecond is long enough to be rooted, intercepted, and defrauded; the PCI Security Council knows that.]
It's great to see people thinking about solutions that fit the mantra: "If you don't have to keep it, then don't keep it."
[Note: all images are likely copyrighted by Verifone and are captures from their public presentation in PowerPoint PPS format here.]
...[Updated May 23, 2008: Someone pointed out that PCI only requires the middle 6 digits (to which I refer in "question 1" above) to be obscured or protected according to requirement 3.3: "Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed)." Hmmm... I'm not sure how that compares to the very next requirement (3.4): "Render PAN [Primary Account Number], at minimum, unreadable anywhere it is stored" Looks like all 16 digits need to be protected to me.]
8 comments:
Use of un-proven proprietary encryption methods in a transaction processing environment can certainly be a major risk for a retailer, especially if you are spending $50 to several hundered dollars per lane for the solution. I know several major retailers are now looking at MagTek's security solution, which I think they are calling MagneSafe. MagTek's solution uses industry standard decrptyion (3DES) and DUKPT key management. That's the same application retailers and card processors use for their pinpads today. MagTek also has a very unique card atuthenication solution built into the same reader solution that detects skimmed cards at the POS. Great for any mag stripe cards, including gift cards. The industry needs to adopt a Card Authentication system. Doing so would eliminate the need to protect data in the first place. Crooks would be unable to do anything with stolen card holder data if it did not work on a counterfeit card.
If the encryption is static (i.e. the same credit card number will make the same ciphertext every time) and the encrypted number can be used at the bank (as you said it could in the article) then the encrypted credit card number is just as sensitive as the original number. It will be susceptible to replay attacks.
If the encryption key is requested from the bank every time an encryption is to be performed then the ciphertext will be different every time and won't be susceptible to replay attacks. Obviously, this means that the keys can't be stored in the device but must be requested from the bank for every transaction.
This device sounds like it will need a lot of buy-in from the banks. They will need the infrastructure to hand out the encryption keys and software to decrypt the credit card numbers before using them. If your chosen bank doesn't offer this yet then you won't be able to use the device.
Mod 10 means simply "divisible by ten". That means that a six digit number has only 100,000 permutations (1/10 of 1,000,000) that are divisible by 10. 100,000 is already a pathetically small number in cryptographic terms. Then you have to factor the encryption algorithm into it. I strongly suspect that in order to create an algorithm that produces mod 10 ciphertexts every time you would need to sacrifice it's cryptographic integrity completely. It would probably end up being a simple substitution cipher.
Alternatively, if you kept the cryptographic integrity and kept switching the key until you got one that satisfied the mod 10 requirement you would most likely be limiting your keys by a factor of 10. (Which is technically sacrificing the cryptographic integrity anyway.)
Incidentally, even doing something like an MD5 hash of the entire credit card number and storing that is not secure. Thanks to the structured nature of credit card numbers, a brute force algorithm to decrypt the hashes would take only a couple of months to run on readily and cheaply available hardware. If you wanted to spend some money on it you could brute-force MD5 encrypted credit card numbers in a matter of hours.
I've just came across to your blog.
Helpful blog!
Cheers..:-)
Thanks for sharing your post and it was superb .I would like to hear more from you in future too.
Thanks anonymous-- if only there were enough hours in the day.
Take a cryptographic hash chain of the credit card number. A brute force method will become much less feasable in that scenario.
@Anonymous: the crypto hash chain has two distinct disadvantages:
1) The payment apps often need to access the credit card number again for payment processing (especially in this case as it traverses from POS to processor).
2) The output format length is too long to be a drop in replacement to a 16 digit card number that many commercial payment processing systems require.
Thanks for the post, I've been looking into Secure Payment Processing systems for my new business, and I wouldn't want to scammed by someone.
Post a Comment