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.


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

More from Application Security

PixPirate: The Brazilian financial malware you can’t see

10 min read - Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme. PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Audio-jacking: Using generative AI to distort live audio transactions

7 min read - The rise of generative AI, including text-to-image, text-to-speech and large language models (LLMs), has significantly changed our work and personal lives. While these advancements offer many benefits, they have also presented new challenges and risks. Specifically, there has been an increase in threat actors who attempt to exploit large language models to create phishing emails and use generative AI, like fake voices, to scam people. We recently published research showcasing how adversaries could hypnotize LLMs to serve nefarious purposes simply…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today