1

I’m researching a possibility of implementing KEK and DEK servers compliant with PCI-DSS requirements.

PCI Tokenization Guidelines states: “The tokenization solution should include a mechanism for distinguishing between tokens and actual PANs.”

The document doesn’t specify for which type of token the requirement above is relevant. Am I right thinking that it is NOT relevant for the tokens based on mathematically reversible cryptographic functions?

Thanks

4

Am I right thinking that it is NOT relevant for the tokens based on mathematically reversible cryptographic functions?

You're right. But you may not want to do it that way.

Tokens are generally isomorphic to card numbers (15-16 digit numeric) because they are supposed to be able to easily replace card numbers in whatever software the recipient uses.

If you were to use tokens that don't look like card numbers, than you've "provided a mechanism for distinguishing between tokens and actual PANs." 4111111111111111 is distinguishable from 057c331e-f538-11e4-b9b2-1697f925ec7b.

But tokens are usually generated by a processor or card brand and handed to a merchant for use instead of card numbers, usually using programmatic interfaces that were designed and specified to communicate 15-16 digit numbers. The merchant probably already has software, with a database and application logic and everything, that was designed to store card numbers. When they tokenize, they have to start storing tokens instead of card numbers. If the tokens look enough like card numbers, then it's usually a simple non-disruptive switch. For "distinguishing [between these isomophic] tokens and actual PANs", they might use invalid IIN/BIN numbers, fail the Luhn algorithm check, etc. etc.

| improve this answer | |
  • Thank you for confirmation. I appreciate and agree with your comment that for processor-merchant compatibility other tokenisation methods may be more appropriate. – Valentin Balaschenko May 8 '15 at 9:11
1

You are right. However, mathematically reversible tokens (aka encrypted data) have a much smaller reduction in PCI compliance scope than a real, randomly generated token. Also, if you are set on the mathematically reversible route, you can also use format-preserving encryption (FPE). FPE produces ciphertexts that can have the same length and format (digits, alphanumeric, ASCII...) as the plaintext.

The way to do traditional, vaulted, tokenization for PCI scope reduction is by generating random tokens and assigning them to PANs. The "mapping" is the database that can tell you which random token goes with which PAN (actually an encrypted PAN for good measure). This database is typically a very highly secure and separate environment referred to as "the token vault".

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.