For encrypting sensitive data, the web service call requires four parameters:
|
DID |
The unique encryption domain identifier. This is a numeric integer that logically represents the context within which the data is encrypted and tokenized. |
|
username |
The encryption domain username with the authorization to call this web service. |
|
password |
The password of the username to authenticate the credential of the requester. |
|
plaintext |
The sensitive data that must be encrypted and tokenized. |
When SAKA receives the request, it first verifies the credentials presented against its internal database or an LDAP directory server (depending on which is configured), and then determines their authorization to request the encryption service by determining if they are a member of an EncryptionAuthorized group. Note that if using LDAP, this group and its members must be created in the LDAP directory as a distinct task of the SAKA installation and configuration process; when using the SAKA internal database, this is performed automatically.
If the requester is authorized, SAKA uses an encryption key to encrypt the plaintext. It also uses a separate HMAC key to generate a unique HMAC of the plaintext. After performing these two cryptographic operations, it stores the ciphertext, the HMAC, the key-identifiers, and metadata about the request in the RDBMS. SAKA never stores the plaintext in the database or anywhere on the system—the plaintext is discarded immediately after the transaction. By default SAKA also generates a numerical token that is characteristically similar to the plaintext (16 digits for a credit-card number, 9 digits for a social security number, etc.) which can be used as a substitute for the plaintext data in applications.
Upon storing the data, SAKA replicates the transaction object to all other SAKA nodes within the same cluster and returns the token to the requester. The requesting application may use this token as a unique identifier for the plaintext and store it within its own database. The token can be configured to be identical in length to the plaintext data (up to a maximum 64 digits).
The replication latency between nodes within a cluster depends on the network capacity between nodes and the saturation of the network at the time of replication. The DEMO appliance provided by StrongKey on the internet has 1GbE ports and the network has light to moderate traffic on it; as a result, we have observed transactions to be replicated from one node to the other in an average of 1–2 seconds.
An illustration of the web service process is shown in the following diagram (to focus on the application's perspective, the replication details are not shown):
