3DES, DUKPT & E2EE Explained

May 14, 2009 by ADMIN
Share |

By John B. Frank, Marketing Strategist with HomeATM ePayment Solutions

I received a couple questions via email and wanted to take the time to provide a “coupla” of answers.  If you have any questions about anything I’ve blogged about over the past year, feel free to shoot me one. I’ve got my email below:

Q: Is Triple DES a better encryption standard than DUKPT?  (Derived Unique Key Per Transaction)?

A: I’ve used the terms Triple DES and DUKPT quite a bit in recent posts.  To clarify, let’s just start by saying that DUKPT does not really compete with Triple DES.  Let’s go over them one by one.

The DES stands for Data Encryption Standard, a block cipher that was selected as an official Federal Information Processing Standard (FIPS) for the United States in 1976.

Triple DES, sometimes shortened further as 3DES, increases the difficulty of cracking the encryption by applying three rounds of action: an encryption, a decryption and an encryption, each with independent keys.

3DES has become popular for encrypting financial transactions because it is potentially far more secure than DES, which has been shown to yield its secrets somewhat quickly to relatively cheap hardware.

Both DES and 3DES use a symmetric key. In other words, the same key enciphers and deciphers the protected data.  To keep the key secret, a secure key-management system is required.

Worldwide, POS devices handle billions of transactions per day.  If the keys to even a small portion of that traffic was discovered, we’d have a tremendously huge problem.  Which is my segway to DUKPT.

One way to prevent fraud is to use a different key for “each transaction,” (Derived Unique Key Per Transaction)   HomeATM’s secure devices (and thus your transactions) are “Protected by DUKPT” and each one is initialized with a master key.   The master key is from which the unique keys are derived, one for each “per” transaction.

The benefit of DUKPT is that even if an attacker discovered the key to a particular transaction, none of the other transactions from the same device would be able to be decrypted with that key.

That  said, a potential attack point (from a fraudster) would be the master key stored in the encrypting device. However, because HomeATM uses DUKPT, our device is built so that tampering with the device wipes this master key out.

These derived keys are used to encrypt transaction data with a symmetric cipher such as 3DES.

HomeATM also takes it one step further and encrypts the Track 2 data as well.  If you ever have any questions regarding financial transaction security or how HomeATM provides true end-to-end-encrypted transactions, feel free to email me.

Before I get to the next question, I’ve got one for you.

When you “type” your card number into a “box” on a merchant website, is it protected by DUKPT?  Is it encrypted?  If so, DES or 3DES?  First one to send me the correct answer gets a Free HomeATM PED!

Q: What is TRUE end-to-end encryption?  (E2EE)

A: First of all, “true” end-to-end encryption can only occur with a PIN based transaction.  It doesn’t exist outside of that scope because their exists a point of the process where the cardholder data is unencypted and recrypted is therefore vulnerable.

With that said, with Heartland’s proposal for end-to-end encryption, E2EE has certainly become a hot topic.

Keep in mind that Heartland’s proposal came “AFTER” their breach…while HomeATM instituted end-to-end encryption from “the beginning.  I’m not bragging.  I’m proudly displaying our insight into the weaknesses inherent in the payments system.

But let’s get back to Heartland, shall we?  In this post I will attempt to explain why they CANNOT simplysnap their fingers and introduce E2EE on their own.

While it’s true that some large U.S. retailers encrypt data in transit within their organization, it’s also true that most don’t.  So in order for E2EE to work, a lot of retailers would have to revamp their systems.  Very costly indeed.

In addition, the top full-service U.S. payment processors also don’t currently support E2EE;  thus, retailers that encrypt card data in transit typically must decrypt it before they send it to their processor.

The key word here is decrypt.  That’s the weak point and therein lies the problem.

PIN Debit is an entirely different animal.  Card brand standards require that PINs are encrypted end-to-end.   In fact, speaking about Heartland’s quest for E2EE,  Distinguished Gartner Analyst Avivah Litan stated:

“End-to-end encryption would be most effective if data was encrypted from the time a card was swiped at a POS until it reached the card issuer, similar to the way personal identification numbers (PINs) currently are encrypted according to card brand standards.”

Starting to get the point?  If not here’s some more:  Ms. Litan went on to state:

“Heartland is limited by the scope of systems it manages and from which it accepts data; it can only seek to influence the card industry to carry end-to-end encryption beyond the processor stage, through the card networks and onto the card issuers. The proposal’s success also depends on merchants’ willingness to invest in terminal upgrades that support card data encryption.”

Author’s Note: For instance…HomeATM’s PCI 2.0 Certified SafeTPIN PED which also encrypts the Track 2 data.  Avivah continues:

“If Heartland implements its proposed project more securely than it has managed in the past with its network, it will make payment card processing more secure for merchants, especially if they don’t manage the encryption keys and leave key management to their processor. Nevertheless, the process will always include vulnerabilities at the point where data is encrypted and decrypted. These vulnerabilities can be limited by using “sound key management practices” and enforcing extra security measures, such as “requiring two separately managed sets of keys for cryptographic operation.”

Can you provide an example of a “sound key management practice?  That’s why HomeATM is the closest thing to TRUE end-to-end encryption in the industry.  (our industry being eCommerce payments and Real Time Money Transfer.)

In the bricks and mortar world, end-to-end encryption doesn’t exist and the whole system would need to be revamped.  You can learn more about that in this related post where Avivah Litan asks:  Hacked! Is Visa Next?

HomeATM’s Engineering Team Designed and Manufactures the World’s FIRST and ONLY PCI 2.0 PIN Entry Device Specifically Designed for eCommerce. Our device provides “Card Present” rates on credit cards and “True PIN Debit” Interchange on debit cards as well as secure 2FA authentication for online banking sites and live, “real-time” money transfer from P2P, B2B, B2P, P2B and mobile.

To learn more about our product’s and services click here or email us at: info@homeatm.net

Stay Informed With RSS Feeds or Email Alerts Here: 

These icons link to social bookmarking sites where readers can share and discover new web pages.
  • TwitThis
  • LinkedIn
  • Google Bookmarks
  • Digg
  • StumbleUpon
  • YahooBuzz
  • del.icio.us
  • Wikio
  • Propeller
  • Facebook
  • MySpace
Share |


Filed under: Breach, D&O Liability, FEATURE ARTICLE, Financial, HomeATM, PCI, Sarbanes-Oxley, Uncategorized, hackers, identity-theft, privacy 

Comments

2 Comments on 3DES, DUKPT & E2EE Explained

  1. James S on Fri, 15th May 2009 2:59 pm
  2. Regarding your question about “the little box” on a merchant website.

    Merchant transactions (via the web) are usually encrypted using SSL/TLS encryption (hopefully ssl2 not ssl1) and could potentially use any of the ciphers below. Most often I’ve seen them use Cryptographic hash’s, and that is most often SHA.

    Ciphers
    Blowfish, Camellia, DES, RC2, RC4, RC5, IDEA, AES
    Cryptographic hash functions
    MD5, MD2, SHA, MDC-2
    Public-key cryptography
    RSA, DSA, Diffie-Hellman key exchange, Elliptic curve

  3. Payments Expert on Wed, 20th May 2009 7:23 pm
  4. This article appears to have missed the last 5 years advances in cryptography that does permit true end to end encryption without the need for extra “black boxes” and changes intermediate systems.

    Plenty of debate on this right now especially around the concepts like Format Preserving Encryption.

Tell me what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!