The token used in HCE transactions is not simply a new number generated from the card number using a specific algorithm. The generated number contains a great deal of information:
- Tokenized card number
- SUK (Single Use Keys)
- Expiration Date
- RSA Keys and Certificates
- Token Transaction Limit
- Token Amount
- ATC (Application Transaction Counter)
What do these components do?
- Tokenized card number: A number used in place of the real card number. It has the same format as the card number, so POS terminals and payment networks can process it just like a normal card number. The real card number is never stored on the phone.
- Single Use Keys (SUK): Used to generate a cryptogram for each transaction. Once a key is used, it becomes invalid. When the keys run out, the app connects to the server to obtain new ones.
- Expiration date: This is the token's own validity period and may differ from the physical card's expiration date.
- RSA keys and certificates: Used to verify the token and the application, and to securely transmit data.
- Token transaction limit and amount: Limits the number and amount of transactions that can be made with the token. This reduces potential losses in situations such as the phone being compromised.
- ATC (Application Transaction Counter): Increases with every transaction, is used in the cryptogram calculation, and prevents the same transaction from being resubmitted.
Why are so many components needed?
In HCE, card data is held in an application running on the phone's general-purpose operating system, rather than in a secure chip as on a physical card. Since this environment is not as protected as a physical chip, security is not left to a single mechanism. The fact that the real card number never reaches the phone, that the keys are single-use, and that the token is defined with limited permissions all ensure that even if one component is compromised, the resulting risk remains limited.
