Key management procedures in Cloud computing

Cloud computing infrastructures require the management and storage of many different kinds of keys; examples include session keys to protect data in transit (e.g., SSL keys), file encryption keys, key pairs identifying cloud providers, key pairs identifying customers, authorization tokens and revocation certificates. Because virtual machines do not have a fixed hardware infrastructure and cloud based content tends to be geographically distributed, it is more difficult to apply standard controls, such as hardware security module (HSM) storage, to keys on cloud infrastructures. For example:

  1. HSMs are by necessity strongly physically protected (from theft, eavesdrop and tampering). This makes it very difficult for them to be distributed in the multiple locations used in cloud architectures (i.e., geographically distributed and highly replicated). Key management standards such as PKCS#10 and associated standards such as PKCS#11 do not provide standardized wrappers for interfacing with distributed systems.
  2. Key management interfaces which are accessible via the public Internet (even if indirectly) are more vulnerable, as security is reduced in the communication channel between the user and the cloud key storage and the mutual remote authentication mechanisms used.
  3. New virtual machines needing to authenticate themselves must be instantiated with some form of secret. The distribution of such secrets may present problems of scalability. The rapid scaling of certification authorities issuing key pairs is easily achieved if resources are determined in advance, but dynamic, unplanned scaling of hierarchical trust authorities is difficult to achieve because of the resource overhead in creating new authorities (registration or certification, in authenticating new components and distributing new credentials, etc).
  4. Revocation of keys within a distributed architecture is also expensive. Effective revocation essentially implies that applications check the status of the key (certificate usually) according to a known time constraint which determines the window of risk. Although distributed mechanisms exist for achieving the challenges to ensure that different parts of the cloud receive an equivalent level of service so that they are not associated with different levels of risk. Centralized solutions such as OCSP are expensive and do not necessarily reduce the risk unless the CA and the CRL are tightly bound.

Tags : , , , , , ,

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.

Leave Comment