News
Secure Encryption key lifecycle management
October 2008 by Ulf Mattsson, CTO, Protegrity Corporation
One of the essential components of encryption that is often overlooked is key management - the way cryptographic keys are generated and managed throughout their life. Because cryptography is based on keys that encrypt and decrypt data, your database protection solution is only as good as the protection of your keys. Security depends on two factors:
• Where are the keys stored and
• Who has access to them?
When evaluating a data privacy solution, it is essential to include the ability to securely generate and manage keys. This can be achieved by centralizing all key management tasks on a single platform, and effectively automating administrative key management tasks, providing both operational efficiency and reduced management costs. Data privacy solutions should also include an automated and secure mechanism for key rotation, replication, and backup.
ADMINISTRATORS SHOULD NOT HAVE ACCESS TO THE KEYS
One easy solution is to store the keys in a restricted database table or file. But, all administrators with privileged access could also access these keys, decrypt any data within your system, and then cover their tracks. Your database security in such a situation is based not on industry best practice, but on an honor code with your employees. If your human resources department locks employee records in filing cabinets where one person is ultimately responsible for the keys, shouldn’t similar precautions be taken to protect this same information in its electronic format?
ENCRYPTION KEYS SHOULD NEVER BE EXPOSED IN CLEAR FORM
Encryption keys should never be exposed in clear form. Encryption keys should be protected and encrypted when stored in memory or databases, and during transport between systems and system processes. The use of a combination of software cryptography and specialized cryptographic chipsets, HSM, can provide a selective added level of protection, and help to balance security, cost, and performance needs. Certain fields in a database require a stronger level of encryption, and a higher level of protection for associated encryption keys.
ACCESS TO KEY MANAGEMENT FUNCTIONS SHOULD REQUIRE SEPARATE AUTHENTICATION
Access to central key management functions should require a separate and optional strong authentication and management of encryption keys should be logged in an evidence-quality audit system. Keys stored in the HSM are protected from physical attacks and cannot be compromised even by stealing the HSM itself. Any attempt to tamper with or probe the card will result in the immediate destruction of all private key data, making it virtually impossible for either external or internal hackers to access this vital information.
A HIGH LEVEL OF SECURITY AND A COST EFFECTIVE SOLUTION
To maintain a high level of security the end-point server platform should only cache encrypted lower level data encryption keys. Key encryption keys should always be stored encrypted on separated platforms. A central server with a hardened standard computing platform to store the keys can provide a cost effective solution in some environments.
PAYMENT CARD INDUSTRY (PCI) REQUIREMENTS
PCI DSS version defines requirements for the key management facilities. FIPS 140-2 Level 3 cryptographic hardware is not required, but section 3.5.2 in the PCI audit testing procedure states separation requirements between different keys: ‘Examine system configuration files to verify that cryptographic keys are stored in encrypted format and that key-encrypting keys are stored separately from data-encrypting keys.
A SCALABLE AND ROBUST ARCHITECTURE FOR KEY MANAGEMENT
Defiance Key lifecycle management helps enable companies to meet the key management guidelines required under the PCI data security standard and it includes policy-based key generation, retrieval, expiration, caching, archival and restoration, as well as audit logging, and secure and scalable architecture. Defiance Key lifecycle management is a scalable and robust architecture allows centralized management across multiple locations and end-points. It also includes failover and high-availability features to help ensure maximum uptime for mission-critical applications requiring access. Defiance key-store is compliant to PCI 1.1 and divided in multiple and separated data stores for storage of cryptographic keys. All keys are stored in encrypted form—encrypted using several layers of key encryption keys (KEK). The optional hardware security module (HSM)1 is a specialized, secure hardware device for storage of the KEK. The Defiance Security Manager ensures that administrators are properly authenticated and authorized to perform Key Management operations.
EFFECTIVE PROTECTION OF MEMORY CACHED KEYS
Memory attacks may be theoretical, but cryptographic keys, unlike most other data in a computer memory, are random. Looking through memory structures for random data is very likely to reveal key material. Well made libraries for use as Native Encryption Services go to great efforts to protect keys even in memory. Key-encryption keys are used to encrypt the key while it is in memory and then the encrypted key is split into several parts and spread throughout the memory space. Decoy structures might be created that look like valid key material. Memory holding the key is quickly zeroed as soon as the cryptographic operation is finished. These techniques reduce the risk of memory attacks. Separate encryption can also be used for different data. These encryption keys can be automatically rotated based on the sensitivity of the protected data. Dedicated Encryption Services are also vulnerable to memory attacks. However, a well made Dedicated Encryption Service runs only the minimal number of services. Since web servers, application servers, and databases have no place on a dedicated cryptographic engine, these common attack points aren’t a threat. This severely constrained attack surface makes it much more difficult to gain the access needed to launch a memory attack. To maintain a high level of security backups contain the encrypted data and only securely encrypted lower level keys. Master keys should be backed up separately.
SECURE KEY BACK UP
A weak link in the security of many networks is the backup process. Often, private keys and certificates are archived unprotected along with configuration data from the backend servers. The backup key file may be stored in clear text or protected only by an administrative password. This password is often chosen poorly and/or shared between operators. To take advantage of this weak protection mechanism, hackers can simply launch a dictionary attack (a series of educated guesses based on dictionary words) to obtain private keys and associated certificates.
