Databases are being encrypted more and more often these days, and there have been some recent cases in which a lack of encryption has caused a major data breach. Let’s say you’ve been using secure engineering practices and considered what-if scenarios at every step of your development process. Your Web application is hardened against cross-site scripting, SQL injections and a host of other common Web application vulnerabilities. You’ve looked over all the Open Web Application Security Project (OWASP) checklists, encrypted all data in transit and encrypted sensitive databases or fields in your database. But where are you storing the encryption keys for that database? Are you using a hardware security module (HSM)? Most organizations aren’t using HSMs to perform encryption with secure keys, but they should. Storing the key in plaintext or even obfuscated within the application is akin to leaving the key under the doormat.
Let’s back up a bit and look at the most common Web application architecture. In a typical Web application with database encryption, the keys are stored directly by the application somewhere on the application server. However, this leaves you open to reverse engineering attacks and creates operational security issues. However, with an HSM, you can avoid those issues.
What Is an HSM?
An HSM is essentially a co-processor. In terms of computer architecture, it may well have all the components of a Von Neumann machine — that is, storage, memory and processing capabilities. The point of an HSM, of course, is to provide dedicated encryption services that are offline from the host itself.
Since an HSM is dedicated to processing encryption and securing the encryption process, the server memory cannot be dumped to gain access to key data, users cannot see the keys in plaintext and you can ensure a trusted path exists between an application and the encrypted data elements. If you think you still can’t relax because someone else has physical access, you are wrong. HSMs have tamper-proof seals that prevent attackers from harvesting memory by means of electronic snooping or radio frequency monitoring.
What Does an HSM Guard Against?
HSMs protect against the theft of content from a sensitive database by a determined attacker. If an attacker gains privileged access to an application server where database keys are being stored in the clear, the keys can be retrieved. It doesn’t matter how well the key is obfuscated. Even if it is compiled, packed or otherwise convoluted, it could always be reverse engineered. Using this type of security is known as security through obscurity and is not a best practice from a secure engineering perspective.
From an operational security perspective, it is inadvisable to allow any human to see sensitive, unencrypted data. This includes not just the end users, but the development team, system administrators and database administrators. By extension, from a systems perspective, you also don’t want sensitive data being propagated from production servers to work stations, staging servers or development servers. If your database contains sensitive data, it is best not to let any human have access to the data in its unencrypted form.
How Is an HSM Implemented?
Because an HSM is typically deployed by an application development team, it falls under the application security domain as opposed to, say, infrastructure security. Hardware security modules can be used by applications to enforce a secure, trusted path. To implement one properly, applications must be built specifically to perform cryptographic operations using the application programming interfaces (APIs) provided by the HSM vendor. Those APIs include common cryptographic functions such as symmetric and asymmetric encryption and decryption operations, hashed message authentication code, cipher message authentication code, RSA, Digital Signature Algorithm, Diffie-Hellman, random number generation, prime number generation and format-preserving generation. HSM APIs may be either vendor-specific, such as IBM’s Common Cryptographic Architecture, or follow an open standard, such as PKCS No. 11. Obviously, one would need to do some careful shopping to ensure the appropriate functions are available, in addition to standard architecture considerations such as the hardware/OS platform and language support.
Compliance
While HSMs are not mandated for PCI compliance, they are used by most payment schemes. The current governing standard for HSMs is called FIPS-140-2 and comes from the National Institute of Standards and Technology. Practically speaking, if you are storing credit card data, you really should be using an HSM. The PCI security requirements from 2009 can be found here, and the update from 2012 can be found here.
While FIPS-140-2 HSMs are widely used in the payment industry, they can dramatically improve the security of your database regardless of your industry. Remember, your medical records are worth more to cybercriminals than your credit cards, so get busy.
How to Get Started With Encryption
Luckily, there exists a clearinghouse for certified HSM products. There are many other discussion topics around hardware security models, including network-based modules specifically for storage systems and other custom designs. However, this article is intended to be a high-level introduction to hardware security modules, and I encourage you to do some further reading from the SANS Institute and Stack Exchange.
Image Source: iStock