StrongAuth KeyAppliance

KA Module

About KeyAppliance™

It comes with 64-bit Linux Operating System, Glassfish JEE5 Application Server, MySQL Relational Database and, StrongKey Lite Encryption System.

Yes, we do have a client application in C# and Managed C++. However, the KeyAppliance 2.0 ships with a Java client library and a sample application that can be readily modified for use by customers.

Without taking network-latency into account, when tested with multi-threaded clients, the entry-level Model T (with an eight-core, 64-bit processor, 8GB of DRAM and a TPM) clocked approximately two hundred and twenty (220) webbservice operations per second (WSOPS). A single WSOPS consists of the following:

  • Receiving the SOAP request
  • Parsing the requst parameters and sanity-checking the values
  • Authenticating and authorizing the requester
  • Encrypting the sensitive data with a Data Encryption Key (DEK)
  • HMAC'ing the sensitive data with an HMAC key
  • Creating a token for the sensitive data
  • Saving and logging all information to the database
  • Logging the transaction in the appliance's server log
  • Assembling and responding to the client application

 

The High Performance KeyAppliance with a 16-core, 64-bit processor and 64GB of memory and Solid State Disks can perform appromixately eight hundred and fifty (850) WSOPS.

The KeyAppliance 2.0 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 KeyAppliance 2.0 with the correct authorization to get the original credit-card number, when needed.

The KeyAppliance 2.0 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 KeyAppliance 2.0 first and create a "Migration Authority Storage Key" (MASK). The setup of the Secondary KeyAppliance 2.0 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 KeyAppliance 2.0 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 KeyAppliance 2.0 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 KeyAppliance 2.0 appliance.

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

For instance, within the KeyAppliance 2.0 Model-T, the TPM generates a unique Storage Root Key (SRK) for each appliance, whichc onsists of a 2048-bit asymmetric key-pair. The KeyAppliance 2.0 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.

If you find another appliance with the same capabilities as the StrongAuth KeyAppliance 2.0 at a lower price, contact us with proof; we will give you one of our Model-T appliances for free! (You will be responsible for shipping, taxes and support costs, of course). Please note, that to use our single free appliance, you will need to buy at least one more appliance. Because of the way the KeyAppliance 2.0 is built for redundancy, it cannot be setup and used as a solitary machine - it must have the second appliance's master-key for replication before it will allow you to configure the first encryption domain. (While you may think that this is a low-down trick, we designed this for your own protection - honest!).

Client & Server Side Security

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 KeyAppliance 2.0 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 KeyAppliance 2.0 appliance. The recommended approach is to have the users using your Client 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 KeyAppliance 2.0 appliance.

The KeyAppliance 2.0 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 KeyAppliance 2.0.

On the server side, the KeyAppliance 2.0 uses a hardened Linux server for managing the security at the operating system layer. To protect the sensitive data and the cryptographic keys, the KeyAppliance 2.0 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 KeyAppliance 2.0 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 KeyAppliance 2.0 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 KeyAppliance, 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 KeyAppliance 2.0 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 KeyAppliance 2.0 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 KeyAppliance 2.0 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 KeyAppliance 2.0 appliance to authenticate them and set their PINs to activate the TPM.

The KeyAppliance 2.0 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.

KeyAppliance™ & HMAC (Hash Message Authentication Code)

A Hashed Message Authentication Code (HMAC) is a cryptographic artifact for determining the authenticity and integrity of a message object, using a symmetric key and a hash (message-digest). The HMAC can be based on message digest algorithms such as the MD5, SHA1, SHA256, etc. Possession of an HMAC value does not compromise the sensitive data as HMACs are not reversible artifacts.

The HMAC key in the appliance is a 256-bit key, and is used with the SHA256 hashing algorithm to create HMACs of sensitive data. The appliance automatically generates and uses a single symmetric HMAC key for a calendar year. It is used to generate HMACs for sensitive data sent to the appliance during that calendar year. This HMAC is stored in the database along with other meta-data and the ciphertext of the sensitive object.

When data is decrypted (based on a decryption request), the appliance regenerates a new HMAC with the decrypted data, using the HMAC key originally used during the encryption process, to determine if the data has not only been unmodified since it was last stored in the database, but to also determine if decryption process was successful. Without this test, the appliance would have no way of knowing if the encrypted object was modified/corrupted in the database.

No, it is not. The PCI-DSS regulation mandates that data-encryption keys be rotated at least once a year to mitigate risks. Additionally, Key-Encrypting-Keys (KEK) are also covered if the encrypted key is a Data-Encryption-Key (DEK). However, the regulation does not specify rules for any other type of key used in the key-management scheme. StrongAuth uses many keys in the system to protect the overall system, of which the HMAC key is one such key (other keys are described in Chapter 10, Key Management in the Reference documentation of the appliance).

This is to avoid any potential crypt-analysis using ciphertext (encrypted and/or HMAC'd data). While many assumptions made in today's cryptography technology are valid (HMAC's are not reversible; the probability of guessing the secret key used for HMACs, is neither increased nor decreased, based on the known HMAC value; etc.), prudence dictates that one does not put all of one's eggs in one basket. If the appliance never rotated the HMAC key, it would be difficult to predict the consequences of an advance in computing technology, on a key in use for many years. By rotating the HMAC key every year, the appliance mitigates some of this risk.

When the appliance generates an HMAC on sensitive data sent for encryption, it uses the HMAC value as a unique index in the database. Since the HMAC value depends on the key and the data, changing the key results in a different HMAC value for the same data.

On January 01 of each year, the appliance will automatically create a new HMAC key for use in the new year. So, if data was previously encrypted (and assigned a unique Token number based on the unique HMAC), the same data sent to the appliance for encryption in the new year will result in a new HMAC (because of the new key) and will be assigned a new Token number despite a duplicate existing in the appliance database under the old HMAC key.

While some customer applications may not care that similar sensitive data results in a different Token number (because decrypting either Token number will result in the correct sensitive data being sent back), applications dependent on tracking whether similar sensitive data is already in their database will not get the expected result.

For example, if credit card number 1234 5678 1234 5678 was encrypted in June 2010, it would have been HMAC'd with the HMAC key for 2010, and may have the Token number 9999 0000 0000 7643. If the HMAC values are not rotated on January 01, 2011, and credit card number 1234 5678 1234 5678 was sent to the appliance for encryption, because of the new HMAC key in 2011, the CCN will be assigned a new Token number – say 9999 0000 0512 4934 – because of the new HMAC value.

Regardless of which Token is sent to the appliance for decryption – either 9999 0000 0000 7643 or 9999 0000 0512 4934 – the appliance will send back 1234 5678 1234 5678 to authorized requesters.

If applications have no problem with this, then NOT rotating the HMAC on January 01 will not cause any problems. It will only cause additional records to be stored in the appliance for the same sensitive data. But, given the 300GB or so of free-space on the KeyAppliances, this will usually not be a problem for most sites.

As mentioned in the earlier response, sensitive data sent to the appliance after January 01 will be HMAC'd with a new key, potentially resulting in a second Token number for existing data. If the HMAC rotation job is executed at some point (using the DACTool), the module will generate an HMAC of all qualifying data with the new HMAC key and store the new HMAC against those objects.

However, where it finds that a given sensitive data item's HMAC already exists in the database (because the sensitive data was encrypted again after January 01 in some transaction), the rotation job skips modifying either the old or the new object and logs the duplicate record ID in the rotation-job report (written out in /usr/local/strongauth/strongkeylite/log directory of the appliance). Reviewing this log file is important to check for duplicates.

Since the log file can be huge (many millions of records), it may be easier to search for such duplicate records by “grep-ing” for them with the following command and piping them through the “less” command for pagination (substitute the actual name of the report below):

grep Duplicate | lessIf there are any duplicates, they'll be listed on the screen.

Depending on your application, you can choose to delete either one of the duplicate values in the appliance. The appliance provides a Deletion web-service that can be called by the application or by the strongkeyliteClient.jar tool bundled with the appliance (see Reference documentation for instructions). However, if you delete one of the objects from the appliance, your application may or may not need to know about the Token number that was deleted (it is assumed that customer applications are maintaining the unique Domain ID and Token number, as a reference to the original data on the appliance).

Alternatively, you can just leave the two Token values on the appliance if it does not matter to your application that a specific PAN has two different Token numbers. Regardless of which Token number is sent to the appliance for decryption, the correct PAN will be returned.

In the version 1.0 of the appliance (all Builds currently in use), the HMAC key is an “annual” key and will be changed automatically on January 01 each year. Whether a site chooses to rotate current HMAC values based on the new key depends on the applications and its business requirements. Customers can be assured that no matter which Token number is used for decryption – either the old or the new one – the correct corresponding sensitive data is always sent back to the application.

However, StrongAuth is evaluating different options for its upcoming release and may change this design to simplify this for customers. Should StrongAuth choose to do so, it will describe the new process in its Reference documentation and provide a smooth migration path.

While a lot depends on the sensitive data, the load on the machine, the number of Data Encryption Keys (DEK) in use, StrongAuth has bench-marked that the standard rack-mounted appliance, having one million records in the database, all encrypted by a single DEK, takes 10-12 minutes to rotate the HMACs for one million records after the job is started.

During the actual HMAC rotation job, the response time of the appliance will drop to approximately 50% of normal response time. Meaning, if the appliance was performing at the rate of 25-30 cryptographic web-service operations per second at steady-state, it will drop to 12-15 operations per second for the duration of the rotation job.

As was stated, your mileage will vary based on many factors. It is strongly recommended that you test your HMAC rotations on your TEST appliance before you perform them on your PROD appliances. If your TEST appliance is of a different kind than the PROD appliance, then you'll have to use it only as a rough estimate. StrongAuth currently supports two models of appliances, and they are both within 5 - 10% of each other in performance.

NOTE: you MUST execute this job on the Primary appliance to ensure that all Secondaries receive the updated HMACs through replication.

The default duration policy for Data Encryption Keys (DEK) is “daily”. This means that a new key is generated every day, upon the first encryption request past midnight. All transactions through midnight of the same date are encrypted with this DEK. While the duration policy can be changed to “weekly”, “monthly” or “annual” if desired, it is recommended that sites leave the policy at the default value – the appliance has the capacity to handle millions of symmetric keys, let alone 365 unique keys per year.

The appliance has a module that will automatically rotate DEKs in accordance with the PCI-DSS requirement. By default, this job is turned OFF, and must be activated by sites to kick off the automatic key-rotation process. Once again, by default, the job (when activated) will rotate keys that are 365 days old, and is configured to execute daily. This ensures that the appliance is only re-encrypting just one days' transactions every day of the year, thus, evening out the performance of the appliance throughout the year.

With version 1.0 of the appliance, this is true - unless you planned for it by migrating just a part of your millions of sensitive records one day at a time over a period of many weeks – probably unlikely :-). StrongAuth is committed to delivering a new module in its appliance in mid-2011, that will allow for “range-based” DEK rotation.

What this means is, if you have 10 million records that were encrypted in a batch job in one day in 2010, with the new rotation module, you will be able to specify a range of records – say 100,000 of the 10 million – on any given day and have those objects re-encrypted with the symmetric key of that day. Since you can do this at any time before the PCI-DSS deadline mandates it, you can spread the re-encryption process of the 10 million records across 100 days of the year (as an example). When the PCI deadline starts the key-rotation job on the appliance, only a fraction of the 10 million records will need to be re-encrypted each day. By spreading this load across the year, the appliance will perform better throughout the year as opposed to running into a wall once a year.

SKCE Module

About StrongKey CryptoEngine™ (SKCE)

The StrongKey CryptoEngine™ (SKCE) is free and open-source software (FOSS) product, written in the Java programming language. The software is bundled as a web-application archive (WAR) that can be deployed in the Glassfish Java application server. It presents a web-service that allows a calling application to encrypt or decrypt files of any size and of any type, and move the files to and from public cloud-storage services, or storage networks and file-systems, automatically. It is designed to allow you to leverage public-clouds for storage while securing the data in accordance with regulatory requirements.

Yes. Please contact us for further details.

The SKCE allows you to:

  • Use public clouds for storage, eliminating the need to lock-up capital in depreciating assets.
  • Encrypt sensitive data without having to worry about the mechanics of cryptography.
  • Use a proven key-management system to store and manage cryptographic keys.
  • Prove compliance to the encryption and key-management (EKM) part of PCI-DSS with little effort.
  • Use different public clouds for disaster recovery by storing multiple copies of encrypted files in AWS S3, Azure, Eucalyptus Walrus, etc.
  • Create a sophisticated and secure file-transfer scheme using public clouds to share data with partners, customers, branch-offices, etc.
  • NEW! Authenticate and authorize users for 1st factor (using LDAP or Active Directory) and 2nd factor with FIDO U2F protocol.

There are two parts to the StrongKey CryptoEngine™ web-application - the web-service module and the "core" module.

During an encryption process, the web-service module is responsible for:

  1. Receiving the web-service request from calling applications over SSL/TLS.
  2. Parsing and verifying request parameters.
  3. Authenticating the requester against the configured LDAP directory service (OpenDJ or AD).
  4. Determining their authorization to request the service.
  5. Creating a unique folder for the input file so multiple submissions of the same file from one or more applications don't clobber each other.
  6. Calling the "core" module to perform the cryptographic processing and,
  7. Moving the returned file to a specified (or configured) target location. If the target location is a public cloud storage service, the web-service module authenticates to the cloud-service using configured access key(s).

 

During encryption processing, the Core module is responsible for:

  1. Determining whether to use a new symmetric encryption key or a cached one.
  2. Generating a new symmetric encryption key (if needed) based on the configured/requested algorithm.
  3. Escrowing the symmetric key with a configured StrongAuth KeyApplianceTM (the code on SourceForge is configured to work with a DEMO appliance maintained by StrongAuth, Inc.; this can be changed in minutes to point to a different KeyAppliance if you have one on your network).
  4. Encrypting the plaintext (unencrypted) file while calculating a message-digest during the encryption process.
  5. Creating an XMLEncryption document containing cryptographic meta-data.
  6. Combining the XMLEncryption document and the ciphertext (encrypted) file into a single compressed ZIP file (with a file name containing a .XENC extension in it) and,
  7. Returning the XENC file to the calling application.

 

During decryption processing, the Core module is responsible for:

  1. Unzipping the XENC file to extract the XMLEncryption meta-data.
  2. Determining the required symmetric key, the location where it can be retrieved, the cryptographic algorithm used for the original encryption, etc. from the meta-data document.
  3. Retrieving the required symmetric key from a StrongAuth KeyApplianceTM at the specified URL in the meta-data.
  4. Decrypting the ciphertext file while calculating a message-digest during the decryption process.
  5. Verifying the plaintext (decrypted) file by matching up the meta-data digest with a newly calculated digest and,
  6. Returning the plaintext file to the calling application.

Platforms & Support

The SKCE has been tested on the following platforms. If you successfully use it on any other platform, post your configuration on the SKCE Open Discussion Forum.

Operating System

  • CentOS 6.X or 7.X 64-bit
  • Windows 7 Professional 64-bit

Java Development Kit

  • Sun/Oracle JDK 8 Update 72

Java Application Server

  • Glassfish 4.1

LDAP Directory

  • OpenDJ 2.5 Xpress1
  • Active Directory

NetBeans IDE

  • 8.0

The SKCE was built using the CentOS 7.1 64-bit distribution of Linux. However, since it is a Java application, it will, technically, run on any platform that supports Java. The SKCE was also tested on Windows 7 Professional Edition. It is likely to run on most versions of Linux, UNIX, Windows and, perhaps, even the OS/400.

The SKCE was built using the Sun/Oracle Java Development Kit 8 Update 72. However, it is likely to run with any update above 72. We have not tested it with OpenJDK; however, we plan to test it with Sun/Oracle JDK7 and the version of OpenJDK that ships with standard CentOS in the next few months. Once completed, we'll update the Supported Platforms section of this site.

The SKCE was built using the Glassfish 4.1 Application Server. Given that Java Enterprise Edition (JEE7) Application Server vendors have different ways of configuring their servers, it is unlikely that SKCE will work with another application server without major modifications to the configuration process. The code in the servlet and the core-module is likely to run without any modifications, but configuration changes to the application server are most likely necessary.

The SKCE was built using Netbeans IDE 8.0. The source code is also distributed as a Netbeans project. The project should be useable in the Eclipse IDE with a few tweaks for locating the dependent JARs.

The SKCE was tested against OpenDJ 2.5 Xpress1 edition and Active Directory running on Windows Server 2008 R2 for access control (authentication and authorization). The LDIF file in the distribution should work against almost all major LDAP Directory servers

However, we haven't had time to test the SKCE with anything other than what we've defined in the Supported Platforms section. If you are able to make it work on/with another platform, post a message in the SKCE Open Discussions Forum; your peers, and we, will definitely appreciate the confirmation as well as details.

The industry is awash with free and open-source software (FOSS) tools and libraries for encryption: BouncyCastle, GPG, JCE, Mozilla, OpenSSL, ZIP (and many more we're probably unaware of). While the tool-kits and libraries are very capable and useful, they were designed to solve problems in a specific way that doesn't address the kinds of problems the SKCE addresses. The SKCE is the first to combine features to address the need to use public clouds while proving compliance to data-security regulations when sensitive data is involved. It does this by shielding the application developer from:

  1. Low-level code required for cryptographic processing;
  2. Low-level code required to integrate with a key-management system;
  3. Low-level code necessary to communicate with multiple cloud service providers. If you do not have a need to use public or private clouds, you can still use the SKCE and store your encrypted files on local or network storage within your environment.

Combining these features and making it available as a web-service makes it possible to integrate legacy and newer internet-age applications to deliver a unique package of features to business users.