Regardless of what rules applications follow, businesses that choose to store CHD must comply with PCI-DSS Requirement 3.4, mandating the protection of sensitive CHD through approved/industry-standard cryptographic schemes and practices. It is at this point the application will call the SAKA webservice to “encrypt” the PAN.
In order to encrypt any sensitive data, the Foundation services of the SAKA requires the following four parameters:
TABLE 1: Parameters for the Encryption service
| # | Parameter | Explanation |
| 1 | did | The unique Encryption Domain identifier. This is a numeric integer that logically represents the context within which the data is encrypted and tokenized. |
| 2 | username | The username within the encryption domain with the authorization to call this webservice. |
| 3 | password | The password of the username to authenticate the credential of the requester. |
| 4 | plaintext | The sensitive data that must be encrypted and tokenized. |
When the webservice call returns after having completed the encryption and tokenization of sensitive data, the SAKA (in its default configuration) return a 16-digit token. Typically the token resembles the following numbers: 1000000000391711, 2000000000231307, 3000000000170319, etc. depending on the number of SAKA nodes in the Production cluster and the number of encrypted objects already stored in the IDB – the SAKA node with server ID #1 returns tokens that begin with the numeral one (1), the node with server ID #2 returns tokens that begin with the numeral two (2), and so on. The SAKA nodes handle replication between cluster nodes asynchronously in the background, so unless the network between nodes was very slow or non-working, all nodes of the cluster have all transactions within a few seconds/minutes.
Notwithstanding the fact that each node generates a unique token that returns the original sensitive data (regardless of which node is called), it is imperative that the application store the encryption domain identifier (DID) with the token in the ADB. This is because, the SAKA supports the ability to create hundreds of encryption domains on a single appliance (which are like virtual machines on a physical server), and each encryption domain is likely to return similar token numbers (unless the domain was specifically configured to return completely unique tokens across encryption domains).
As such, applications must know which encryption domain to contact when decrypting a token. Calling the wrong domain will either generate incorrect data (if the same credentials exist across domains) or fail to return a response due to invalid credentials. This leads to the first important design consideration when using the SAKA:
Design Consideration #1
|
The ADB must have a column in its data-schema to store the DID with the tokenized PAN, and the application must be modified to read the DID and send it with the token to the SAKA for decryption, deletion or relay webservices. The ADB should plan on using at least 3 digits for the DID column, unless your environment anticipates having more than 999 encryption domains within a single cluster. Do not assume that only one application will use the SAKA, and as such, all transactions will default to a single domain; in our experience, due to differing business needs, local laws and increasing sensitivity to the disclosure of even unregulated personally identifiable information (PII), companies are being forced to encrypt/tokenize more than just CHD in e-commerce applications. As such, it is almost certain that companies will need to use multiple encryption domains in the future; planning for it by including the DID in the data-schema will avoid painful modifications to the first application when a second application needs to use the SAKA. |
Since the SAKA (in its default configuration) is designed to return the same token for the same CHD no matter how many transactions are performed, the token may now be within all applications in the infrastructure to refer to the CHD. Authorized applications may decrypt the token to retrieve the original CHD when needed.