SKLES Frequently Asked Question

1.  What are the major differences between StrongKey and StrongKey Lite?
2.  How fast does the SKLES perform?  How scalable is it?
3.  Is there a C/C++/C# client-library available with the SKLES?
4.  How does the SKLES use a cryptographic hardware module?
5.  How does the SKLES handle failovers?
6.  How does the tokenization scheme work in the SKLES?
7.  What kind of security is supported on the Client side when working with the SKLES?
8.  What kind of security is supported on the Server side of the SKLES?

2.  How fast does the SKLES perform?  How scalable is it? (Top )

Tthe SKLES encryption transaction consists of the following operations:

    - receiving a SOAP web-service call
    - authenticating/authorizing the requester
    - encrypting the plaintext
    - generating the HMAC
    - optionally, generating a pseudo-number (token)   
    - persisting the data and logging the transaction
    - returning the HMAC (or token) to the caller

Without taking network-latency into account, the entry-level Model T (with a quad-core, 64-bit Phenom processor, 4GB of DRAM and a TPM) clocked forty-three (43) encryption transactions per second (see last few lines of output below:).

.... 
 998.  Original value: 1111222233331997  Token received: Q2srOLvlga8U)U382Qmw3ySXPNNxliDHD31Yo3RZZku=
 999.  Original value: 1111222233331998  Token received: Tbbj3PYa3vWc7JN9301/s2oyFdK+tNaxqWEsRDXAM7Q=
1000.  Original value: 1111222233331999  Token received: ckrvtDQiHuw6iRuwtSIRWxst1w/TqLGOTaSUkALcW0M=

real    0m23.337s 
user    0m3.840s
user    0m0.178s 

We've also clocked thirty-seven (37) encryption and decryption transactions per second (which not only includes the full cycle for encryption described above, but the same cycle in reverse for decryption); this essentially means that it really consisted of 2000 web-service calls, authorizations and crypto-operations all occurring back-to-back; see the last few lines of the test:

.... 
 998.  Original value: 1111222233332997  Token received: MPOkWU06BSwNT9PvZFGa9JZ5aMiUnkRNTYFrCsTRX2Q=
SUCCESS: Original and recovered PANs are identical! 
 999.  Original value: 1111222233332998  Token received: jivl4H/hXlfUQcOIzuc+hduXJZahshWC/ghwEq+YDEk=
SUCCESS: Original and recovered PANs are identical! 
1000.  Original value: 1111222233332999  Token received: oGIfgCcdN4uQlsJBSYQaEhi/cc7j+TNjzlpdHUW3c/g=
SUCCESS: Original and recovered PANs are identical! 

real    0m27.838s 
user    0m5.360s
user    0m0.290s 

3.  Is there a C/C++/C# client-library available with the SKLES?  (Top )

Not yet.  However, the SKLES ships with a Java client library and a sample application that can be readily modified for use by customers.  A C/C++/C# client-library can be developed by knowledgable developers using the accompanying Web Service Description Language (WSDL) in the SKLES very  rapidly (one customer built a C# test client in less than 2 hours with Visual Studio).

Cryptographic hardware modules - such as the Trusted Platform Module (TPM) and the Hardware Security Module (HSM) - are used by the SKLES to protect the cryptographic keys within the appliance.  

For instance, within the SKLES Model-T, the TPM generates a unique Storage Root Key (SRK) for each appliance, whichc onsists of a 2048-bit asymmetric key-pair.  The SKLES then generates a Migration Authority Storage Key (MASK) for each appliance and replicates this across appliances during the installation process to establish trust amongst appliances. The MASK, which is also a 2048-bit asymmetric key-pair is encrypted under the SRK.  For every encryption domain created on the appliance, a unique 2048-bit asymmetric Domain Key pair is created and encrypted under the MASK.  A domain's AES symmetric encryption keys - which encrypts all sensitive data in the appliance - is finally encrypted under the encryption domain's Domain Key. 

In order to decrypt sensitive data, the chain of keys must first be decrypted before the AES key is available for use.  The TPM's SRK - which does not leave the TPM by design - is the ultimate protector of the chain of keys.  Three (3) Key Custodians are required to activate the TPM before it can be used to encrypt/decrypt the chain of keys.

HSM's are used in a similar fashion.

The SKLES is designed to work with a minimum of two appliances.  In the installation and setup - which takes between 2 -4 hours - you setup the Primary SKLES first and create a "Migration Authority Storage Key" (MASK).   The setup of the Secondary SKLES also creates its own MASK.  These MASKs are "introduced" to each other as trusted keys.

When a new encryption domain is setup on the Primary, its Domain Key is encrypted under under both MASKs and migrated to the Secondary.  All AES symmetric encryption keys and sensitive data ciphertext are replicated from the Primary to the Secondary through standard database replication (since the data is all encrypted, it can even be done over non-SSL ports).  Since the Domain Key is encrypted under both MASKs, the Secondary appliance can decrypt anything hat was encrypted under the Primary.

During a failure, when the Primary fails, your Network Management tool detects the failire and you initiate a small configuration process that "marks" where the Secondary will take over.  Firewall ports are opened up on the Secondary and the Secondary is now ready to accept service requests.  Since it has all records replicated to it upto the oment when the Primary failed, it can service any request the Primary had knowledge of.

When the Primary comes back into operation, a recovery process that mirrors the "new" transactions from the Secondary onto the Primary must be executed; after this, the Primary takes over again and Secondary is switched back into passive mode.

A more sophisticated setup is also possible with more SKLES boxes in the picture, with cascading replication.  In this scenario, the Primary replicates to a Secondary, and the Secondary replicates to a Tertiary machine.  Applications are designed to connect to the Primary first, and if unavailable, automatically connect to the Secondary.  Applications that use the SKLES web-services never connect to the Tertiary machine directly, so it serves as a final backstop in the failover architecture.  However, because of the cascading replication, intervention is not required for the first failover; applications can immediately attempt to connect to the Secondary
for services.  This setup is a little more complex, but it ensures that applications will never have to wait for encryption/decryption web-services due to the failure of a single SKLES appliance.

6.  How does the tokenization scheme work in the SKLES?  (Top )

The SKLES can tokenize anything - but it can return only numbers (currently).  The maximum size of the returned token can be upto 64-digits.  If you need an alpha-numeric token to be returned, this will have to be addressed as a special requirement.

The tokenization feature works very simply: you configure the number of digits you want returned in a token, say 16 digits for a credit-card number, and then set the starting value of the token, say 9999000000000001.  For each unique credit-card number received by the SKLES, the system increments the starting token value and returns that number after it has encrypted and stored the data in its internal database.  If the same credit card number comes to the appliance the same token is returned to the caller.

Applications can now use the returned token in place of the actual credit-card number when storing transaction data.  Since the transaction application neither has sensitive data, nor the key, it does not fall into scope of  security-audits for encryption and key-management.  Applications can simply return the token to the SKLES with the correct authorization to get the original credit-card number, when needed.

7.  What kind of security is supported on the Client side when working with the SKLES?  (Top )

Security on the client side is minimal - no key ever comes to the client; no encryption is ever performed on the client and as a consequence, no sensitive data is ever maintained on the client.  This has the effect of taking client applications out of audit-scope for regulatory compliance (such as for PCI-DSS).  All communication with the SKLES is over SSL.

The only security you need to be concerned about is the UserID and Password you will use to make web-service requests of the SKLES appliance.  The recommended approach is to have the users using your Clent application provide a UserID and Password before using the application, and then pass these as parameters into the web-service request.  This ensures that there is no sensitive information on the Client side that needs to be maintained on the hard-disk to make web-service requests.  Application-to-Application web-service requests can be secured through stronger layers of control, if desired, by enabling Client SSL Authentication on the SKLES appliance.

The SKLES can be integrated into your site's Active Directory, any other LDAP Directory server or use its internal database to manage users and their privileges within the SKLES.

8.  What kind of security is supported on the Server side of the SKLES?  (Top )

 On the server side, the SKLES uses a hardened Linux server for managing the security at the operating system layer.  To protect the sensitive data and the cryptographic keys, the SKLES uses a harware cryptographic module - such as a Trusted Platform Module (TPM) or a Hardware Security Module (HSM) - to protect the key-chain. 

For example, the TPM generates a Storage Root Key (SRK) which never leaves the TPM chip.  Since the TPM itself is soldered to the motherboard of the server, the TPM cannot be extracted and compromised by itself.   The SKLES generates a unique Migration Authority Storage Key (MASK) - a 2048-bit RSA key-pair - for each appliance and encrypts the MASKs private-key under the SRK.  The SKLES then generates a unique Encryption Domain Key (EDK) - another 2048-bit RSA key-pair - which is encrypted under the MASK.  All AES symmetric keys are encrypted under the unique EDK.  In order to decrypt sensitive data, the chain of keys must first be decrypted; this ultimately depends on activating the SRK in the TPM.

Each appliance has three (3) Key Custodians (KC) who  generate unique 2048-bit RSA keys at installation-time.  To activate the TPM, each KC must digitally sign a nonce and send it to the SKLES, which verifies the signature and then sets their part of the PIN to activate the TPM.  Once all three KCs have set their PINs, the TPM is activated and the SKLES is ready for use.  Without the KC PINs, the TPM cannot be activated.  Since no KC secret is stored on the appliance, the theft of the SKLES appliance is useless - everything is encrypted on the box and the master-key (the SRK) is inside the cryptographic hardware module.

The KCs do not need to be physically present at the SKLES to activate the TPM each time the machine is rebooted.  A VPN session to the appliance is sufficient.  A tool used by KCs and provided with the SKLES, will communicate securely over SSL with the SKLES appliance to authenticate them and set their PINs to activate the TPM.

The SKLES can be integrated into your site's Active Directory, any other LDAP Directory server or use its internal database to manage users and their privileges within the SKLES.