Got Questions?

We figured you might.

We have spooled a few popular questions about StrongKey and the Tellaro™ and listed them below, but if you don’t see your question here, please don’t hesitate for a second to drop us a line.


Why do you call it the Tellaro?

As the story goes, on a stormy night in 1660, the town of Tellaro slept peacefully. The sea was so rough that no one expected danger to be fast approaching on the horizon. Though the seas raged, a band of pirates led by Rooster Arenzano forged through the storm in an all-out, surprise attempt to attack and loot the town of Tellaro that very night. The pirates, however, couldn’t account for all the things fate had in store for them on that stormy night. To their dismay, the seas were not the biggest adversary, but instead, something else lurking beneath its waters. As they neared the shore of the sleepy town, an enormous octopus climbed out of the water and up a church belfry to escape the turbulent seas. In its ascent, the great creature began to ring the bells. The citizens of Tellaro, recognizing the alarm, took to the streets to defend the village and drove off the pirate attack. After their victory, they looked upward at the church tower, eager to rally around their hero, expecting to find a fellow citizen or guard who had rung the bells. Instead, their gaze landed on a the massive octopus, the unexpected protector of all they held dear.

What happens if I lose my FIDO Security Key?

A neat thing about FIDO technology is that it enables the use of multiple security keys to access your account. You can have multiple keys registered to your account on the Tellaro, then put one on your key chain, the second in a locked drawer at home, and the third in the office, etc., as backups. Even if you lose one, you can always use a backup key to access your account, delete the electronic key associated with the lost physical key, and continue working with the backup key as your primary key. Replace the lost key with a new one and register it to your account.

Even if you lose all the keys to your account, StrongKey has a built-in two-step verification to send a PIN to your mobile phone or to an email address registered on the account. Using this PIN, you can register a new security key to your account.

Finally, the Tellaro Kit contains tamper-evident envelopes where your Tellaro Administrator’s Security Key (TASK) is stored; using the TASK, you can delete registered keys associated with your account and have the Tellaro administrator send you a new registration link for use with a new security key.

Can this protect against ransomware?

The StrongKey Tellaro leverages multiple technologies to protect you from ransomware:

  • FIDO strong authentication requires the use of a hardware token (inaccessible by remote attackers).
  • The FIDO protocol requires that the human attempting to authenticate to a web application is physically present in front of computer to satisfy FIDO’s “test of user presence” requirement in the protocol.
  • StrongKey has integrated the popular open-source MediaWiki software (which runs websites like with our FIDO Sign-On (FSO) web application to enable the use of FIDO strong authentication to access the wiki. If you were to install and use MediaWiki on one of your computers to store your content and files, ransomware would be unable to access, modify, and delete files on the wiki without the FIDO Security Key and the “test of user presence,” as mandated by FIDO protocols. This transactional security ensures that ransomware will be unable to harm StrongKey’s customers.

Why do I need to have a physical box?

StrongKey has learned — and believes — that your security must be anchored to something within your control. In the real world, the security of our safe deposit box is anchored in the bank’s security infrastructure and policies, while your control is established through contract and the physical possession of one of the two keys that can open the locker. Similarly, access to your bank account at an Automated Teller Machine (ATM) is established through the physical possession of an ATM bank card.

Tellaro’s security features rely upon the the cryptographic hardware module on the box combined with your possession of multiple Security Keys (even upon every reboot of the Tellaro; this security feature protects your data even if a Tellaro box is stolen from your premises — we do recommend keeping it out of sight in a safe location at the office).

StrongKey believes the cloud offers many benefits; but trusting the cloud with all your security would be similar to trusting the bank with both keys to your safe deposit box. This is the reason why the Tellaro was designed as an “on-premises” solution.

Okay, then what happens if my box dies?

Our solutions come in a “highly available (HA) kit.” This is a package of two duplicate boxes, such that if one goes down, the second is running a duplicate mirror of the first. Service is not lost, and StrongKey will replace the downed box within 24–48 business hours.  

Okay, but what if both of those boxes die? Say, my office catches on fire.

For the vast majority of our users, a high availability (HA) kit will suffice. For those who want the ultimate in backup, we recommend buying an additional node as part of the cluster and storing it in a place separate from a main office. This can be in a fireproof locker or at a home office. for example. The encrypted keys as well as encrypted data will be replicated to the StrongKey Cloud continuously and can be restored to the third, off-line node within hours of a disaster. Such Business Continuity capability has been available only to enterprises in the past, but is now available to SMBs through StrongKey.

How is this different from Dropbox?

Consider this analogy: Suppose you are working with a real estate agent to buy a new house. Upon closing on your house, your agent brings you a bottle of champagne to celebrate, as well as copies of your keys to let you into your place. But as she hands you the keys, she tells you that she’s also going to keep a copy of those keys. “Don’t worry — you can trust me,” she insists. But you know that someone out there has a duplicate of your keys, and could let herself in if she wished, let the police in if they pressured her, or lose those keys and have a criminal pick them up.

This is a rough approximation of what Dropbox does with your data. Yes, it may be encrypted, but the keys to unlock that encryption exist with Dropbox! If subpoenaed, they can turn over your data. Theoretically, their employees could look at your data. Dropbox could be hacked.

StrongKey is different because you—and only you—have control of your keys.

What kind of encryption does StrongKey use?

We encrypt data and documents with an AES 256-bit (this is a NIST-approved standard) symmetric key — which the industry calls a Data Encryption Key or DEK.

We encrypt the DEK with a RSA 2048-bit (this is also a NIST-approved standard) asymmetric key — this key is generally called a Key Encrypting Key or KEK.

We then protect the KEK with a RSA 2048-bit Master Key, which is generated and stored in a cryptographic hardware module — the TPM (or “Trusted Platform Module”). Currently, we are working with a Common Criteria (CC — a security standard agreed to by many OECD countries including the US) certified TPM, but in 2018, we expect to start shipping units that are not only Common Criteria certified, but are also US Federal Information Processing Standards (FIPS) certified TPMs.

To activate the TPM upon a restart of the appliance, it requires digital signatures from multiple Key Custodians. The digital signatures are created by RSA 2048-bit keys held in the custody of the Key Custodians. Without these keys that create the “activation digital signatures”, the box is useless (to a thief or attacker) — the TPM will not function. If it does not function, the Master Key cannot be used to decrypt the KEK, which in turn cannot be used to decrypt the DEK, which in turn cannot be used to decrypt the data or document.

Every document that is encrypted is also digitally signed using a Document Signing Key or DSK. The digital signature on the document ensures that its integrity is preserved and attacks cannot be carried out by modifying the metadata on the document to have the box decrypt a document for an unauthorized person.

So, while this scheme sounds complex, this is what allows our appliances to scale up to 50M keys for StubHub, while ensuring extremely high levels of security that satisfy Central Banks Security Officers and their auditors. This identical security—which has been in the enterprise appliance for the last 7–8 years—will be available to the SMB, in the Mini, at 1/10th the price of the enterprise appliance. That’s what makes it unprecedented.

KeyAppliance — KA Module (KAM)

About KeyAppliance

What comes in the box when I order a KeyAppliance™ 2.0?

A 2-socket, 2U rack-mountable server.

What software does the KeyAppliance™ 2.0 come with?

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

Is there a C/C++/C# client-library available with the KeyAppliance™ 2.0?

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.

How fast does the KeyAppliance™ 2.0 perform?

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) web service operations per second (WSOPS). A single WSOPS consists of the following:

  • Receiving the SOAP request
  • Parsing the request 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, 64GB of memory, and solid state disks — can perform approximately eight hundred and fifty (850) WSOPS.

How does the tokenization scheme work in the KeyAppliance™ 2.0?

The KeyAppliance 2.0 can tokenize anything — but it can return only numbers. The maximum size of the returned token can be up to 64-digits. If you need an alphanumeric 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 (EX: 16 digits for a credit card number) and set the starting value of the token (EX: 9999000000000001). For each unique credit card number received by the StrongKey Light Encryption System (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.

How does the KeyAppliance™ 2.0 handle failovers?

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—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 encrypted under the Primary.

During a failure, when the Primary fails, your Network Management tool detects the failure 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 up to the moment when the Primary failed, it can service any request of which the Primary was aware.

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.

How does the KeyAppliance™ 2.0 use a cryptographic hardware module?

[a name=”hardware_modules”]

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, which consists 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 between 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 encrypt all sensitive data in the appliance — are 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.

HSMs are used in a similar fashion.

What is the StrongAuth Guarantee?

If you find another appliance with the same capabilities as the StrongKey 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 can 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- and Server-Side Security

What kind of security is supported on the Client side when working with the KeyAppliance™ 2.0?

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 via Secure Socket Layer (SSL).

The only security you need to be concerned about is the username and password you will use to make web service requests of the KeyAppliance 2.0 appliance. The recommended approach is to have the users of your Client application provide a username and password before using the application, and then pass these as parameters into the web service request. This ensures that, to make web service requests, there is no sensitive information on the client side that must be maintained on the hard disk. 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 with Active Directory, any other LDAP Directory server, or use its internal database to manage users and their privileges within the KeyAppliance 2.0.

What kind of security is supported on the Server side of 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 hardware 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 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, then encrypts the MASK 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 during installation. 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 Active Directory, any other LDAP Directory server, or use its internal database to manage users and their privileges within the SKLES.

KeyAppliance and Hash Message Authentication Code (HMAC)

What is an HMAC?

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.

What is the HMAC key in the StrongKey appliance used for?

The HMAC key in the appliance is a 256-bit key 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 metadata 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.

Is the HMAC key covered by PCI DSS?

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. StrongKey uses many keys in the system to protect the overall system, of which the HMAC key is one (other keys are described in Chapter 10, Key Management, in the reference documentation of the appliance).

If the HMAC key is not covered by PCI DSS, why bother rotating it?

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 (HMACs 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.

What are the consequences of NOT rotating the HMAC key?

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 1st 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 1st 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.

What are the consequences of rotating the HMAC key well after January 01?

As mentioned in the earlier response, sensitive data sent to the appliance after January 1st 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 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 1st 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 the /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 | less 

If there are any duplicates, they will be listed on the screen.

How does one deal with the duplicates, if found?

Depending on the application, either one of the duplicate values in the appliance may be deleted. 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 one of the objects is deleted from the appliance, the 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, leave the two token values on the appliance if it does not matter to the 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.

Is this something that we have to do every year?

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 1st 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.

How long does this HMAC key rotation job take and what is the impact of this on the normal operations of the appliance?

While a lot depends on the sensitive data, the load on the machine, the number of Data Encryption Keys (DEK) in use, StrongKey has benchmarked 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; this means if the appliance was performing at the rate of 25–30 cryptographic web service operations per second at a steady state, it would drop to 12–15 operations per second for the duration of the rotation job.

As was stated, your response time 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. StrongKey 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.

How does all this affect the key rotation mandated by PCI DSS?

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 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 day’s transactions every day of the year; thus, leveling out the performance of the appliance throughout the year.

But, what about the millions of records we migrated when we bought the appliance? Won't that bog down the machine on the migration's anniversary date?

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. StrongKey is committed to delivering a new module in its appliance in mid-2011, that will allow for “range-based” DEK rotation.

This means 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.

KeyAppliance — SKCE Module

About StrongKey CryptoEngine (SKCE)

What is the 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.

Is there a support SLA available for the SKCE™?

Yes. Please contact us for further details.

What business benefits does the SKCE™ provide?

  • 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 PC -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

How does the SKCE™ work?

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.
  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 StrongKey KeyAppliance™ (the code on SourceForge is configured to work with a DEMO appliance maintained by StrongKey, Inc.; this can be changed in minutes to point to a different KeyAppliance at any time).
  4. Encrypting the plaintext (unencrypted) file while calculating a message digest during the encryption process.
  5. Creating an XMLEncryption document containing cryptographic metadata.
  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 metadata.
  2. Determining the required symmetric key, the location where it can be retrieved, and the cryptographic algorithm used for the original encryption, etc., from the metadata document.
  3. Retrieving the required symmetric key from a StrongKey KeyAppliance™ at the specified URL in the metadata.
  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.
  6. Returning the plaintext file to the calling application.

Platforms and Support

What platforms does SKCE™ 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

Can I use SKCE on/with another platform?

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. SKCE™ was also tested on Windows 7 Professional Edition. It is likely to run on most versions of Linux, UNIX, Windows, and perhaps even OS/400.

SKCE™ was also built using the Sun/Oracle Java Development Kit 8 Update 72. However, it is likely to run with any update above 72. It has not been tested 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.

SKCE™ was built using 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.

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

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

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.

Why should I use the SKCE when other FOSS tools are available?

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 of which we’re probably unaware). While the toolkits 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 SKCE addresses. 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 the following:

  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 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.