4

I'm looking at implementing a PCI token generation process based on a MAC code obtained from the PAN. This would be an irreversible token.

The method I have in mind seems OK to me, but I'm not quite sure it would fly with a QSA. Some advice on the potential fails of my recipe would be very much appreciated.

Here are the details :

  • The token would be a 32 digits value, 10 of which would be decimal and 8, hexadecinal. The 10 decimal digits would be the first 6 and last 4 digits from the PAN. They are added only to create variety and avoid collisions;
  • The 8 hex digits would be a CBC MAC obtained from a 32 characters string formed by the PAN XORed with a salt, plus some padding made from some (repeated) PAN digits;
    • The HSM I'm using only supports 3DES with double-length keys (no AES, no SHA-256,etc...);

Does anyone have an opinion on this method?

schroeder
  • 123,438
  • 55
  • 284
  • 319
Claude Chouinard
  • 41
  • 1

1 Answers1

1

There is a specific tokenization guideline available in order to better understand the requirements and constraints of PCI-DSS in this regard.

This guideline specifies that there are different approaches regarding tokenization, being one of them "A one-way non-reversible cryptographic function (e.g., a hash function with strong, secret salt)". In addition, it allows a token format like 6+(Tokenized Value)+4.

In your scenario, from what I can ascertain, as long as the salt value used for your MAC-CBC is kept secret and unpredictable (thus making infeasible a bruteforce / collision attack in order to obtain the full PAN), you should be good in the eyes of a QSA.

Jausk
  • 209
  • 3
  • 9