Authenticating and authorizing a user by way of a digital certificate

An administrator may issue a credential to a user and may define a policy that authorizes its use based on a predefined location. The policy and the credential may be bound in a digital certificate signed by a trusted party. When the user operates a computing device to access a resource, the computing device may present the digital certificate to the resource. In turn, the resource may use the digital certificate to authenticate the user and to verify that the policy authorizes his or her access.

BACKGROUND

Digital certificates are commonly used to authenticate users in computing systems to authorize access to computing resources. A digital certificate typically binds a credential with information identifying a user associated with the digital certificate. A computing system relies on the digital certificate to authenticate the user so that the user can thereafter access a computing resource by way of the computing system.

The credential typically includes a cipher and is issued to the user by an administrator that manages its uses. The administrator provides the credential and the information identifying the user to a certificate authority that generates the digital certificate in, for instance, an X.509 standard format.

DETAILED DESCRIPTION

The following detailed description is directed to techniques for employing digital certificates to control access of users to resources operated by a service provider across boundaries.

As noted above, an administrator typically issues a credential to a user to facilitate access by the user to one or more computing resources by way of the credential. As disclosed herein, the administrator can also associate an authorization policy with the credential. The authorization policy provides a basis for authorizing access to computing and other resources by the user associated with the credential based on various parameters such as location-based parameters. For instance, the authorization policy can indicate that the user's access to a resource should be restricted based on a location of the resource, a location of a user's computing device presenting the credential and so on.

The credential, the authorization policy and information identifying the user can be bound in the same digital certificate. When the user operates the computing device to request access to the resource by way of a system, the system authenticates the user based on the digital certificate and authorizes the access to the resource based on the authorization policy also contained in the digital certificate.

To generate the digital certificate, the administrator often sends the credential, the authorization policy and the information identifying the user to a trusted party. The trusted party, usually a certificate authority, digitally signs an electronic document that contains the credential, the authorization policy and the information identifying the user to generate the digital certificate. The resulting document is a digital certificate that not only attests to the association of the user and the credential, but that also controls the use of the credential by way of the authorization policy. Further, the digital certificate is protected against tampering by the digital signature of the trusted party.

The digital certificate is usually retained by the user on a storage medium such as a smart card, thumb drive, or other portable storage device that the user may use separate from the user's computing device. The user, in turn, can provide the credential to a computing device by way of a reader so that the computing device can, in turn, authenticate the user or provide the digital certificate to another system to authenticate the user. Additionally, the digital certificate can be stored on the user's computing device which can present it to the other system that authenticates the user.

As noted above, according to an aspect of the disclosure, an authorization policy is also included in the digital certificate. The authorization policy can limit permissions granted to the user such that a system can both authenticate a user and determine policy restrictions placed on the user by referring to the contents of the digital certificate and without the need for the system to refer to a separate authorization policy. In one example, the authorization policy may limit the user's access to a resource when the user is located outside of a predefined geographic boundary or when services hosted by the resource are not offered in a geographic area where the user operates.

As also noted above, the digital certificate is often issued to the user. In an example embodiment, the user is a real person or an entity that uses a computing resource such as a computing device or system. In another example embodiment, the user is a computing resource, a user account, or an administrative account that uses the digital certificate.

The following figures and embodiments describe the use of the digital certificate in the context of accessing a server. Nevertheless, other computing and non-computing resources are contemplated as falling within the scope of the disclosure. Example computing resources include datacenters, network-based resources, web servers, personal computing devices and the like. Example non-computing resources include resources with a controlled access to a facility such as entrances controlled by smart card readers.

The use of the digital certificate as disclosed herein can also include providing a certain type of services, accessing a certain type of data associated with the computing resources, or other type of operations available to the user. For example, in the context of datacenters, the digital certificate can be used to authorize the user to launch a virtual machine with a particular operating system but not with another operating system. Similarly, in the context of a web server, the web server may provide the user with a certain type of content based on the digital certificate. In the context of a facility, a smart card reader may process the digital certificate to authorize the user to access a particular floor of the facility but not others.

FIG. 1illustrates an example embodiment of a system for using a digital certificate to control access of a user to servers. The controlled access includes an authentication of the user and a determination of one or more functions that the user is authorized to perform. In a basic configuration, system100ofFIG. 1includes a user device110in communication with a first server130and a second server140over a network120. Network120may include communication networks of any type that are suitable for providing communications between user device110and servers130and140and may include a combination of discrete networks that may use different technologies. For example, network120may comprise a cellular network, a WiFi/broadband network, a local area network (LAN), a wide area network (WAN), a telephony network, a fiber-optic network or combinations thereof. In an example, the WiFi/broadband network may be adapted to communicate with the Internet. Network120may be also configured to transmit data between any of the components of system100.

User device110is associated with a user112to whom a digital certificate114is issued and is configured to enable communications to servers130and140by way of digital certificate114. User device110and servers130and140can employ various cryptographic protocols and other techniques to secure the communications. The cryptographic protocols include transport layer security (TLS) and secure sockets layer (SSL), which may be collectively referred to as TLS/SSL. Many of these cryptographic protocols and other security techniques involve the use of one or more encryption algorithms to encrypt data communicated between devices or components. The term encryption algorithm, as used herein, refers to any cipher, code or other technique used to encrypt communications. Such encryption algorithms include, for example, advanced encryption standard (AES) that uses symmetric key cryptography, Ron River Adi Shamir and Leonard Adleman (RSA) that uses asymmetric key cryptography and the like.

Digital certificate114may encode authorization information associated with user112. In an embodiment, digital certificate114embeds a credential114A associated with user112and an authorization policy114B associated with user112. Credential114A typically includes information that facilitates functions that the user can perform such as accessing a resource. This information may be in the form of a secret, a code, a token, a cipher, a pair of private/public keys or any information derived by applying, for instance, a cryptographic technique to the particular permission.

Authorization policy114B can include a rule that defines location restrictions associated with user112so that a system that authenticates the user can also use the location restrictions to authorize a request of user device110to access a computing resource. The locations restrictions allow the system to authorize the use of the digital certificate based on the location of the resource that user112attempts to access and also, in some instances, based on the location of user112when access is attempted.

In an example embodiment, first server130is associated with first location132and second server140is associated with second location142. In response to receiving digital certificate114from user device110, servers130and140verify that credential114A is properly issued to user112, authenticate user112, and retrieve authorization policy114B. Servers130and140also enforce authorization policy114B by comparing the location restrictions defined by the rule included in the authorization policy to first and second locations132and142. When, for instance, the rule includes a location that encompasses first location132but not second location142, first server130authorizes a request for access, whereas second server140denies the request for access.

To further illustrate the operation of authorization policy114B, the following describes various examples where first server130is located in Alaska, second server140is located in California. In a first example, authorization policy114B restricts user112from accessing servers located outside of California. When user112operates user device110to access the information at first server130, first server130uses the digital certificate to authenticate user112. First server130also determines whether to authorize the operation using the authorization information embedded in digital certificate114. Here, the server114determines that user112is not authorized to perform the operation on server130located in Alaska, based on authorization policy114B. Consequently, server130denies user device110access to the information.

In comparison, when user device110presents digital certificate114to second server140, this server may also follow a similar authentication and authorization procedure as first server130. However, in this case, second server140authorizes user112to access the information because authorization policy114B allows the use of the digital certificate in California, which is where second server140is located.

In another example, authorization policy114B allows user112to access servers by way of the digital certificate when the user is located in Oregon. In this example, when user112operates user device110to connect to first server130that is in Alaska, first server130allows the user to access the information if user device110is located in Oregon at the time of the access.

In yet another example, authorization policy114B allows user112to access servers by way of the digital certificate when the servers are located in California and when the user is also located in California when the user attempts to access the servers. In this example, first server130that is located in Alaska denies user device110's access to the information regardless of the location of user112. In comparison, second server140that is located in California allows user device110to access the information only when user112is also located in California.

The location restrictions may not be limited to geographic boundaries of states, but may also include other physical and non-physical boundaries. For example, the physical boundaries are based on a geographic region, a country, a city, an area code, a building, a floor of a building, a certain radius of a global positioning system (GPS) coordinate and the like. The non-physical boundaries can be logical boundaries that depend on how data is stored, managed and accessed. For example, servers130and140can store the information in different partitions that have different access levels such as in high, medium and low sensitivity groups. In comparison, the location restrictions can allow user112to access the data in the medium or low sensitivity groups. Thus, even when user112is authenticated and authorized to access the information, he or she is denied access to the data stored in the high sensitivity group by way of digital certificate114.

In an embodiment, an official agency associated with a jurisdictional boundary can also mandate the location restrictions. For example, government agencies in the United States of America and in Germany may require cryptographic keys to be of different lengths. A first agency associated with one of the two countries may allow a use of 128-bit and 64-bit public keys while a second agency associated with the other country may limit the use to the 64-bit public key. As such, when the administrator issues credential114A that includes one of the two types of public keys, the agencies require the administrator to restrict the use of credential114A based on the key length. In this example, the administrator allows the user to use the 64-bit public key within any of the two countries and the use of the 128-bit public key within only the jurisdictional boundary of the first agency.

The rule may authorize the use of digital certificate114based on a destination location, a source location or a combination of the two locations. The destination location includes the location where the digital certificate is used such as the locations associated with the servers. An example of this rule is in the form of “the user of this digital certificate is authorized to use the digital certificate to access a resource that is located in California.” For instance, when user112presents digital certificate114to servers130and140, only second server140may authorize user112's access by way of digital certificate114because second server140is located in California, whereas first server130is located in Alaska.

The source location includes the location from where the digital certificate is presented such as the location of the computing device at the time that it requests the access to the servers or the location of the user at that time. An example of this rule is in the form of “the user of this digital certificate is authorized to use the digital certificate when the user is located in Oregon.” For instance, when user112presents digital certificate114to servers130and140, the servers may authorize user112's access by way of digital certificate114when user device110is located in Oregon. Otherwise, both servers deny the user's access regardless of their locations.

To generate digital certificate114, the administrator may provide credential114A, authorization policy114B and the information identifying user112, among other data, to the trusted party.FIG. 2illustrates an example end-to-end system for issuing a digital certificate similar to digital certificate114ofFIG. 1. The illustrated end-to-end system200may include some or all elements of system100ofFIG. 1and may include an administrator device210, a certificate authority220, a user device230and a server240interconnected by one or more communication networks and configured to issue and use the digital certificate.

An administrator operates administrator device210to issue a credential212to a user associated with user device230. The administrator also defines an authorization policy214that restricts uses of credential212, identifies the user in user information216, e.g., a user's identity, name, address, contact information, and associates user information216with credential212. These and other functions of the administrator can be executed on administrator device210that outputs credential212, authorization policy214and user information216. Administrator device210may also provide this output to certificate authority220or to user device230that may subsequently transmit the output to certificate authority220.

In turn, certificate authority220verifies that user credential212is properly issued to the user based on user information216and binds authorization policy214, user information216and user credential212in a digital certificate222. Certificate authority220includes any computing device suitable for interaction with components of system200and is associated with a trusted third party that server240relies on to verify the user. For example, digital certificate222allows server240to trust that user credential212is properly issued to the user. Certificate authority220also transmits digital certificate222directly to user device230or, instead, to administrator device210that then transmits digital certificate222to user device230. When the digital certificate is received, user device230stores and uses it to interact with server240.

Server240performs a user authentication and authorization232procedure that involves authenticating the user based on digital certificate222and authorizing operations of the user based on authorization policy214embedded in digital certificate222. For example, server240includes any computing device suitable for interaction with components of system200and for storing data and is configured to provide access to computing resources using various techniques. One technique includes encrypting data exchanged with user device230based on user credential212when the user is authenticated and authorized to exchange the data.

Administrator device210, certificate authority220and user device230may be components of a public key infrastructure (PKI) system that is configured to generate, distribute, store, manage and revoke digital certificate222. In an example, administrator device210is integrated with certificate authority220and/or user device230. Likewise, user device230is configured to self-certify user credential212by integrating functionalities or elements of certificate authority220. In another example, user device230is configured to issue user credential212and user information216, whereas administrator device210is configured to generate authorization policy214. In this example, certificate authority220receives user credential212and user information216from user device230and authorization policy214from administrator device210and issues digital certificate222accordingly.

FIG. 3is a flowchart depicting an example procedure that system200ofFIG. 2may perform to issue and use digital certificate222. Operation302illustrates an administrator device issuing a credential to a user, such as a public key. The administrator device identifies the user and defines a policy that limits his or her use of the credential. Operation304illustrates a certificate authority generating a digital certificate and digitally signing the certificate with a private key of the certificate authority. The digital certificate includes, for example, the public key, the user information, the policy and the digital signature of the certificate authority. The certificate authority transmits the digital certificate to a user device associated with the user or to the administrator device.

Operation306illustrates the user device using the digital certificate to interact with a server, such as a web server associated with a service provider. For example, the user may wish to authenticate to the server to access resources offered by the service provider and may use a browser of the user device to connect to the server. In this example, when the user device connects to the server, the user is prompted to enter a password into the user device to unlock a database on the user device that stores a private key associated with the public key of the credential. The user is granted access to the private key and the user device uses the private key to sign randomly generated data. The signed data and the digital certificate are sent to the server.

Operation308illustrates the server authenticating the user and determining whether the user device is authorized to access the server based on the digital certificate. For example, to authenticate the user, the server determines that the digital signature that was used to sign the digital certificate is associated with the certificate authority, thereby validating that the digital certificate is authentic. In addition, the server verifies that the user device includes the private key associated with the public key embedded in the digital certificate. For example, the server uses the public key to validate the randomly generated data that was signed with the corresponding private key and that was sent to the server along with the digital certificate, thereby validating the user's identity.

As part of an authorization process, the server also processes the policy embedded in the digital certificate to determine whether to authorize an operation associated with a request from the user device. The server enforces the policy using various techniques that are further described inFIG. 6. One technique that the server may implement includes a comparison of a location restriction from the policy to its location or to the location of the user device and to authorize the operation based on the comparison. For example, when the policy indicates that the user is authorized to access content hosted on a resource in Texas and when the server hosts content in such a location, the server provides the user device access to the content. Further, the policy can require the server to alert the administrator when the user attempts to use the digital certificate in a non-authorized way. Thus, when the server hosts content in Arizona that the user device attempts to retrieve by way of the digital certificate, the server sends a communication to the administrator device.

In comparison toFIGS. 2 and 3,FIGS. 4 and 5illustrate examples of another system and procedure, respectively, for issuing the digital certificate where only the administrator device is configured to generate the authorization policy. More particularly the illustrated system400ofFIG. 4includes a user device410, a certificate authority420and an administrator device430interconnected by a network and may implement some or all elements of system200ofFIG. 2. User device410is configured to generate a credential412A and user information412B and to transmit this information to certificate authority420. In parallel, administrator device430is configured to generate an authorization policy412C that controls uses of credential412A based on locations and to transmit such a policy to certificate authority420. In turn, certificate authority420verifies the information received from user device410and generates a digital certificate422that includes the credential and the policy and digitally signs the digital certificate using a certificate authority private key424.

In an example, user credential412A includes a public key that is associated with a private key of the user. Although a pair of asymmetric keys is described inFIG. 4, other type of keys, such as a pair of symmetric keys or other techniques, may be implemented to generate credential412. The public/private keys are randomly generated by a key generation module implemented at administrator device430, user device410or another computing device coupled to either device. The private key is only known to user device410, whereas the public key is shared with certificate authority420. User information412B is based on an identity of the user and includes, for example, a name, an address, contact information and so on.

Authorization policy412C is defined by an administrator of user device410and is not necessarily based on the identity of the user. Instead, authorization policy412C is based on a requirement that is defined by the administrator or by an official agency and that mandates a boundary within which credential412may be used. The administrator uses administrator device430to generate such a policy.

Certificate authority420signs digital certificate422using certificate authority private key424to bind credential412A, user information412B and restriction412C together and transmits digital certificate422to user device410. Certificate authority private key424is generated by a key generation module that is implemented at certificate authority420and that outputs a pair of keys. The pair of keys typically includes a certificate authority public and certificate authority private key424. This public key is published and shared with user device410. In comparison, certificate authority private key424is kept as a secret and is only known to certificate authority420.

Digital certificate422not only provides a verification that credential412A is properly associated with the user based on, for example, user information412B, but also provides a verification that the user is authorized to use credential412A according to authorization policy412C. Because digital certificate422is signed with certificate authority private key424, user device410or any other non-certificate authority computing device can retrieve, decrypt and read authorization policy412C using the certificate authority public key but cannot alter or tamper with authorization policy412C.

FIG. 5is a flowchart depicting an example procedure for issuing digital certificate422to a user and may be performed by system400ofFIG. 4. Operation502illustrates a certificate authority receiving a credential associated with the user. A user device associated with the user or an administrator device associated with an administrator that manages credentials issued to the user transmits the credential to the certificate authority. Operation504illustrates the certificate authority receiving user information from the user or administrator device. Operation506illustrates the certificate authority receiving an authorization policy associated with the use of the credential from the user or administrator device. The authorization policy is defined by the administrator and describes a location restriction where the credential may be used.

The credential, the user information and the authorization policy are transmitted in the same or in a different data transmission to the certificate authority. For example, when the administrator device issues the credential to the user, the administrator device automatically transmits all three pieces of information to the certificate authority. In another example, when the user device receives the credential from the administrator device or when it generates the credential and determines that the credential needs to be signed, the user device transmits the credential to the certificate authority and notifies the administrator device of such a transmission. In turn, the administrator device transmits the restriction to the certificate authority with a request to bind it to the credential and the user information.

Operation508illustrates the certificate authority generating the digital certificate. In an example, the certificate authority verifies that the user is properly associated with the credential. The verification can include a domain validation or extended validation. For example, the trusted party contacts the administrator to verify the credential by way of an electronic communication, such as an email sent to a known address of the administrator. The electronic communication describes, hashes, or copies the credential, the user information and the authorization policy and embeds a link for approving the information. Once approved, the certificate authority assembles the credential, the user information and the authorization policy in a document and signs the document using a private key associated with the certificate authority to generate the digital certificate. Operation510illustrates the certificate authority transmitting the digital certificate to the user or administrator device.

Once the digital certificate is issued to the user, the user can operate the user device to present the digital certificate to a server. The server uses the digital certificate to facilitate an operation of the computing device based on the authorization policy embedded in the digital certificate. For example, the server facilitates a connection of the computing device to the server or to a computing environment that the server may be associated with. The computing environment uses the server or components other than the server to further authenticate the user and authorize the user device to access resources associated with the computing environment.

FIG. 6illustrates an example system for using the digital certificate to authenticate the user and to authorize his or her operations in conjunction with access to computing resources gated and services provided by the server. The illustrated system600includes a user device610and a server620interconnected by a communication network and may implement some or all elements of system100ofFIG. 1, system200ofFIG. 2and system400ofFIG. 4. User device610stores a digital certificate612that is issued to the user and that is similar to digital certificate422ofFIG. 4, for example. More particularly, digital certificate612binds a credential612A, user information612B and an authorization policy612C.

Server620may include some or all elements of servers130and140ofFIG. 1or any computing device that can be used as part of an access point to a network-based service. The network-based service includes, for example, a website hosting service, a logon service for logging into computers, a multimedia content streaming service, a compute service, a data storage service and the like.

Access to the functionality provided by any of the services associated with server620may be performed in various ways that include enforcing authorization policy612C independent of an access rule622associated with the server or in conjuncture with the access rule. When the enforcement is independent of access rule622, server620authenticates the user based on digital certificate612, retrieves authorization policy612C and allows the use of credential612A based on the rule specified in the policy. For example, after authenticating the user and determining that he or she is authorized to access the multimedia content streaming service based on digital certificate612, server620encrypts the multimedia content with credential612A and streams the encrypted content to user device610. Likewise, to provide the website hosting service, server620and user device610can establish a secure connection630that uses a TLS protocol. This secure connection can use credential612A along with a server's public key in a TLS handshake to establish a secret that is shared and used to encrypt data exchanged between client device610and server620.

When access rule622is used in conjuncture with authorization policy612C, the access rule is configured to provide another authorization layer for authorizing the user to access the computing resources or services associated with server620. In an example, access rule622includes a profile that is associated with the user and that specifies the operations that the user can perform. In this example, the digital certificate can be provided to the user in the form of smart card that can be inserted in user device610. However, when the smart card is lost or stolen, the user's profile is updated to indicate this status and to specify that access to server620by way of the digital certificate should be denied. Thus, when a third party inserts the smart card into a computing device and connects to server620, the server does not authorize the access of the third party.

In another example, access rule622may allow server620to provide user device610with partial access to the services even when the user is authenticated and authorized based on digital certificate612. In this example, server620may host two sets of content that are located in Ohio. Access rule622requires the server to stream the first set using a 40-bit key encryption and the second set using a 60-bit key encryption. Although authorization policy612C allows the user to access content hosted in Ohio, when credential612A is a 40-bit key, server620streams the first set of content to user device610and denies access to the second set.

Further, access rule622may be configured to customize the access to server620. For example, when two users are issued two different digital certificates that contain the same authorization policy, access rule620can differentiate the services provided by server620to both users. In this example, after authenticating and authorizing each user based on the corresponding digital certificate, access rule622authorizes server620to provide access of the first user to all of its services and access of the second user to only the website hosting and multimedia content streaming services.

FIG. 7is a flowchart depicting an example procedure that a server, such as server620ofFIG. 6, may perform to provide access to the user device by way of the digital certificate and the access rule as applicable. Operation702illustrates the server receiving a request to establish, for example, a secure communication session using a SSL protocol based on the digital certificate. Operation704illustrates the server authenticating the user based on the digital certificate. This authentication is performed based on, for example, a lightweight directory access protocol (LDAP) that is included in the access rule of the server.

Operation706illustrates the server comparing the authorization policy of the digital certificate to requirements of the access rule after authenticating the user to determine the level of access that the user is authorized to have. Operation708illustrates the server establishing the secure communication and providing the user device access to the computing resources and services associated with the server based at least in part on the comparison. For example, the authorization policy allows the user to use his or her public key to only access a computing resource in Utah while the access rule requires the server to strictly adhere to the policy. In this case, if the requested computing resource is located outside of Utah, the server denies the user device from accessing the resource and terminates the secure communication session. If the access rule also requires the server to notify an administrator of the user of a violation of the policy, the server retrieves contact information of the administrator from the digital certificate and sends a notification in the form of an electronic communication to an address contained in the contact information.

When the user device is provided access to the server, its resources or its services, such an access includes various uses of the user's credential. One use includes establishing secure communications between the user device and the server. For example, the user's credential is used to generate a new key that is shared between the user device and the server and that is used to encrypt subsequent communications between the two network nodes. A second includes encrypting data that is uploaded to the server. For example, when the user device transmits data to the server for storage, the server encrypts the data using the user's credential. Yet another use includes retrieving data stored on the server. For example, the server generates a temporary key and encrypts data stored at the server with this key. To provide the user device access to the encrypted data, the server encrypts the temporary key with the user's public key and transmits the encrypted data and the encrypted temporary key to the user device. In turn, the user device decrypts the temporary key using the client's private key and subsequently decrypts the data using the decrypted temporary key. These and other uses are further described inFIGS. 8 and 9.

FIG. 8illustrates server620providing a data service830to user device610ofFIG. 6in response to a data request812received from the user device. This service is provided after authenticating the user and verifying that authorization policy612C and access control rule622authorize the service. In an example, data service830includes transmitting data824from server620to user device610and implements a secure mechanism to protect the data.

The secure mechanism includes multiple layers of data encryption. As described herein above, user device610and server620share a cipher, shown inFIG. 8as a shared key826, that the server uses to encrypt data824. The server also encrypts the encrypted data and shared key826with the user's credential612A for transmission to the user device. To access data824, user device610decrypts the received information using the user's private key to retrieve shared key826and decrypts data824based on the decrypted shared key.

FIG. 9is a flowchart depicting an example procedure for providing data service830ofFIG. 8and may be performed by server620and user device610. Operation902illustrates the server authenticating the user based on the digital certificate associated. Operation904illustrates the server verifying that the user is authorized to access data managed by the server based on the digital certificate and, as applicable, based on the access rule. When the user is authorized, the server allows the data access by executing any of operations906,908and920-924.

Operation906illustrates the server retrieving the credential, such as a public key, associated with the user from the digital certificate. Operation906may be followed by operation908or operation920based on various secure mechanisms that may be implemented by one skilled in the art. Operation908illustrates the server encrypting the data using the user's public key and transmitting the encrypted data to the user device. Operation910illustrates the user device decrypting the received data using the user's private key associated with the user's public key.

Operation920illustrates the server encrypting the data with a secret. The secret can be a shared key that the server shares with the user device. The secret can also be associated with a connection session between the user device and the server and can be disposed of when the server terminates the secure connection. Operation922illustrates the server encrypting the secret with the user's public key. This encryption protects the secret from being used by a computing device other than the user device and the server. The server also encrypts the data with the secret, which results in a first set of encrypted data. The server further encrypts the first set with the user's public key, which results in a second set of encrypted data. The second set provides additional protection to the data because of the dual encryption. This layering of encryption can be repeated by using additional secrets and public keys associated with the user.

Operation924illustrates the server transmitting the encrypted secret and the second set of encrypted data to the user device. Operation926illustrates the user device receiving the encrypted secret and decrypting the secret using the user's private key. The user device also decrypts the received data with the user's private key to retrieve the first layer of encrypted data. Operation928illustrates the user device retrieving the secret and decrypting the first layer of encrypted data using the retrieved secret. The user device retrieves and processes the data from the decrypted first layer for display to the user at a user interface.

It should be appreciated that the network topologies illustrated in the figures have been greatly simplified and that many more networks and networking devices may be utilized to interconnect the various computing systems disclosed herein. These network topologies and devices should be apparent to those skilled in the art.

It should also be appreciated that the systems in the figures are merely illustrative and that other implementations might be utilized. Additionally, it should be appreciated that the functionality disclosed herein might be implemented in software, hardware or a combination of software and hardware. Other implementations should be apparent to those skilled in the art. It should also be appreciated that a server, gateway or other computing device may comprise any combination of hardware or software that can interact and perform the described types of functionality, including without limitation desktop or other computers, database servers, network storage devices and other network devices, PDAs, tablets, cellphones, wireless phones, pagers, electronic organizers, Internet appliances, television-based systems (e.g., using set top boxes and/or personal/digital video recorders) and various other consumer products that include appropriate communication capabilities. In addition, the functionality provided by the illustrated modules may in some embodiments be combined in fewer modules or distributed in additional modules. Similarly, in some embodiments the functionality of some of the illustrated modules may not be provided and/or other additional functionality may be available.

A computing node, such as a user device, an administrator device, a certificate authority or a server, may be implemented on a wide variety of computing environments, such as commodity-hardware computers, virtual machines, computing clusters and computing appliances. Any of these computing devices or environments may, for convenience, be described as computing nodes.