Key Management for Enterprise Data Encryption
by Ulf Mattsson - CTO of Protegrity - Monday, 10 December 2007.
Key domains for protection and easier management

A mature data encryption solution should support the concept of key domains which can isolate different systems for security reasons or operational needs. Each key domain may have different security exposures and can have a different policy for how keys should be managed including key generation, key rotation and protection of key material. It should support transparent re-encryption of the data when it flows between systems that are using different encryption keys or different algorithms. The Key Management System must support multiple levels of keys to ensure that the encryption keys that protect secret and confidential data cannot be compromised. This enables the use of different encryption keys for different columns, tables and files. When setting policy, it is important to configure the use of different encryption keys and initialization vectors across different columns, tables and files to maintain compartmentalization and a diverse front against attack. The Keys should be stored in an Enforcement Agent that supports dual control (requiring more than a single administrator/operator) for key recovery. It may be implemented in hardware or software, but it must support both the encryption and integrity of the key backup format.

Annual review of algorithms and key lengths

The Key Management System must support key length or strength of 128-bits or greater for symmetric keys. Such keys are deemed “strong encryption” and are not susceptible to a brute force attack using current technology. Public or asymmetric keys must be of equivalent strength. That is, a 128-bit symmetric key and 3072-bit public key are considered to be equivalent in terms of strength, while a 15,360-bit public key is equivalent to a 256-bit symmetric key. The data encryption should be performed with strong standard algorithms including 3DES, AES 128 or AES 256. Data requiring protection for longer periods of time should use the longer key lengths. Note that adequate CPU power today may not be enough tomorrow as you incorporate more secure communications. It is wise to establish a key-length policy early and review it annually.

Secure generation and distribution of keys

The Key Management System must generate a unique key for each file, tape, or other data element that needs to be encrypted. Private keys must be generated within the secure confines of the Key Management System and never be transferred outside the Key Management System unless encrypted with a Key Encryption Key. All keys should be centrally generated in software or hardware based on the security class for the type of data they protect. The key management system must be able to electronically transfer private keys to other trusted key repositories throughout the enterprise. This may also be implemented via Smart Cards. The security policy should define where different keys should be stored and cached. The master keys are used to encrypt all operational keys that should be stored in cipher text in separated databases. Security metadata and operational encryption keys should be kept in cipher text (even when stored in memory) until needed for use by crypto-services routines. All communication both external and internal is encrypted. All Data Protection System services should be using X.509 certificates and SSL for secure distribution of encryption keys. Unique keys should be generated for each Enforcement Agent, and should be used when sending information between system components. The data encryption method should be based on different encryption keys for different columns, tables, files and directories. An optimal design for Hardware Security Module support can be based on an optimal combination of hardware and software keys. Supported Hardware Security Module should be tamper evident and compliant with FIPS PUB 140-2 Level 3 Security Requirements for Cryptographic Modules, and keys are randomly generated in compliance with ANS X9.24 Section 7.4.

Spotlight

Lessons learned developing Lynis, an open source security auditing tool

Posted on 15 October 2014.  |  Lynis unearths vulnerabilities, configuration errors, and provides tips for system hardening. It is written in shell script, installation is not required and can be performed with a privileged or non-privileged account.


Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.
  



Daily digest

Receive a daily digest of the latest security news.
  

DON'T
MISS

Mon, Oct 20th
    COPYRIGHT 1998-2014 BY HELP NET SECURITY.   // READ OUR PRIVACY POLICY // ABOUT US // ADVERTISE //