Following my publication of a the design for Personal Data Protection in a database , I have received emails asking to elaborate on the proper protection of Secure Keys in the infrastructure.
I'll describe it through the following example:
You want to secure some information, therefore you encrypt it. The encrypted data is stored on some computer readable/writable media. For the entire excercise to be useably fast the actual encryption and decryption is done through a computer program, residing on a general purpose computer. This program needs a decryption key in order to recover the data into a useable form.
If you need the encrypted data only for archival purposes, and acces it only very infrequently, you can set up a situation where you have an isolated (non-networked) computer system in a secure room, doing the encryption and decryption and keep the key in a separate vault in a sealed tamper-evident envelope. When the time for decryption comes, an authorized person opens the vault, breaks the seal on the envelope and types in the key in the decryption program.
But in a more realistic situation, the encrypted data will be needed on a daily basis, so it will probably be kept inside a database or a file on the computer. This computer will need to be networked, and some form of server application will be responsible for decrypting and presenting the data to the user. In this scenario, having the decryption key in a vault serves little purpose, since someone will need to type it in at least several times per hour. So, the solution would be to keep the key somewhere inside the computer. Here's the catch: Any secret kept within a computer is actually very very insecure. It is kept in a file on the file system, or in RAM memory. Both locations are accessible at least to all administrators and can easily become subject to a hacker intrusion. Encrypting the key does not improve things since again, there is a decryption key which is available in cleartext. The image below presents a computer system in which the secret key is stored in RAM or HDD. Both are fully accessible by the OS, and can be dumped to be analyzed and the secret key can be retreived.
What is needed is a way to have the key in a safe location, but to be able to obtain it's services for decryption at speeds at which the computer operates. So, we need a tamper evident and secure vault inside the computer. This is the role of the Hardware Security Module (HSM). The HSM is a hardware device which protects its content, and never reveals the content in an unencrypted form to the host computer, and the host computer cannot access and address any of the storage memory of the HSM. If any form of attempt to tamper the HSM is detected, it can be logged or the HSM can self-destruct the secure contents, depending on the security level of the HSM.
The HSM provides services through an API to generate and import secret keys and to encrypt/decrupt data with those keys. The image below presents a computer system in which the secret key is stored in the protected HSM memory. The OS can request a service of decryption of some data, but the secret key is never directly accessible
The HSM modules come in a form of a PCI card or an external device which connects via USB/SCSI/RS232 interface
It's physical tamper resistance is assigned as a level of FIPS-140-2 validation, with levels 1 to 4
- Level 1 - Imposes very few requirements. In general, all components must be "production-grade" and various obvious kinds of insecurity must be absent.
- Level 2 - Imposes Level 1 requirements and adds requirement for physical tamper-evidence and role-based authentication.
- Level 3 - Imposes Level 2 requirements and adds requirement for physical tamper-resistance, identity-based authentication, and a physical or logical separation between the interfaces by which "critical security parameters" enter and leave the module, and its other interfaces.
- Level 4 - Imposes Level 3 requirements byt adds more stringent physical security requirements as well as robustness against environmental attacks.
Personal Data Protection - Anonymizing John Doe
NIST Validation lists
Talk back and comments are most welcome