Key Management System - Required features for network elements' security

Every network element in Enterprise network requires access to security keys at some time or other.  Mobiles, laptops typically have security keys for securing emails,  for storing the confidential data and for backingup the data in remote locations.  Servers in data centers have private keys and certificates for providing authentication credentials to external users.  Network infrastructure devices also require symmetric keys for storing the data securely in file system, private/public key pairs and certificates to provide authentication credentials to remote VPN users etc..   Key Management Server provides a central mechanism to store the keys and retrieve the keys on demand basis.  

PCI (Payment Card Industry) standard specifically requires that keys are not stored in the network elements' persistent memory.   It is expected that the keys are downloaded every time that element is powered up.  It is also expected that the keys downloaded are kept in temporary memory which would get erased when power is off.  In case of battery powered devices, they are expected to be stored in Hardware Security Modules (HSM).  This mechanism would protect the data when the media or device is stolen.

Centralization of  all key management operations  gives control for Enterprises to manage the life cycle of keys. This kind of control is required now more than before due to cloud computing and smart phones. As we all know, Cloud computing allows Enterprises to rent VMs on demand basis.  Virtual appliances are typically installed on the VMs.  Since these rented VMs are hosted in Cloud computing providers' data centers,  Enterprises would like to ensure that the not only data, but also keys are secure.  Having Key Management Server within Enterprise trusted boundary would ensure that administrator to do Key management operations such as Revoke (expire), key rotation.   When VM is no longer required, all keys associated with the VM can be either revoked or archived.  This kind of control also helps to revoke the keys in case of VM break-in. 

What are the devices and applications that require keys and Key Life cycle management:


End network elements such as laptops, desktops and smartphones :  

• Secure Email :  PGP  is normally used to secure the emails on the wire.  PGP requires private key/public key or certificates to secure the emails.
• Crypto file systems :  These storage systems (within laptop or on dedicated remote file systems) are used to secure the confidential information.
• Data backup :  Backup data should be secured and only can be decrypted by user.
• IPsec VPN Client

Servers and Network infrastructure devices:

• HTTP Servers/SIP Servers/other SSL based Servers:  
• SSL based proxy applications such as Network Anti Virus,  SSL VPN,  Management Servers such as HTTPS,  SSH etc..
• Crypto file systems to store the confidential data.
• IPsec VPN Servers

Centralized Key Management consists of two components - Key Management Server and Clients.  Typically there would be one key management server and as many clients as number of network elements requiring centralized keys. 

Generic requirements of Key Management Server:

• It is expected to provide storage of different types of keys.  Some applications generate keys on their own and store the keys in Key Management Server.  Some applications expect Key Management Server to create and store the keys.
• Private key,  public key or certificate and certificate chain.  
• Symmetric key.
• Get Operation : Key Management Server is expected to serve the keys to the clients requesting.  
• Get Attributes:  This operation is expected to be provided by Key Management Server to provide different attributes associated with the key.  Keys are not served as part of this operation.
• Back up of keys in case of any trouble in Key Management Server :  There are two operations are expected - Export and Import.  Export is to backup the keys from the Key management server and import is to get the keys from backup. 
• Key Expiry : Expiring the keys -  Typically keys are rotated every 1 or 2 years.  Some times, expiry of keys need to be done in case of key compromise.
• Key rotation :  As part of expiring the keys,  it is required to create new key to replace the old key.  To ensure the continuity of applications, both keys may need to be active for some time (overlap time).  During overlap time, old key is typically used for 'process' operation (decryption). New keys is used for both protect and process operations. 
• Archive of keys:  Once the key is expired,  it can be archived.  Archiving is different from backup.  Backup of keys is done on active keys and archiving is done on the inactive keys.  Resume operations is expected to be provided in case keys need to re-activated. 
• Deletion of keys:  Once the keys are determined that they are no longer required,  deletion operation can be done. Typically deletion happens after few years after it is archived. This is to ensure that there is no useful data that was encrypted using the keys that are targeted for delete operation.
• Key Management Client and Server communication must be secure (SSL is one option).  KMS is expected to have scalability to support large enterprises. 
• Network Element (Device) registration :  A device might have multiple applications requiring Key Management facilities.  If the device is stolen, all the keys of all applications in the device need to be revoked.  Revocation might involve actively communicating with the device and also to communicate with other devices using same keys or some parts of the keys.  To facilitate this,  key management server is expected to provide revoke operation on all keys correspond to the device.  KMS is expected to provide facilities to register the devices, revoke all keys on a device and deregister the devices.   There could be many devices that exist in the Enterprise.  It may be expensive for IT to register the devices.  There should be facilities for Key Management client on the device to auto register the device if it does not exist in the KMS.  KMS is also expected to provide control for users to revoke the keys on the device.  That is, if laptop or smart phone is stolen, user itself can go to KMS and revoke the keys rather than depending on the IT to do which may take longer and it is possible for thief to get hold of data in between.
• Binding among the keys:  
•  In public key cryptography,  pair of keys are required together - Private and public key pair. Yet times, certificate chain is also required along with this pair of keys.  Any key management operation is typically done on these keys together.  That is, when the key is revoked, its counterpart is also expected to be revoked. This binding is 'peer binding'. 
• There is another kind of binding -  Key derivation binding.  Here the binding parent-child binding. Some operations on the parent are applied on the derived keys.  Actions on derived keys may not have any affect on the parent key. 
• Some times keys are used for wrapping and unwrapping the other keys.  This is normally used in export and import operations.  When keys are exported,  keys are encrypted using wrap key.  As part of import operations, keys are unwrapped using wrap key. For lack of better term, let me call this as 'wrap binding'.
• Key deployment in clients:
• Key Management Systems are expected to provide the keys requested by the clients as long as ACL rules allow it to do.  
• Yet times,  multiple objects may be retried by the clients together.  Key Management System should provide mechanism to bind the objects and get the all the objects corresponding to that binding. Private/Public key and certificates retrieval is one example.
• When new keys are created or registered by one client,  it is needed that these keys are deployed on other systems (clients).  There are two common cases:
• VPN Server creating or registering the keys:  Public key and certificate objects are expected to be installed on all known VPN clients.  How does KMS know the devices to install the keys to?  KMS can take 'application registration'  in this case. This is in addition to Device registration. VPN Server as part of installing the keys in KMS can indicate the 'application Identification' of the clients and also indicate the keys that need to be installed. KMS can use this information to find out devices from the device/application registrations and deploy the keys in those devices and application.
• Cluster of Servers :  In Enterprise, multiple servers are used to serve the content. These servers share the load among them.  It is necessary that keys used are same across all servers. Even one server registers the keys, all keys need to be deployed in all other servers in the cluster.  KMS is expected to allow KM clients to indicate the information so that it can deploy keys to all other servers.  Again device and application registration facility allows this.
• Access Control List: Access Control list play very important role in providing control for IT departments to do key management operations. It provides control for trusted users to do key management operations - Create/Register,  Backup, Revoke,  Key Rotation,  Archive, Delete, Get, Get Attributes - by associating user groups to permissions (key management operations).  Each ACL rule is really a combination of 'User group' and 'Permissions' on a given key object. It is normally accepted in the industry to create the ACL rules as part of creation/registration of keys.   If the creator group is not present in the KMS during the key creation time, creator group is also created with the creator user as part of the user group. There are two types of ACLs - Key object based,  non-Key based.  Key Object based ACL is part of each Key object and is normally created by the creator.  Non-Key based ACL are non-key specific and normally created by the administrator.  
• Non-Key based ACL:  These ACL rules control the access when the keys are not present.  These ACL rules are normally created by the administrators. Each ACL rule contains the 'user group' and 'different types of permission'.    Different types of permissions can be:  Create/Register keys,  Create user group as part of key object creation,  Allow auto device registration by the creator of key object,  'Allow application registration by the creator'.  'allow creation of ACL rules on object by the creator',  'Allow archive', 'Allow resume', 'Allow import', 'Allow export',  ' Allow derive' by creator etc..   If administrator does not give 'Allow user group',  'Allow auto device registration' or 'allow ACL rules on objects', then administrator is expected to do these operations.  In addition to creating non-key based ACL rules,  KMS should provide facilities for administrators to add 'admin' users automatically to the user groups created by the creators to ensure that Enterprise always have control of keys. This is useful to process the data  when the IT gets hold of the laptops and smart phones after employees leave the company.  Yet times, administrator themselves might delegate some operations to some other IT staff.  Non-key based ACL should allow multiple IT personnel to do the key operations on existing key objects. These ACL rules may be delegated based on the 'applications'.  These ACL rule, hence, should contain   'user group',  'application identifier' and 'permissions'.  'Permissions are same as 'key based ACL rules'.  'Application identifier' can be 'Any'.
• Key based ACL:   These rules are normally created by the creators. Each rule contains 'Key object',  'user group' and permissions.  These ACL rules are sent to the KMS as part of create/register operation.  As discussed in addition to the ACL rules,  KM client also can send deployment information such as 'send the keys'.   KMS is expected to send the keys to the clients based on the application identification.  ACL rules indicate what rule information can be retrieved by the clients.  In case of VPN client, ACL rule are created by the creator such a way that only public key and certificates can be retrieved.  In case of cluster of servers application, ACL rule is created such a way that private key, public key and certificates can be retrieved by all servers in the cluster. 'Permissions in the ACL rule' can be - Get, Get Attributes,  Revoke, Derive, Expire, Archive, Backup, Delete etc..