The Great Pyramids of Giza in Egypt are probably the first safes ever constructed. They were built as tributes to and the final resting place of three Egyptian pharaohs. They had very complicated locking mechanisms that didn’t work since sometime between 2500 BC and the 18th century, their contents were removed. Still, you have to give the Egyptians credit for being the first to create a workable safe. Fast forward to the 1800s and the first combination lock safe was invented. In any case, a safe is designed to secure something of physical value so that only authorized people can and unauthorized people can’t access its contents.
Jump ahead to the late 20th century and the advent of securing digital information so that only authorized people can access the information. It wasn’t a stretch to use the analogy of a safe to conjure up an image that everyone could understand. Hardware Security Modules (HSMs) and safes have had a shared vision from the start. Early HSMs took this analogy to heart by using physical keys in locks to secure the digital contents.
Early on, technologists should have divorced themselves from the “safe” analogy but due to its ease of description to the accountants, most kept propagating this image. In reality, a safe and an HSM are very different and only a discussion of the differences (in order to discredit the analogy) should be addressed.
As stated earlier, a safe is designed to secure something of value so that the owner of the item knows where it is at all times and can take comfort that it’s not being stolen. A safe is very binary: an item is inside the safe and therefore secure OR the item is outside the safe. Once the item is outside the safe, the safe plays no additional role in its security.
An HSM is a complicated piece of technology that performs two basic functions: it creates cryptographic elements through complex mathematical equations involving large prime numbers, modal properties and random numbers. Once these cryptographic elements are created, the HSM then provides the mechanism (working with other applications like SQL, Oracle, Microsoft, etc.) to use these elements. The use of these elements does include the protection of the keys but not the storage of same. This single sentence demonstrates the difference between a safe and an HSM. Storage is binary, protection is non-binary.
If we were to examine the physical safe analogy in a logical world, the safe would be opening and closing multiple times every second. For a hacker, less than a second of vulnerability is all they need to wreak havoc on a corporation’s data. See the problem? This is why an HSM should be more considered a safe place to perform crypto functions.
An HSM is far from binary. Contents of an HSM are stored inside the HSM, used by applications inside the HSM, used by applications outside the HSM, modified within the HSM, extracted from the HSM, created inside the HSM and a long list of other very complicated tasks. And unlike a safe, an HSM is also designed to secure its contents when the item is outside the HSM. Even the Egyptians didn’t think of that one. With all that an HSM must do, comparing an HSM to a safe simply isn’t valid.
It is because this analogy isn’t valid that any discussion whereby an HSM’s security is defined simply by its key storage within the HSM is overly simplistic to the complexities of its intended use. Crypto is complicated and those trying to use it are constantly trying to find ways of simplifying the discussion, especially to the people writing the check. Many of the simplified analogies used when explaining crypto are quite acceptable but the simplification of an HSM to a thick steel box with a large handle, spinning dials and stainless steel bolts is only serving to minimize or marginalize the HSM’s important role in an effective security solution.
Please click here to learn more about Entrust’s products.
