BTW. You might want to refer to your brother in law’s girlfriend as his wife or she might get jealous…

1. Sometime within the next 24 hour cycle, you’ll want to decrypt that data in order to put the card number into detail records on an extract/settlement file. So, Alejandro’s DUKPT-like 128-bit methodology (as described above) works perfectly here. It surely meets PCI/CISP standards and the routines are reversible. This does result in two additional responsiblities:

* The file containing the LMKs and BDKs should be locked down in a secure directory using appropriate key management processes.

* The settlement file - at rest - will contain the clear card numbers. It’s beyond the scope of this blog to offer a solution to that, but as a consultant I will tell you that our customers have elected to solve that issue by encrypting the file using PGP prior to transmission to the settlement partner.

2. At any point subsequent to transaction completion, there’s a chance that a user will want to interrogate the transaction log to address a question like “Hey, what transpired with card XXXX at store 0720 on May 28th and May 29th?” (most probably this request was generated by a cardholder concern). So, you’d want to query the transaction log by card number. But - we’ve got an issue: the result of the field outputed in the methodology described here varies *by transaction* (the essence of DUKPT). So, to find all occurrences of usage by card XXXX, you’d have to decrpyt *all* the cards on the file in order to address the question. Obviously, this isn’t tenable. So, there’s a need to encrypt the card a second time for this other purpose. Here, though, we can make use a less-consumptive and less process-intensive methodology: an SHA-1 one-way hash gives us what we need because the result for any card Y will always be the same. It isn’t reversible, but doesn’t need to be: subsequent queries on card XXXX can create the SHA-1 hash and then search for all occurrences of the same value, thus addressing the requirements of ad-hoc, user-driven query needs.

The upshot of all this is an implementation in which the transaction log contains three fields:

a. A field that contains the literal string that matches what you can show according to PCI/CISP standards, i.e., the six-digit BIN + four trailing digits of a card. In other words, we have a field in a varchar(19) entry on a SQL DB that would contain ‘567890_______1234′ (that’s not implying use of mask here - we’re literally storing the underbars).

b. A second field contains the output of the SHA-1 hash, used for queries. Note in all cases that we’re encrypting ONLY the PAN. You can never store the entire track, not even if encrypted.

c. A third field (call it ’secureData’) will contain the result of the DUKPT routine (as well as some ancillary components and sanity checks) as described by Alejandro.

Please contact sales@jpos.org if you want to get additional information about training options.