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.
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.
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.
A neat thing about Fast Identity Online (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 Personal Identification Number (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.
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.
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 a single-tenant appliance solution.
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 the premises). The single-tenant appliance can be kept somewhere discreet in your office, or hosted virtually through StrongKey or another data center. Either way, with only you having access to the security keys, the data on your Tellaro cannot be compromised.
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.
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 small- to mid-sized businesses (SMBs) through StrongKey.
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 cloud providers do with your data. Yes, it may be encrypted, but the keys to unlock that encryption exist within their cloud! If subpoenaed, they can turn over your data. Theoretically, their employees could look at your data. The provider could be hacked.
StrongKey is different because you—and only you—have control of your keys.
We encrypt data and documents with an Advanced Encryption Standard (AES) 256-bit (this is a National Institute of Standards and Technology (NIST)-approved standard) symmetric key — which the industry calls a Data Encryption Key (DEK).
We encrypt the DEK with a Rivest–Shamir–Adleman (RSA) 2048-bit (this is also a NIST-approved standard) asymmetric key — this key is generally called a Key Encrypting Key (KEK).
We then protect the KEK with a RSA 2048-bit Master Key, which is generated and stored in a cryptographic hardware module — the Trusted Platform Module (TPM). Currently, we are working with a Common Criteria (CC — a security standard agreed to by many Organisation for Economic Co-operation and Development (OECD) countries including the US)-certified TPM, but in 2019, we expect to start shipping units that are not only CC-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 (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.
While this scheme sounds complex, this is what allows our appliances to scale up to 50M keys, while ensuring extremely high levels of security that satisfy Central Banks Security Officers and their auditors.
Without taking network latency into account, when tested with multi-threaded clients, the T-Series (with an eight-core, 64-bit processor, 8 GB 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 Simple Object Access Protocol (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)
HMACing 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 E-Series, with a 16-core, 64-bit processor, 64 GB of memory, and solid state disks, can perform approximately eight hundred and fifty (850) WSOPS.
The Tellaro 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 StrongKey encryption, 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 Tellaro with the correct authorization to get the original credit card number, when needed.
Cryptographic hardware modules — such as the Trusted Platform Module (TPM) and the Hardware Security Module (HSM) — are used by the Tellaro to protect the cryptographic keys within the appliance.
For instance, within the Tellaro, the FIPS 140-2 Level 2-certified TPM generates a unique Storage Root Key (SRK) for each appliance, which consists of a 2048-bit asymmetric key pair. The Tellaro 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, but are only available in the E-Series.
Yes, we do have a client application in C# and Managed C++. However, the Tellaro ships with a Java client library and a sample application that can be readily modified for use by customers.
Tellaros come with the following software:
64-bit Linux Operating System
Payara Application Server
MariaDB Relational Database
StrongKey Encryption System
A 2-socket, 2U rack-mountable server.
With a 16-core, 64-bit processor, 64 GB of memory, and solid state disks, the E-Series can perform approximately eight hundred and fifty (850) WSOPS.
The Tellaro is designed to work with a minimum of two appliances. In the installation and setup—which takes between 2–4 hours—the primary appliance is set up first and a Migration Authority Storage Key (MASK) is created. The setup of the secondary appliance 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 appliance. 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 appliances in the picture, allowing for 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 StrongKey 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 Tellaro appliance.
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 Tellaro 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 Tellaro 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 Secure Socket Layer (SSL) authentication on the Tellaro.
Our appliances can be integrated with Active Directory (AD), any other LDAP directory server, or use its internal database to manage users and their privileges within the Tellaro.
On the server side, the Tellaro uses a hardened Linux server for managing the security at the operating system layer. To protect the sensitive data and the cryptographic keys, our appliance uses a hardware cryptographic module — such as a Trusted Platform Module (TPM) or a Hardware Security Module (HSM) — to protect the key chain.
The TPM, for example, generates a Storage Root Key (SRK) which never leaves the TPM chip. Since the FIPS 140-2 Level 2-certified TPM is soldered to the motherboard of the server, the TPM cannot be extracted and compromised by itself. The Tellaro 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 Tellaro 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 (KCs) 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 Tellaro, which verifies the signature and then sets their part of the Personal Identification Number (PIN) to activate the TPM. Once all three KCs have set their PINs, the TPM is activated and the Tellaro 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 Tellaro 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 with the appliance 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 appliance will communicate securely over SSL with the Tellaro to authenticate them and set their PINs to activate the TPM.
The Tellaro appliance can be integrated into Active Directory (AD), any other LDAP Directory server, or use its internal database to manage users and their privileges within the appliance.
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 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 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 the 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 Payment Card Industry Data Security Standards (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 to protect the overall system, of which the HMAC key is one (other keys are described in Chapter 15, KAM Key Management, in the SAKA Administration Guide documentation of the appliance).
This is to avoid any potential cryptanalysis using ciphertext (encrypted and/or HMACed 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 advances 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 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 2018, it would have been HMACed with the HMAC key for 2018, and may have the token number 9999 0000 0000 7643. If the HMAC values are not rotated on January 01, 2019, and credit card number 1234 5678 1234 5678 is sent to the appliance for encryption, because of the new HMAC key in 2019, 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 January1st 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 free space on the appliances, this will usually not be a problem for most sites.
As mentioned in the earlier response, sensitive data sent to the appliance after January 1st will be HMACed 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 January1st 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.
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 the SAKA Administration Guide 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 Primary Account Number (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 current Tellaro, 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.
While a lot depends on the sensitive data, the load on the machine, and 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 WSOPS at a steady state, it would drop to 12–15 WSOPS 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.
The default duration policy for Data Encryption Keys (DEKs) 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.
StrongKey’s Tellaro appliance allows for “range-based” DEK rotation.
This means if you have 10 million records that were encrypted in a batch job in one day in 2018, 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.
The StrongKey file encryption solution is a 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 Payara application server. It presents a web service that allows a calling application to encrypt or decrypt files of any size or type, and automatically move the files to and from public cloud storage services or storage networks and file systems. It is designed to allow leveraging of public clouds for storage while securing the data in accordance with regulatory requirements.
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 Amazon Web Services (AWS) Simple Storage Service (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 Universal 2nd Factor (U2F) protocol (WebAuthn in progress)
There are two parts to the StrongKey file encryption web application — the web service module and the core module.
During an encryption process, the web service module is responsible for:
Receiving the web service request from calling applications over SSL/TLS.
Parsing and verifying request parameters.
Authenticating the requester against the configured LDAP directory service (OpenDJ or AD).
Determining their authorization to request the service.
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.
Calling the core module to perform the cryptographic processing.
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:
Determining whether to use a new symmetric encryption key or a cached one.
Generating a new symmetric encryption key (if needed) based on the configured/requested algorithm.
Escrowing the symmetric key with a configured StrongKey Tellaro.
Encrypting the plaintext (unencrypted) file while calculating a message digest during the encryption process.
Creating an XML Encryption (.XENC) document containing cryptographic metadata.
Combining the .XENC document and the ciphertext (encrypted) file into a single compressed .ZIP file (with a file name containing a .XENC extension in it).
Returning the .XENC file to the calling application.
During decryption processing, the core module is responsible for:
Unzipping the .XENC file to extract the XML Encryption metadata.
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.
Retrieving the required symmetric key from a Tellaro at the specified URL in the metadata.
Decrypting the ciphertext file while calculating a message digest during the decryption process.
Verifying the plaintext (decrypted) file by matching up the meta data digest with a newly calculated digest.
Returning the plaintext file to the calling application.
Our file encryption application has been tested on the following platforms (as of 11 Feb 2019).
CentOS 7.x 64-bit
MariaDB 10.2.13 for Linux, 64-bit
Sun/Oracle JDK 8 Update 181
Microsoft Active Directory for Windows 2008
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 breadth of problems StrongKey addresses. StrongKey is the first to combine file encryption 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:
Low-level code required for cryptographic processing.
Low-level code required to integrate with a key management system.
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 StrongKey’s file encryption 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 internet-age applications to deliver a unique package of features to business users.
StrongKey offers two support tiers to help ensure our customers are able to access help when and how they need it. The first tier is a Monday through Friday, 9am–5pm PST support service that includes direct access to our support engineers at any time during that window. The second tier is 24×7 support access, to give customers peace of mind that they have someone available to call no matter what.