I am often asked about what policy and features can be assigned to an AES encryption key that is created by Alliance Key Manager, our encryption key management HSM. Simply put there are various options available at key level for each symmetric encryption key you create. This helps you line up with PCI-DSS, HIPAA/HITECH and other compliance regulations, as well as providing a well rounded security strategy for proper encryption key management. I wanted to give you a little bit of flavor of what some of these key options are so you can get a sense of the flexibility when it comes to key creation.
To get started, when creating a symmetric key, you assign it a user friendly name. This can be something as simple as ENCKEY_HR. This makes it easily identifiable from a management standpoint for what it's used for and for what group will be using it. And since these are AES keys we are creating, you'll be asked to specify what key size you wish to utilize for each individual key. Your options are 128 bit, 192 bit, and 256 bit keys. I normally recommend the 256-bit size as it is the strongest options available, but in all honesty, any size is adequately strong against any brute force attack it might come up against by a crafty hacker trying to decrypt your data
When creating keys, you’re allowed to set activation and expiration dates. This allows you to pre-create keys and to define a schedule as to when a key can be made available for use. You may want to have a policy where keys expires every few years and you revoke their use from users. If you're familiar with PCI requirements you'll know that you have to establish a crypto-period for your active encryption keys. When creating an encryption key you can specify how many days that key will be made available before it automatically rolls over into a new version of that key. The friendly key name you assigned to it at conception will never change, but behind the scenes you'll have a completely new instance of that key for use. Additionally, in an event where you suspect a data breach or need to roll a key manually, these options are available for you as well.
To provide an additional layer of security to who can have access to encryption keys, we provide a Key Access table that lets you lock down who or what groups can have access to which keys. There are varying levels of granularity that are made available for you in this area. For example, from a very unrestricted sense where anyone in your organization with an authorized TLS session to the server can request a key, all the way to the very strict policy where only specified users within specified groups can requests certain keys. These credentials are all set at the key level and are defined on the key requestor side within the distinguished name of the digital certificate they are using to connect to the key server and establish a secure link for key retrieval.
Additionally, keys have mirroring attributes that can be set at the key level to ensure you don't experience a business interruption by always having access to keys in the event of a network outage. I've seen customers never miss a beat when that unexpected outages occurs due to the fact that they have a hot failover standing by and ready to go. Also, to help add a level of detail to the keys you'll be creating, we provide sixteen different metadata fields for you specify details unique for each individual key. These fields enable you to easily track important details relevant to the key throughout its lifecycle.
Managing encryption keys with a Hardware Security Module (HSM) is the best way to ensure encrypted data remains secure. Learn how to easily store encryption keys separately from your encrypted data with a secure encryption key management HSM by visiting our Encryption Key Management Simplified Resources page.
