BACKGROUND OF THE INVENTION

[0001 ] The present invention relates generally to cloud computing, and more particularly to providing security to cloud computing service by using portable security devices.

[0002] Cloud computing enables an on-demand network access to a shared pool of configurable computing resources. It provides scalability, flexibility, and fault resilience. Although cloud computing has becoming increasingly popular, security remains a major issue to be addressed.

[0003] One of the cloud computing service models is Infrastructure as a Service (laaS), which allows consumers to configure processing, storage, network, and other computing resources, and to deploy and run desired software, such as operating systems or/and applications. One good example is Amazon's Elastic Cloud Computing (EC2) ¹ , which, among other things, allows the consumer to configure and run instances of virtual machines on Amazon's hardware.

[0004] The most promi nent laaS usage model is the hybrid approach. All established organizations already have their own computing infrastructure and software; many have security, privacy, and other regulatory and compliance req uirements. The hybrid approach leverages existing computing resources and uses the cloud resources as needed. The hybrid model allows the organization to keep its key assets and applications in-house for better control and provides an incremental process toward moving to the cloud. The hybrid model approach leads to hybrid applications that uses an organization's internal computing resources as well as the cloud resources. The cloud providers implement web services and application programming interface

¹ From Amazon.com of Seattle, Washington, USA. Described in Jinesh Varia, Cloud Architectures, Amazon Web Services (June 2008), available at

http://jineshvaria.s3.amazonaws.com/public/cloudarchitect ures-varia.pdf (retrieved on May 9, 2011) (API) for client applications to access the cloud computing resources. The RESTful API ² is the most common API format for such purposes.

[0005] Security is a key issue for outsourcing computing and data to the cloud because the consumer has no direct control to the infrastructure. The confidentiality, integrity, and availability of data and applications are crucial; any loss thereof would results in financial losses (e.g. , loss of business, inadvertent payment of someone else's bill, payment to customers), damage to reputation, loss of compliance, and inconvenience or financial injury to consumers. Cloud providers have deployed various mechanisms to provide security to their respective cloud services, including deployment of network firewalls, security settings to cloud computing accounts, separation of virtual machines, and access control mechanisms for cloud resources. Furthermore, typical ly cloud computi ng providers req u ire that al l API cal ls i ncl ude authentication information, such as digital signature of API calls. The authentication serves dual purposes: access control and billing for cloud usage. The consumer's application cryptographically computes the digital signature using the private key of a {private key, public key} pair or a secret key shared with the cloud provider. The signature proves that the user indeed is the holder of the secret.

[0006] Cloud providers advise consumers to keep the secret keys in a secure place and never share the keys with other individuals. If the key is compromised, the security of the consumer's data and applications in the cloud is also compromised. A problem is how to keep the key secure including assurance of secure key exchange, key storage, and key usage. With the current practice, in one scenario, the cloud provider generates a secret access key and its corresponding ID. The consumer copies the key and the ID from the cloud provider website and stores the key and ID on the consumer's computer or a server. Depending on the use cases, the consumer's application may read and use the key, the key may be hardcoded in the application, or the consumer

² Richardson, Leonard; Ruby, Sam (2007), RESTful Web Services, O'Reilly (published (May 8, 2007)) may send the key back to the cloud server. If a malware program resides on the consumer's computer or the application is compromised, the attacker may steal the key. Once having the key, the attacker can access the consumer's account in the cloud, accessing sensitive or private information, shutting down services, or using resources for free with the accrued charges charged to the key owner, thereby leading to the damages mentioned herein above. Furthermore, the consumer often manually manages the key, which provides a further usability issue.

[0007] Security is a major aspect when considering the adoption of cloud computing services. The IEEE and the Cloud Security Alliances (CSA) ³ have joined forces to develop security standards and to promote best security practices. The CSA has published the security guide ⁴ and identified seven top threats to cloud computing ⁵ .

[0008] Cloud providers build security features in many layers, including facility, hardware, virtual machine, storage, network, service, and APIs. This work focuses on securing API to cloud services. Cloud providers, such as Amazon EC2 and S3, Microsoft Azure ⁶ , Rackspace Mosso ⁷ , Terremark, ⁸ and Sun cloud, ⁹ publish APIs and associated documentation on their websites for software developers to develop applications that programmatically access

The Cloud Security Alliance (CSA) (www.cloudsecurityalliance.org) is a not-for-profit organization with a mission to promote the use of best practices for providing security assurance within Cloud Computing, and to provide education on the uses of Cloud Computing to help secure all other forms of computing. The Cloud Security Alliance is led by a broad coalition of industry practitioners, corporations, associations and other key stakeholders.

⁴ Cloud Security Alliance, Security Guidance for Critical Areas of Focus in Cloud Computing, v2.1 , www.cloudsecurityalliance.org/csaguide.pdf (retrieved May 11 , 2011)

⁵ Cloud Security Alliance, Top Threats to Cloud Computing, vl .O, March 2010, www.cloudsecurityalliance.org/topthreats/csathreats.vl .O.pdf. (Retrieved May 1 1 , 2011)

⁶ Of Microsoft Corporation, Redmond, Washington, USA

⁷ Of Rackspace US, Inc., San Antonio, Texas, USA

⁸ Of Terremark Worldwide, Inc., Miami, Florida, USA

⁹ Of Sun Microsystems, a subsidiary of Oracle Corporation, Redwood Shores, California, USA computing resources in the cloud. All these APIs require proper authentication in order to manage and interact with cloud services, including provisioning, management, operation, and monitoring. Most APIs are RESTful web service APIs.

[0009] The cloud APIs typically require client authentication. For example, AWS Query API requires computing HMAC-SHA hash using a secret access key (Amazon Web Services 2006), Windows Azure API requires SSL mutual authentication using the client X.509 certificate (Microsoft 2010), Mosso API requires an authentication token for accessing cloud services (Rackspace 2006), and Terremark API uses HTTP basic authentication (Terremark). Oracle recently proposed a cloud management API as a standard to the Distributed Management Task Force (1992). The proposal also specifies the HTTP basic authentication for each API request (Oracle 2010). The Open Cloud Computing Interface (201 1 ) is a set of open specifications from the Open Grid Forum. Unfortunately, OCCI only recommends that a client authentication mechanism be used where appropriate.

[0010] Cloud providers allow consumers to use the cloud services directly as well as through APIs. For example, a management console allows users to directly manage cloud resources, such as virtual machine instances or associated storage. In both the direct use and API scenarios, consumers must authenticate to the cloud by presenting some secrets (e.g. password) or proving the possession of the secrets (e.g. secret access key, private key). If these secrets are compromised, so are consumers' cloud accounts. Securely transferring, storing, and retrieving the secrets have not been well addressed, which negatively affects the security, usability, and adoption of cloud services.

[001 1 ] From the foregoing it will be apparent that there is still a need for an improved method to provide a secure mechanism for secure key exchange, key storage, and key usage to secure cloud computing. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 a is an illustration of two different devices that incorporate smart cards, namely, a credit card shaped smart card and a USB token with an embedded smart card and Figure 1 b is a high-level view of the architecture of a smart card of Figure 1 a.

[0013] Figure 2 is a diagram illustrating a high-level view of the architecture of a cloud computing system.

[0014] Figure 3 is a diagram illustrating an alternative high-level view of the architecture of a cloud computing system.

[0015] Fi gu re 4 is a ti m i ng seq uence d iagram of a devi ce registration process for registering a device to provide a secure mechanism for secure key exchange, key storage, and key usage to secure cloud computing.

[0016] Figure 5 is a timing sequence diagram illustrating the process of creating a key pair or a secret key and associates the ID of the key pair or the key with a resource in the cloud.

[0017] Figures 6 and 7 are timing sequence diagrams illustrating the connection or service request process using a personal security device.

[0018] Figure 8 is a schematic i l lustration of a hierarchical arrangement of cloud data structures and associated authentication keys.

DETAILED DESCRIPTION OF THE INVENTION

[0019] In the following detailed description, reference is made to the accom panying drawi ngs that show, by way of i ll ustration , specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. It is to be understood that the various embodiments of the invention, although different, are not necessarily mutually exclusive. For example, a particular feature, structure, or characteristic described herein in connection with one embodiment may be implemented within other embodiments without departing from the spirit and scope of the invention. In addition, it is to be understood that the location or arrangement of individual elements within each disclosed embodiment may be modified without departing from the spirit and scope of the invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims, appropriately interpreted, along with the full range of equivalents to which the claims are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.

[0020] In an embodiment of the invention, a mechanism is presented that provides a secure mechanism for secure key exchange, key storage, and key usage to secure cloud computing.

[0021 ] A. Introduction

[0022] The solution described herein uses portable security devices (PSD), such as smart cards or smart card based USB tokens, to secure access to cloud computing resources. Figure 1 a illustrates two example of portable security devices 101 , one is a credit card shaped smart card 101 a, and another is a secure USB token with an embedded smart card 1 01 b. As described above, cloud APIs typically require client authentication for each API request. Such authentication typically involves cryptographic operations using a certain secret, e.g., a secret key or a private key. The cryptographic operation with respect to an API request is often called signing an API request; the result is called a signature; and the secret used for the operation is called a signing key.

[0023] Figure 1 b is a block diagram illustrating the architecture of one embodiment of a portable security device 101 . The portable security device (PSD) 101 has a connector 103 for connecting the portable security device 101 to a host computer. Alternatively, the portable security device 1 01 communicates wirelessly with a host computer. The portable security device 101 further contains a processor 105 connected to a communications interface 1 17 for communication to the host computer via the connector 103. The processor 105 is further connected to a non-volatile memory 107 and a readonly memory 109. The read-only memory 109 may be used to store programs 1 1 1 , for example, program instructions executable by the processor 105 to perform the methods described herein below. These programs 1 1 1 may, alternatively, be stored in the non-volatile memory 107. The non-volatile memory may further store a signing key 1 13 associated with the security device and one or more signing keys 1 15 associated with particular cloud computing resources. These are described in greater detail herein below. (As described herein above and further discussed below, some cloud provider uses symmetric key cryptography and others use asymmetric keys for authentications. For the simplicity of description, in the following, the term key is used whenever there is no need to distinguish the handling of a symmetric key (or called a secret key) or a private key of a key pair.)

[0024] Figures 2 and 3 are schematic diagrams illustrating two alternative operating environments in which a PSD 101 is used to generate, store and use authentication keys associated with cloud computing services. In the example of Figure 2, a PSD 101 is used to manage authentication keys allowing a user 201 to operate a browser based cloud computing application to access a cloud resource 203 managed by a could computing server 205. In the example of Figure 3, a PSD 101 is used to manage authentication keys allowing a user 201 ' to operate a client application to access a cloud resource 203' ¹⁰

Wherever an apostrophe or a letter is used as a suffix to a reference numeral herein managed by a could computing server 205'. Figures 2 and 3 are described in greater detail herein below.

[0025] Returning now to Figure 1 b, the PS D 1 01 m ay be programmed to generate and store both symmetric keys (secret keys) and asymmetric keys (key pairs). The PSD 101 encrypts the symmetric keys using the public key of the cloud computing server 205 and sends the encrypted keys to the cloud computing server 205. For key pairs, the PSD 101 sends its public keys to the cloud computing server 205. After the key exchange, the handling and usage of the secret keys is between the cloud computing server 205 and the PSD 101 , instead of between the cloud and the hybrid application or the user. No secrets are transferred unencrypted and private keys never leave PSD 101 , thereby significantly improving the security of the cloud computing services. Furthermore, the consumers are not burdened with deciding where to store the secrets and do not need to manually copy the private or secret keys. Thus, an improvement in usability is also achieved.

[0026] Smart card based security devices are used herein for purposes of describing a preferred embodiment. A smart card is a small card that contains a secure and tamper-resistant microprocessor chip. It has secure memories (RAM and non-volati le memory), performs cryptographic computations, and contains security applications. Smart cards have been used successfully as subscriber identification modules (SIM) in cell phones, and cards for banking, computer access, digital signature, and many more.

[0027] Conventional smart cards based on ISO 7816 standard ¹¹ ca n use a tech nol ogy, cal l ed SCon n ect, to co m m u n i cate with web applications. ¹² SConnect includes a web browser extension, which supports such designation indicates different instances of elements that have the same reference number but that do not bear the suffix. Any references made herein without the suffix is meant to apply equally to the elements having the suffix unless explicitly stated otherwise.

¹¹ Identification Cards - Integrated Circuit(s) Cards with contacts, ISO 7816 standards

¹² K. Sachdeva, H.K. Lu, and K. Krishna, "A Browser-Based Approach to Smart Card Connectivity," IEEE Workshop on Web 2.0 Security and Privacy, Oakland, California, May 21 , 2009. Firefox, IE, and Safari (alpha), and a JavaScript API. The user inserts the smart card to a card reader connected to his computer. Some computers, such as DELL Latitude series, have embedded smart card readers. One can also use an external smart card reader.

[0028] The smart card based USB token has an embedded smart card and external (with respect to the smart card) flash memory. The user inserts the token to a USB port of his computer. The smart card USB tokens can use SConnect technology as well, if they are based on the PC/SC interface standard. ¹³

[0029] While the present discussion relies on smart cards as an illustrative example for a PSD 101 , the technology described herein applies equally to other secure portable devices such as secure USB tokens and secure mobile devices.

[0030] A computing cloud typically has a certain (e.g. hierarchical) structure that organizes the computing resources of the cloud, such as services and virtual machines; virtual data centers, clusters, and storage volumes. Herein a PSD 101 is used to provide a two-factor security protection to the cloud structure for enhancing the security and usability. The two factors are what you know (PIN, password, or passphrase) and what you have (a PSD 101 ). The security protection applies to the software and data resources in the computing cloud infrastructure. The technology described herein provide mechanisms generating and using different keys, and handling different authentication protocols for different resources rather than using the same ID and secret key for all the resources and services in a same cloud account. This provides the capability of using the relationships among resources to configure the level of protection, usability, and performance based on needs.

[0031 ] The technology described herein enhances the security and usability to existing cloud computing services by introducing the two-factor security protection, which makes the key exchange, key storage, and key usage

PC/SC Workgroup, Specifications, http://www.pcscwork group.com, V 2.01.3, Jan. 2006. much more secure and removes the manual process by the user. As a result, the method mitigates risks associated with three out of seven top threats to cloud computing (insecure interfaces and APIs, data loss or leakage, and account or service hijacking). ¹⁴

[0032] The operating environment in which the present technology may be used for managing authentication keys for securing cloud computing resources consists of the following which are illustrated in Figure 2:

1. A cloud computing server 205, of a cloud computing service cloud 207 which provides cloud resources 203, and an API 204 for accessing the cloud resources 203;

2. An hybrid web application 206 residing on a hybrid web application server 209 within an organization's domain and accessing the resources 203 in the cloud 207;

3. A user 201 , for example, an administrator to the hybrid application 206;

4. A user's computer 21 1 ;

5. A web browser 213, running in the user's computer 21 1 ;

6. A portable security device 101 , for example, a smart card, which belongs to the user 201.

7. One or more user accounts 215; each associated with a user 201 allowing the user 201 to access certain cloud resources 203.

[0033] The Figure 2 illustrates this operating environment. The arrows in the figure represent logical connections. In reality, the hybrid web application 206 and the user computer 21 1 access the cloud computing services 207 through the organization's firewall and then the Internet, which are not illustrated in the figure.

[0034] The user 201 accesses the hybrid application 206 to manage the cloud computing resources 203 associated with the organization of the user, such as configuring and launching a new virtual machine instance, configuring security settings, and allocating a new storage volume. The user 201

Cloud Security Alliance, Top Threats to Cloud Computing, vl .0, March 2010 may also access the cloud directly, for example, associating a security device 101 with the account.

[0035] Alternatively, the application accessing the cloud computing resources may be running inside the user's computer 201 or inside the web browser 213. (See Figure 3 wherein the application is referred to as a Client Application 206'.)

[0036] I n one em bodiment, all connections between the user's computer 21 1 , the hybrid application 206 and the cloud computing server 205 are TLS/SSL. The cloud provider typically requires use of a secret access key or proving the possession of a private key for every service request through the API.

[0037] Portable security devices 1 01 have secure storage and perform cryptographic computations. Utilizing these capabilities, such devices may be used to store keys and to secure access to cloud computing resources. Th is i nvolves three basic operati ons : key storage , key exchange , and cryptographic computations.

[0038] Key Storage. The PSDs 101 preferably have tamper- resistant secure storage that can store secret keys (e.g. shared keys, private keys), e.g., in non-volatile memory 1 07 (Figure 1 b). Because the PSD 1 01 requires user authentication, an attacker must have both the device and the user login credential in order to gain or steal the secrets.

[0039] Secure Key Exchange. In one embodiment, before issuing the PS D 1 01 to a user, the issuer may provision the PSD with an X.509 certificate and associated private key for communications with the cloud computing provider. For key exchange, the PSD 101 sends the certificate to the cloud computing server 205, which associates the certificate with the user account. The cloud computing server 205 can encrypt the secret access key using the public key of the PSD 101 and sends the encrypted key to the PSD 101 .

[0040] Alternatively, the PSD 101 can generate the secret access keys or key pairs. The PSD 1 01 also stores the keys. In that alternative, the PSD 101 sends the public key to the cloud server 205, or encrypts the secret key using the public key of the cloud computing server 205 and sends the encrypted secret key to the cloud computing server 205. The private key never leaves the PSD 101 and the shared secret key never leaves the PSD 101 or the cloud computing server 205 in plain text.

[0041 ] Some cloud API requires cryptographic computations, such as digital signature or cryptographic hashing, to authenticate requests. The PSD 101 devices can perform these cryptog raph i c co m p utati o ns us i ng a cryptography module. The advantage of moving such operations to the PSD 101 is that the secret key or private key remain inside the device, preventing attackers from stealing the keys. The PSD 101 does not provide interface to export the private key nor to export the secret key without encryption.

[0042] Through use of the technology described herein two-factor security protection is provided for cloud computing services that provide an API for resource access. The two factors are what you know (PIN, password, or passphrase) and what you have (a security device, e.g. a smart card or a secure USB token). The security protection applies to resources in the cloud. A user must know the secret (PIN, etc.) and have the security device in order to access the resources.

[0043] The two-factor security protection method uses the basic operations described herein above. The mechanism further includes processes for registration of a PSD 101 , association of the PSD to an account and of keys and I Ds to particular cloud resources 203, and resource connection . The (hierarchical) relationships of the resources in the infrastructure enable the cloud providers and consumers to configure the security, usability, and performance based on needs.

[0044] B. General Operations

[0045] To use a PSD 101 , a user 201 first registers the PSD 101 with a cloud account 215. After the registration, protecting a cloud resource 203 involves two phases, association and connection. The association relates an ID of a key pair or a secret key with a resource 203; the connection mechanism allows the user 201 to connect to or access the resource 203 to perform certain tasks.

[0046] In the following descriptions, the user 201 interacts with an application 206, which is a client to the cloud computing server 205. The application 206 knows how to communicate with the user's security device, e.g., usi ng the G E MALTO SCon nect tech nol ogy descri bed i n U . S . Pat. N o . 7,748,609, to Kapil Sachdeva and Ksheerabdhi Krishna, entitled System and method for browser based access to smart cards. The application 206 may be the hybrid web application running inside the user's organization's perimeter (network domain) or a client application running on the user computer or in user's web browser. For the simplicity of descriptions, in the following description, it is referred to as the client application.

[0047] B.1 Registration

[0048] In order to use a PSD 101 for an account 215 with a cloud provider, the user registers the PSD 101 . The user 201 may register the PSD 101 during the account activation or afterward. The PSD 101 is provisioned with a {public key, private key} key pair for use with the cloud provider. Figure 4 is a timing sequence diagram illustrating the registration process.

[0049] The registration may involve the following steps (it is not strictly necessary that these steps are executed in the precise order suggested here):

1 . The user 201 logs in to the user's cloud account 215 on the cloud 207, through the client application 206, or the user 201 creates a new account 215. The user requests to register the user's PSD 101 .

2. The user logs into the user's PSD 101 , using PIN for example.

3. At the user's req uest, the client application 206 obtains device information from the PSD 101 , such as the serial number and public key.

4. The application 206 sends the PSD 1 01 device information to the cloud computing server 205.

5. The cloud computing server 205 associates the PSD 101 information with the user's account 215. 6. The cloud computing server 205 generates a signing key for the PSD

101 .

7. The cloud computing server 205 encrypts the signing key with the public key of the PSD 101 .

8. The cloud computing server 205 transmits the encrypted signing key to the PSD 101 .

9. The PSD 101 stores the signing key 401 .

[0050] Alternatively (to steps 6 - 9), the PSD 101 generates the signing key and sends the key to the cloud computing server 205 encrypted using the public key of the cloud computing server 205.

[0051 ] The PSD 101 uses its signing key to sign initial requests to the server before other keys are established. For example, the user may create one or more signing keys (symmetric or asymmetric) for signing server requests for different resources.

[0052] B.2 Association

[0053] The association phase creates a key pair or a secret key and associates the ID of the key pair or the secret key with a resource in the cloud . Figure 5 is a tim ing seq uence diagram i llustrati ng the association process.

[0054] Let K be the key (pair) for the resource R 203; IdK be the identifier for K; KS is the signing key established in the registration phase. The goal of the association process is to associate IdK with R. The PSD 101 uses the signing key KS 401 to si gn the req uest to the cl oud server for this association. Once the association is established, the PSD 101 uses to sign all the future requests for the resource R.

[0055] In more detail, the association takes the following steps (it is not strictly necessary that these steps are executed i n the precise order suggested here):

51 . The user 201 identifies a resou rce for key associ ation to the application 206. 52. Via the appl ication 206, the user 201 req uests the PSD 1 01 to generate a key pair or secret key in the PSD 101 .

53. The PSD 101 generates the key pair or the secret key, and stores the key(s) 1 15 (Figure 1 b) in its secure storage 107. The PSD 101 sends the public key to the client application or encrypts the secret key using the public key of the cloud computing server 205 and sends the thus encrypted key to the client application.

54. The client application 206 formalizes the request, with parameters including the identity of the resource 203, key (pair) I D, and the public key (or the encrypted secret key via the public key of the server 205).

55. The application 206 asks the PSD 1 01 to perform a cryptographic operation, e.g., to sign or to encrypt the request.

56. The PSD 101 performs the cryptographic operation, for example, to sign the request using the signing key 1 13 of the PSD.

57. The PSD 101 returns the resulting signature to the client application

206.

58. The client application 206 combines the signature with the original request, and sends the resulting combined request to the cloud computing server 205.

59. The cloud computing server 205 verifies the request, for example verifies the signature using the device's public key (or the shared secret key)

60. The cloud computi ng server 205 associates the key I D with the resource.

[0056] In an alternative embodiment, the cloud computing server 205 generates the key pair or the secret key. In this case, the server encrypts private or the secret key using the device's public key or the shared secret key, and sends the encrypted key to the device for storage.

[0057] Thus, after the association phase an association has been established between a resource R 203, and a key id IdK, and a key K (shown as key K 601 in Figures 6 and 7). These associations are stored in both the PSD 101 and by the cloud computing server 205. [0058] B.3 Connection or Service Request

[0059] The connection phase enables the user 201 to connect to a resource or to make a service request using the user's PSD 101 . From the association phase, both the PSD 101 and the cloud computing server 205 have stored the key K 601 (and 601 ') associated with the resource R 203. The PSD 101 signs any requests for the resource R 203 with the key K 601 .

[0060] Figure 6 is a tim ing seq uence diagram i l lustrating the connection or service request process in the operating environment of Figure 2, i.e., wherein the application used by the user 201 to access a cloud resource 203 is a hybrid application 206 hosted external to the user's computer 213 via a host client 213. The following describes this phase in more details which starts with the user connecting the user's PSD 101 to the user's computer 21 1 (it is not strictly necessary that these steps are executed in the precise order suggested here):

61 . The user 201 logs into the PSD 101 , for example, by entering the PIN for the PSD 101 .

62. The user 201 , operati ng a host cl ient 21 3, e.g . , a web browser, causes the application 206 to make a service request for a computing resource 203 in the cloud 207 and selects the key ID associated with the resource 203.

63. The client application 206 prepares the request for access to the resource R 203.

64. The client application 206 asks the PSD 201 to perform some cryptographic operation, e.g., digital signature or encryption, with respect to the request.

65. The PS D 201 usi ng its cryptography module 602 performs the cryptographic operation using the private key or the secret key 601 associated to the key ID.

66. The PSD 201 retu rns the result, e.g . , a digital signature or an encrypted message to the client application 206.

67. The cl i ent appl i cation 206 sends the service req uest and the cryptographic operation result (e.g. , signature) to the cloud computing server 205. 68. The server verifies the cryptographic operation result using the public key or the secret key 601 ' associated with the key ID.

69. If the verification is successful (9a and 9b), connection is established between the user operating the host client 213, the client application 206, and the resource 203 via the cloud computing server 205.

[0061 ] Figure 7 is a tim ing seq uence diagram i l lustrating the connection or service request process in the operating environment of Figure 3, i.e., wherein the application used by the user 201 to access a cloud resource 203 is a host client 206' operating on the host computer 21 1 . The following describes this phase in more details which starts with the user connecting the user's PSD 101 to the user's computer 21 1 (it is not strictly necessary that these steps are executed in the precise order suggested here):

71 . The user 201 logs into the PSD 101 , for example, by entering the PIN for the PSD 101 .

72. The user 201 , operating a host client 206', e.g., a web browser, builds a service request for a computing resource 203 in the cloud 207 and selects the key ID associated with the resource 203.

73. The client application 206' asks the PSD 201 to perform some cryptographic operation, e.g., digital signature or encryption, with respect to the request.

74. The PS D 201 usi ng its cryptography module 602 performs the cryptographic operation using the private key or the secret key 601 associated to the key ID.

75. The PS D 201 returns the result, e. g . , a digital signatu re or an encrypted message to the host client application 206'.

76. The host client application 206' sends the service request and the cryptographic operation result (e.g. signature) to the cloud computing server 205.

77. The server verifies the cryptographic operation result using the public key or the secret key 601 ' associated with the key ID. 78. If the verification is successful (78a and 78b), connection is established between the user operating the host client 206' and the resource 203 via the cloud computing server 205. [0062] C. Hierarchical Security Protection

[0063] Different cloud providers adopt different hierarchical structures for their resources. Each resource in the hierarchical structure may be associated with a unique key or inherit the key from its parent. The key may be a symmetric key or an asymmetric key pair, which require different cryptographic computations. A cloud provider may provide more than one type of APIs with different authentication methods and different kind of keys to access the same resource. A security device can store multiple keys and perform various cryptographic operations, which enables it to provide security protection to various resources in the cloud hierarchy.

[0064] Figure 8 is a schematic diagram illustrating an example hierarchy wherein various nodes in the hierarchy are assigned keys. In the illustration a key KA is assigned to the user account 215. There are n cloud computing services 803 provided under the user account 215. For this example, only service 3 803" is assigned a key KS3. The other services inherit the keys from the user account 215, i.e., key KA is used to authenticate to the other services and key KS3 is used to authenticate to Service 3 803".

[0065] For Service 1 803, there are n virtual memories 805. Each is assigned its own key KV1 - KVn, respectively. Thus, authentication to the virtual machines 805 requires the use of the specific key KVx corresponding to the virtual machine x.

[0066] For Service 3 803" there are n Data volumes 807. For this service the authentication key may be either assigned to the data volume, e.g., as shown for Data Volume 1 807, or may inherit the key from the service, as shown for Data Vol. n 807 ⁿ . Alternatively, keys may be assigned to specific data objects 809 in the data volume 807 (this alternative is not illustrated in Figure 8).

[0067] Thus, the PSD-based approach for managing authentication keys described herein allows the user or the cloud provider to customize the security level based on the needs in security, performance, and usability, or the balance of them. For example, (1 ) the granularity of the security protection: some resources have their own keys, while others may inherit or share keys; (2) usage of one or multiple PSDs for different cloud services; and (3) single or multiple user authentications for various requests. This includes at least the following aspects:

1. The granularity of the security protection in the user's account. For example, at one end of the security spectrum, all resources in all levels share a single key, which is not very secure; at the other end of the spectrum, each resource has its own unique key, which is much more secure. Most cases may fall in the middle of the two extreme: some resources may have their own keys, and others may inherit or share keys.

2. Usage of one or multiple security devices. For example, a user can use one security device to store all the keys and perform required cryptographic operations; or a user can use one device for one cloud service and another device for another.

3. Single or multiple device authentications: a user enters PI N (or passphrase, etc.) to the security device once or multiple times for various requests, or one PIN per cloud service or one PIN for all cloud services with one cloud provider.

[0068] D. Conclusion

[0069] Cloud services often require secret access keys or private keys to access. Keeping these keys secure during transit and in storage is critical. If the keys are compromised, so are the users' accounts and their applications, services, and data in the cloud. The technology described herein secures these keys and associated cryptographic operations using portable security devices.

[0070] A user, typically an administrator, must have the security device and the credential, such as PI N, in order to manage the computing resources, e.g. launching or shutting down a virtual machine instance, in the cloud. This provides a two-factor protection to the resources. The user can enter the PIN from the computer either via a keyboard or a virtual PIN pad; or using an external secure hardware PIN pad. Using the hardware PIN pad is the most secure method because the PIN never enters the computer. If the PIN entry is through a keyboard, it is possible that a malicious keystroke logger resides on the user's computer and it captures all keystrokes including the PIN. However, the PIN is useless without the device.

[0071 ] The security device provides a secure storage for the secret keys (including the access key and private key). In two exemplary embodiments, the secure storage is either the tamper-resistant secure memory of a smart card or the flash memory of a secure USB token with real-time encryption and decryption.

[0072] According to the method described herein above, the cloud server 205 and the PSD 101 transfers the access key using encryption; the PSD 101 performs cryptographic computations using the access key or the private key inside the PSD 1 01 ; and the cloud server 205 uses the result of the cryptographic operation to authenticate the service requester. In this way, the secret access key never leaves the cloud server 205 or the PS D 1 01 unencrypted, and the private key of the PSD 101 never leaves the PSD 101. As such, attackers cannot steal the keys from the computer 21 1 or a browser executed on the computer 21 1.

[0073] Only the cloud server 205 and the PSD 101 deal with secret keys. This also provides better usability because the user 201 does not need to copy the keys and find a safe place to store the keys.

[0074] The general principles discussed herein are applicable to other cloud provider offerings in addition to the ones specifically discussed herein.

[0075] From the foregoing it will be apparent that a mechanism has been disclosed that provides a secure mechanism for secure key exchange, key storage, and key usage to secure cloud computing.

[0076] Although specific embodiments of the invention have been described and illustrated, the invention is not to be limited to the specific forms or arrangements of parts so described and illustrated. The invention is limited only by the claims.

[0077] We Claim: