Hybrid Content Protection Architecture for Email

Abstract

The computer-implemented method (400), when executed by data processing hardware (18) of a user device (10), causes the data processing hardware to perform operations. These operations include obtaining, from a message server (160), an encrypted message (152E) encrypted with a single-use data encryption key (DEK) (170) and an encrypted DEK (170E) including the single-use DEK encrypted with a public key (PK) (172PK). The operations also include sending a decryption request (210) to a key access control list server (KACLS) (50) requesting the KACLS to decrypt the encrypted DEK with a private key (PRK) (172PRK) associated with the PK. The decryption request includes the encrypted DEK. The KACLS is independent of the message server. The operations also include receiving the single-use DEK from the KACLS and using the single-use DEK to decrypt the encrypted message.

Description

[Technical field]

[0001] The present disclosure relates to a hybrid content protection architecture for messaging services such as email. [Background technology]

[0002] Encryption is becoming one of the most important tools in use to ensure confidentiality and authenticity of messages between users. These messages are often passed through message servers (e.g., email servers) that are not under the control of the user sending and / or receiving the message. Users can rely on the email server for encryption and decryption, allowing the email server to access unencrypted messages. To maximize privacy, some users employ client-side encryption, which involves the user encrypting the message before sending it to the message server for delivery. Summary of the Invention

[0003] One aspect of the present disclosure provides a method for providing a hybrid content protection architecture. The computer-implemented method, when executed by data processing hardware of a user device, causes the data processing hardware to perform operations. The operations include obtaining, from a message server, an encrypted message encrypted by a single-use data encryption key (DEK) and an encrypted DEK including the single-use DEK encrypted by a public key (PK). The single-use DEK may be used only to encrypt the encrypted message. The operations also include sending a decryption request to a key access control list server (KACLS), requesting the KACLS to decrypt the encrypted DEK by a private key (PRK) associated with the PK. The decryption request may include the encrypted DEK. The KACLS is independent and / or distinct from the message server. The operations also include receiving the single-use DEK from the KACLS and decrypting the encrypted message using the single-use DEK.

[0004] Embodiments of the present disclosure may include one or more of the following optional features: In some embodiments, the decryption request is configured to cause the KACLS to obtain an encrypted PRK from the message server, the PRK including the PRK encrypted by a private KACLS key, decrypt the encrypted PRK using the private KACLS key, decrypt the encrypted DEK using the PRK, send the single-use DEK to the user device, and discard the PRK. In some of these embodiments, the private KACLS key includes a symmetric key owned only by the KACLS.

[0005] In some examples, the decryption request is configured to cause the KACLS to authenticate the user of the user device with the message server and to authenticate the user of the user device with a third-party identity provider independent of the message server. Optionally, further operations include obtaining a second message, generating a second single-use DEK, encrypting the second message using the second single-use DEK, sending an encryption request to the KACLS requesting the KACLS to encrypt the second single-use DEK with the PRK, receiving from the KACLS a second encrypted DEK including the second single-use DEK encrypted with the PRK, and sending the encrypted second message and the second encrypted DEK to the message server. In some implementations, the second message is obtained using the Secure / Multipurpose Internet Mail Extensions (S / MIME) standard.

[0006] In some examples, the message server does not receive the PRK or access to the decrypted message. Optionally, the PK and the PRK comprise an asymmetric key pair. The message server may store the PK. In some implementations, the encrypted message comprises an email and the message server comprises an email service.

[0007] Another aspect of the present disclosure provides a system for providing a hybrid content protection architecture. The system includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that, when executed by the data processing hardware, cause the data processing hardware to perform operations. The operations include obtaining from a message server an encrypted message encrypted by a single-use data encryption key (DEK) and an encrypted DEK including the single-use DEK encrypted by a public key (PK). The single-use DEK may be used only to encrypt the encrypted message. The operations also include sending a decryption request to the KACLS requesting the KACLS to decrypt the encrypted DEK by a PRK associated with the PK. The decryption request may include the encrypted DEK. The KACLS is independent and / or separate from the message server. The operations also include receiving the single-use DEK from the KACLS and using the single-use DEK to decrypt the encrypted message.

[0008] This aspect may include one or more of the following optional features: In some embodiments, the decryption request is configured to cause the KACLS to obtain an encrypted PRK from the message server, the PRK including the PRK encrypted by a private KACLS key, decrypt the encrypted PRK using the private KACLS key, decrypt the encrypted DEK using the PRK, send the single-use DEK to the user device, and discard the PRK. In some of these embodiments, the private KACLS key includes a symmetric key owned only by the KACLS.

[0009] In some examples, the decryption request is configured to cause the KACLS to authenticate the user of the user device with the message server and to authenticate the user of the user device with a third-party identity provider independent of the message server. Optionally, further operations include obtaining a second message, generating a second single-use DEK, encrypting the second message using the second single-use DEK, sending an encryption request to the KACLS requesting the KACLS to encrypt the second single-use DEK with the PRK, receiving from the KACLS a second encrypted DEK including the second single-use DEK encrypted with the PRK, and sending the encrypted second message and the second encrypted DEK to the message server. In some implementations, the second message is obtained using the Secure / Multipurpose Internet Mail Extensions (S / MIME) standard.

[0010] In some examples, the message server does not receive the PRK or access to the decrypted message. Optionally, the PK and the PRK comprise an asymmetric key pair. The message server may store the PK. In some implementations, the encrypted message comprises an email and the message server comprises an email service.

[0011] The details of one or more embodiments of the disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will become apparent from the description and drawings, and from the claims. [Brief description of the drawings]

[0012] [Figure 1] 1 is a schematic diagram of an example system for a hybrid content architecture for message sharing. [Diagram 2] FIG. 2 is a schematic diagram of exemplary components of the system of FIG. 1. [Figure 3A] FIG. 2 is a sequence diagram for the operation of the system of FIG. [Figure 3B] FIG. 2 is a sequence diagram for the operation of the system of FIG. [Figure 4] 1 is a flowchart of an example arrangement of operations for a method of providing a hybrid content architecture for message sharing. [Diagram 5] FIG. 1 is a schematic diagram of an example computing device that can be used to implement the systems and methods described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] Like reference symbols in the various drawings indicate like elements. Encryption is becoming one of the most important tools in use to ensure confidentiality and authenticity of messages between users. These messages are often passed through message servers (e.g., email servers) that are not under the control of the user sending and / or receiving the message. Users can rely on public email servers to encrypt messages, allowing the email servers to access unencrypted messages. To maximize privacy, some users employ client-side encryption, which involves the user encrypting messages before sending them to the message server for delivery.

[0014] However, client-side encryption relies on users being able to securely and easily share a key for decryption. This is most commonly accomplished with public key cryptography, consisting of a public key (which may be shared with others) and a private key (which can only be shared with the owner). Data encrypted with a pair's private key can only be decrypted with the associated public key, and similarly, data encrypted with a pair's public key can only be decrypted using the private key. The private key can also be used to perform digital signatures on content, which can be verified using the public key. Thus, if two users each share their respective public keys, the users can communicate securely as long as their respective private keys remain secret.

[0015] In this scenario, if the private key of one of the users is compromised by an attacker, not only does the attacker gain access to all previous emails encrypted with the associated public key, but the attacker also gains the ability to impersonate the user (i.e., by digital signature). Therefore, keeping the private key secret is of utmost importance.

[0016] Users are increasingly relying on multiple devices to send and receive messages. For example, users send and receive email via mobile phones, laptops, desktops, and tablets. Traditional client-side encryption schemes require a user to maintain a private key on each user device that the user uses to share messages. Not only is this inconvenient for the user (the user must ensure that each device is kept up to date with the latest private key), but each device further increases the risk of exposure to the private key(s). If an attacker gains access to any of the devices, the private key for that device can be compromised, allowing the attacker to access all messages decrypted by that key.

[0017] Embodiments herein provide a hybrid content protection architecture for message sharing (e.g., email). The architecture includes a trusted key access control list server that is separate and independent of any message server that a user uses to send or receive messages. The key access control list server provides the only access to a user's private key, ensuring that the message server does not have access to the private key or unencrypted messages, relieving the user of the burden of maintaining the private key across multiple devices. The key access control server may additionally employ audit features that allow users detailed information regarding their private key usage and limit damage in the event that the user's authentication credentials are compromised.

[0018] Referring to FIG. 1, in some implementations, an exemplary message protection system 100 includes a remote system 140 that communicates with one or more user devices 10 via a network 112. The remote system 140 may be a single computer, multiple computers, or a distributed system (e.g., a cloud environment) having scalable / elastic resources 142 including computing resources 144 (e.g., data processing hardware) and / or storage resources 146 (e.g., memory hardware). A data store 150 (i.e., a remote storage device) may be overlaid on the storage resources 146, allowing for scalable use of the storage resources 146 by one or more of the clients (e.g., the user devices 10) or computing resources 144. The data store 150 is configured to store multiple messages 152, 152a-n. In some examples, the messages 152 include emails, but may also store any other type of communication (e.g., any text message, audio message, and / or video message). The data store 150 may store any number of messages 152 at any one time. In some examples, as described in more detail below, some or all of the stored messages 152 are encrypted messages 152, 152E, 152Ea-n.

[0019] The remote system 140 runs a message server 160. The message server 160 (e.g., an email server or mail server) is configured to receive messages 152 from users 12 (via user devices 10) and deliver the messages 152 to other users 12. For example, the message server 160 may include an email server to send and receive emails. The message server 160 may use any conventional technology (e.g., Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), Internet Message Access Protocol (IMAP), HTTPS API, custom protocols, etc.) for sending and receiving messages 152 and may include any number of subcomponents (e.g., an incoming message server, an outgoing message server, a list server, policy, a webmail server, etc.).

[0020] The message server 160 is configured to receive messages 152 from user devices 10 associated with respective users 12, for example, via the network 112. The user devices 10 may correspond to any computing device, such as a desktop workstation, a laptop workstation, or a mobile device (i.e., a smartphone). The user devices 10 include computing resources 18 (e.g., data processing hardware) and / or storage resources 16 (e.g., memory hardware). The users 12 may draft and send messages 152 to the message server using a web browser, a standalone application executing on the user device 10, or any other suitable means.

[0021] In some implementations, the first user device 10, 10a of the first user 12, 12a executes a client encryption controller 180. The client encryption controller 180 retrieves an encrypted message 152E from the message server 160. The encrypted message 152E was drafted by the second user 12, 12b using the second user device 10, 10b. In some examples, the second user 12b (via the second user device 10b) encrypts the encrypted message 152E using a single-use data encryption key (DEK) 170. The single-use DEK 170 represents an encryption key that is randomly generated to encrypt only a single message 152. After the message 152 is encrypted by the single-use DEK 170, the DEK 170 cannot be used again (i.e., to encrypt another message 152) for security purposes.

[0022] The client encryption controller 180 also obtains the encrypted DEK 170, 170E in addition to the encrypted message 152E. The encrypted DEK 170E represents a single-use DEK 170 encrypted by a public key (PK) 172, 172PK. In some examples, the PK 172PK is an asymmetric public key. The asymmetric public key is associated with the user 12a (i.e., the first user 12a) who is the intended recipient of the message 152 and is linked with the PRK 172PRK owned by the first user 12a. Thus, to gain access to the encrypted message 152E, the DEK 170E needs to be decrypted using the PRK 172PRK of the user 12a. The second user 12b may send the encrypted message 152E to the message server 160 via a message server 30 associated with the second user 12b. This message server 30 may be the same as the message server 160 of the first user 12a or may be a completely different service. The second user 12b may encrypt the message 152 locally on the second user device 10b or may rely on the message server 30 (although this allows the second user's message server 30 to access the unencrypted message 152).

[0023] After the first user device 10a obtains the encrypted message 152E and the encrypted DEK 170E, it sends a decryption request 210 to a key access control list server (KACLS) 50. The decryption request 210 requests the KACLS 50 to decrypt the encrypted DEK 170E with the PRK 172PRK of the first user 12a. In some examples, the decryption request 210 includes the encrypted DEK 170E for the KACLS 50 to decrypt. Optionally, the KACLS is independent and separate from the message server 160. That is, the message server 160 does not have access to the keys controlled by the KACLS 50. Similarly, the KACLS 50 does not have access to the messages 152 stored, maintained, sent, or received by the message server 160. The KACLS 50 may run on a completely independent hardware that communicates with the message server 160 and / or the first user device 10a over a network.

[0024] The KACLS 50 uses PRK172PRK, which is a private key related to PK172PK used by the second user 12b to encrypt the DEK 170, to decrypt the single-use DEK 170 used to encrypt the message 152. The first user device 10a receives the decrypted single-use DEK 170 from the KACLS 50. The first user device 10a uses the decrypted single-use DEK 170 received from the KACLS 50 to decrypt the message 152 for viewing by the first user 12a. In this manner, the first user 12a obtains access to the message 152 composed by the second user 12b without the message server 160 obtaining access to the decrypted message 152 (because the message server 160 lacks access to PRK172PRK), without the KACLS50 obtaining access to the decrypted message 152 (because KACLS50 lacks access to the encrypted message 152E), and without the first user device 10a maintaining PRK172PRK locally.

[0025] 2, as shown in schematic diagram 200, by relying on KACLS 50, user 12a is relieved of the responsibility of ensuring that each user device 10a, 10aa-an is provisioned with the same PRK 172PRK. Instead, user 12a is free to use any number of user devices 10 to decrypt encrypted messages 152E received from message server 160. Instead of each user device 10a of first user 12a being provisioned with a PRK 172PRK, a decryption request 210 is sent to KACLS 50, which uses PRK 172PRK to decrypt the encrypted single-use DEK 170E provided by decryption request 210.

[0026] In some embodiments, KACLS 50 authenticates and / or authorizes user device 10a and / or user 12a before decrypting DEK 170E. KACLS 50 may request credentials 214 (e.g., username and password, authorization token, multi-factor authentication response, etc.) from user 12a. In some examples, KACLS 50 performs multiple authentication steps. For example, KACLS 50 authenticates user 12a and / or user device 10a with message server 160 (i.e., the service provider that provides message server 160) in addition to authenticating user 12a and / or user device 10a via a third-party identity provider that is independent of KACLS 50 and message server 160.

[0027] In some examples, KACLS 50 stores (e.g., in a database) a copy of PRK 172PRK for each user 12 that KACLS 50 serves. In these examples, in response to receiving a decryption request 210, KACLS 50 retrieves from storage the PRK 172PRK associated with the user 12 of the decryption request 210. In other examples, however, KACLS 50 decrypts DEK 170 in a stateless manner. That is, KACLS 50 does not maintain a repository of PRK 172PRK. Instead, during an initialization or setup routine that provisions or creates an account for user 12a, KACLS 50 encrypts user 12a's PRK 172PRK with KACLS encryption key 230. KACLS encryption key 230 is, for example, a symmetric key available only to KACLS 50. KACLS 50 or user 12a then provides the encrypted PRK 172EPRK (i.e., PRK 172PRK encrypted by KACLS encryption key 230) to message server 160, which stores the encrypted PRK 172EPRK on behalf of user 12a. For example, message server 160 includes a PRK data store 240 that stores the encrypted PRKs 172EPRK, 172EPRKa through 172EPRKn, for each user 12 of message server 160.

[0028] In these examples, in response to the user 12 sending the decryption request 210 to the KACLS 50, the KACLS 50 obtains the encrypted PRK172EPRK from the message server 160. For example, the KACLS 50 uses the key request 220 to request the appropriate encrypted PRK172EPRK from the message server 160 (e.g., by a user ID or other identifier that identifies which encrypted PRK172EPRK the message server 160 needs to obtain). The decryption request 210 may include an identifier to identify the encrypted PRK172EPRK that the KACLS 50 needs to obtain from the message server 160. The message server 160 never has access to the decrypted PRK172PRK, so it obtains the encrypted PRK172EPRK from the data store 240 and sends the encrypted PRK172EPRK to the KACLS 50. After receiving the encrypted PRK172EPRK from the message server 160, the KACLS 50 uses the KACLS encryption key 230 to decrypt the encrypted PRK172EPRK. With the decrypted PRK172PRK, KACLS50 may proceed to obtain the decrypted single-use DEK170 as described with respect to FIG. 1. That is, KACLS50 transmits the single-use DEK170 to the user device 10. After recovering the decrypted single-use DEK170, KACLS50 may discard (i.e., purge from memory) the decrypted PRK172PRK, so KACLS50 needs to request the encrypted PRK172EPRK from the message server 160 for future decryption requests 210. In some embodiments, KACLS50 may maintain a cache that temporarily stores the encrypted PRK172EPRK for a threshold period of time to reduce requests 210 to the message server 160.

[0029] In other examples, the message server 160 also includes the encrypted PRK 172EPRK when delivering the encrypted message 152E and the encrypted DEK 170E to the user device 10a. That is, the message server 160 automatically includes the encrypted PRK 172EPRK in each encrypted message 152E delivered to the user device 10a. In these examples, the user device 10a includes the encrypted PRK 172EPRK in the decryption request 210, allowing the KACLS 50 to recover the PRK 172PRK without having to query the message server 160.

[0030] 3A, a sequence diagram 300a provides an exemplary sequence of operations for the first user device 10a to receive and decrypt an encrypted message 152E sent by the second user device 10b. In operation 302, the second user device 10b (or alternatively, the message server 30 on behalf of the second user device 10b) sends the encrypted message 152E to the message server 160 of the first user 12a. The encrypted message 152E is accompanied by the encrypted DEK 170E used to encrypt the encrypted message 152E. The encrypted DEK 170E is encrypted using the PK 172PK of the first user 12a. In operation 304, the message server 160 delivers the encrypted message 152E and the encrypted DEK 170E to the first user device 10a. In operation 306, the first user device 10a sends a decryption request 210 to the KACLS 50. In some examples, the decryption request 210 includes the encrypted DEK 170E and / or an identifier that identifies the user 12a and / or the user device 10a. In some implementations, the KACLS 50 retrieves the encrypted DEK 170E from the message server 160. The KACLS 50 may perform one or more authentications / authorizations of the user device 10a and / or the user 12a. The decryption request 210 may include credentials 214 for authenticating the user device 10a or the user 12a.

[0031] Optionally, the KACLS 50 sends a key request 220 to the message server 160 in operation 308. The key request 220 may include identification and / or authentication of the user 12a or the user device 10a. In response, in operation 310, the message server 160 provides the encrypted PRK172EPRK to the KACLS 50. In operation 312, optionally, the KACLS 50 decrypts the encrypted PRK172EPRK and uses the decrypted PRK172PRK to decrypt the encrypted DEK170E. In operation 314, the KACLS 50 sends the decrypted DEK170 to the first user device 10a. Communications between the KACLS 50 and the first user device 10a may be further secured (e.g., via HTTPS) to ensure confidentiality of the decrypted DEK170. In operation 316, the first user device 10a decrypts the encrypted message 152E using the decrypted DEK 170 to obtain the decrypted message 152 originally composed by the second user 12b.

[0032] Referring back to FIG. 1, in some embodiments, the KACLS 50 supports the user device 10a to encrypt the constructed message 152 in a manner similar to that for decrypting the received message 152. For example, to allow the recipient of the message 152 (e.g., the second user 12b) to authenticate the source of the message 152, the first user 12a may rely on the KACLS 50 to digitally "sign" the message 152 by encrypting some or all of the message 152 or the message's attachments using the PRK 172PRK. In this scenario, the first user 12a may create the message 152 and then generate a random DEK 170 to encrypt the message 152 and / or the attachments. The first user device 10a may send an encryption request 212 including the generated DEK 170 to the KACLS 50. The KACLS 50 encrypts the DEK 170 with the PRK 172PRK after authenticating the user 12a and / or the user device 10a in a manner similar to that described above. The first user device 10a sends the signed message 152S and the encrypted DEK 170E to the message server 160 for delivery to the recipient of the message 152 (eg, the second user device 10b).

[0033] 3B, a sequence diagram 300b provides an exemplary sequence of operations for a first user device 10a to create and sign / encrypt a message 152 for transmission to a second user device 10b. Here, in operation 320, the first user 12a creates a message 152 for transmission to a second user 12b via the first user device 10a. The first user device 10a generates a random single-use DEK 170 (i.e., a key that has not been used to encrypt a previous communication) and, in operation 322, signs the message 152 with the DEK 170. The first user device 10a sends an encryption request 212 to the KACLS 50, in operation 324. The encryption request 212 may include the DEK 170.

[0034] In some embodiments, the KACLS 50 sends a key request 220 to the message server 160 to obtain the encrypted PRK 172 EPK associated with the first user 12a in operation 326. In operation 328, the message server 160 returns the encrypted PRK 172 EPK associated with the first user 12a to the KACLS 50. The KACLS 50 encrypts the DEK 170 with the PRK 172 PRK to generate the encrypted DEK 170E in operation 330. In operation 332, the KACLS 50 returns the encrypted DEK 170E to the first user device 10a. In operation 336, the first user device 10a sends the signed message 152S to the message server 160 along with the encrypted DEK 170E. The message server 160, in operation 338, delivers the signed message 152S and the encrypted DEK 170E to the second user device 10b (or alternatively, another message server 30 associated with the second user 12b). The second user device 10b can decrypt the encrypted DEK 170E using the PK 172PK associated with the first user 12a, thus ensuring the authenticity of the message 152 (i.e., the digital signature) without revealing the first user's PRK 172PRK to the message server 160. Although not shown here, it will be appreciated that the first user device 10a can additionally or alternatively encrypt the message 152 to ensure confidentiality, for example, using the PK 172PK associated with the second user 12b.

[0035] Referring back to FIG. 1, in some examples, the first user device 10a runs the client encryption controller 180, but the second user device 10b does not. In these scenarios, the system 100 may implement various features of, for example, the S / MIME (Secure / Multipurpose Internet Mail Extensions) standard to ensure interoperability of messages communicated between the first user device 10a and the second user device 10b. In this manner, the system 100 does not require each user device 10 to run the client encryption controller 180; instead, the system may be integrated with traditional client-side encryption techniques. In other examples, both the first user device 10a and the second user device 10b run separate client encryption controllers 180, so that both perform operations similar to those described in FIGS. 3A-3B when sending and receiving messages from the other user device 10. In these examples, the message server 160 may serve both users 12a, 12b (e.g., both users 12a, 12b subscribe to the same email service). The system 100 may support any number of symmetric ciphers (e.g., AES-256-GCM, AES-128-GCM, AES-256-CBC, AES-128-CBC, ChaCha20-Poly1305, 3DES, etc.) and asymmetric ciphers (e.g., ECDH, RSA, SHA-256, MD5, etc.).

[0036] In some examples, the message server 160 maintains a directory or list 162 of PKs 172PK to facilitate message transmission between the first user 12a and the second user 12b. For example, the message server 160 maintains a list 162 that associates PKs 172PK (and / or certificates) with specific users 12. In this manner, the client encryption controller 180 may query the message server 160 to obtain the public key 172PK of another user 12 for encryption or decryption of a message 152.

[0037] In some embodiments, the KACLS 50 includes an auditor 52. The auditor 52, in some examples, monitors and records all usage of the PRK172PRK. For example, when the auditor 52 receives a decryption request 210 or an encryption request 212, it logs information about the request, such as the date and time, user identification, and purpose of the request. Thus, in the event of a compromise, the log can be reviewed (e.g., by an authorized user 12) to determine the extent of the damage. In some examples, the auditor 52 enforces access control of the PRK172PRK. For example, all authorized users 12 of the PRK172PRK can be associated with roles that limit the scope of use of the PRK172PRK. For example, only users 12 with a role of "signer" can be permitted to sign a message 152 using the PRK172PRK. As another example, only users 12 with a role of "decryptor" can be permitted to decrypt an encrypted message 152E using the PRK172PRK, but not permitted to perform other actions (e.g., signing). If the auditor 52 authenticates / authorizes the user 12 via the credentials 214, the auditor 52 may verify the role of the user 12. The auditor 52 may perform a variety of other security roles. For example, the auditor 52 may perform certificate validation to ensure that a Transport Layer Security (TLS) certificate chain is valid.

[0038] In some embodiments, the KACLS 50 includes a hardware security module (HSM) or a key management service (KSM). In these embodiments, the KACLS 50 performs encryption / decryption operations utilizing the HSM / KSM after authenticating and / or authorizing the user 12a and / or the user device 10a. The HSM may be a physical computing device configured to manage and protect digital keys by various means of tamper resistance. The HSM may be external to the KACLS 50, and the KACLS 50 may send encryption / decryption requests to the HSM. In this manner, the KACLS 50 may primarily function as an identity authentication / verification gateway for the user 12a to access the HSM. That is, since the HSM typically requires a complex level of trust to be established for communication (e.g., server-to-server communication), the KACLS 50 may function as a gateway for the user 12a to access the encryption and decryption functions of the HSM.

[0039] 4 is a flowchart of an exemplary operational arrangement of a method 400 for providing a hybrid content protection architecture for transmitting encrypted messages. The computer-implemented method 400, when executed by the data processing hardware 18 of the user device 10, causes the data processing hardware 18 to perform operations. The method 400 includes, in operation 402, obtaining an encrypted message 152E from the message server 160, the message 152E being encrypted by a single-use DEK 170. The single-use DEK may be used only to encrypt the encrypted message 152E. The operation 402 also includes obtaining an encrypted DEK 170E including the single-use DEK 170 encrypted by a PK 172PK. In operation 404, the method 400 includes sending a decryption request 210 to the KACLS 50, requesting the KACLS 50 to decrypt the encrypted DEK 170E by a PRK 172PRK associated with the PK 172PK. The decryption request 210 may include the encrypted DEK 170E. The KACLS 50 is independent of the message server 160. At operation 406, the method 400 includes receiving the single-use DEK 170 from the KACLS 50. At operation 408, the method 400 includes using the single-use DEK 170 to decrypt the encrypted message 152E.

[0040] 5 is a schematic diagram of an exemplary computing device 500 that can be used to implement the systems and methods described herein. Computing device 500 is intended to represent various types of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The components shown, their connections and relationships, and their functionality are for illustrative purposes only and are not intended to limit the implementation of the invention described and / or claimed in this document.

[0041] The computing device 500 includes a processor 510, a memory 520, a storage device 530, a high-speed interface / controller 540 that connects to the memory 520 and a high-speed expansion port 550, and a low-speed interface / controller 560 that connects to a low-speed bus 570 and the storage device 530. Each of the components 510, 520, 530, 540, 550, and 560 are interconnected using various buses and may be mounted on a common motherboard or may exist otherwise as desired. The processor 510 may process instructions for execution within the computing device 500, including instructions stored in the memory 520 or the storage device 530, to display graphical information for a graphical user interface (GUI) on an external input / output device such as a display 580 connected to the high-speed interface 540. In other implementations, multiple processors and / or multiple buses may be used as needed, along with multiple memories and memory types. Also, multiple computing devices 500 may be connected, with each device performing some of the required operations (e.g., as a server bank, a group of blade servers, or a multiprocessor system).

[0042] The memory 520 stores information non-transiently within the computing device 500. The memory 520 may be a computer-readable medium, a volatile memory unit(s), or a non-volatile memory unit(s). The non-transient memory 520 may be a physical device used to temporarily or permanently store programs (e.g., instruction sequences) or data (e.g., program state information) for use by the computing device 500. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electronically erasable programmable read-only memory (EEPROM) (e.g., typically used for firmware such as boot programs). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and disk or tape.

[0043] The storage device 530 can provide mass storage for the computing device 500. In some implementations, the storage device 530 is a computer-readable medium. In various different implementations, the storage device 530 can be a device array, including a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid-state memory device, or a storage area network or other configuration of devices. In additional implementations, the computer program product is tangibly embodied in an information carrier. The computer program product includes instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer-readable or machine-readable medium, such as the memory 520, the storage device 530, or a memory on the processor 510.

[0044] The high-speed controller 540 manages the more bandwidth-intensive operations of the computing device 500, and the low-speed controller 560 manages the less bandwidth-intensive operations. Such an allocation of duties is merely an example. In some implementations, the high-speed controller 540 is coupled to the memory 520, the display 580 (e.g., via a graphics processor or accelerator), and a high-speed expansion port 550 that can accept various expansion cards (not shown). In some implementations, the low-speed controller 560 is coupled to the storage device 530 and the low-speed expansion port 590. The low-speed expansion port 590 may include various communication ports (USB, Bluetooth, Ethernet, wireless Ethernet, etc.) and can connect, via a network adapter or the like, to one or more input / output devices such as a keyboard, a pointing device, a scanner, or a network device such as a switch or router.

[0045] The computing device 500 can be implemented in many different forms, as shown in the figure: for example, it may be implemented as a standard server 500a, or multiple times within a cluster of such servers 500a, as a laptop computer 500b, or as part of a rack server system 500c.

[0046] Various implementations of the systems and techniques described herein may be realized in digital electronic and / or optical circuitry, integrated circuits, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementation in one or more computer programs executable and / or interpretable by a programmable system including at least one programmable processor, which may be specialized or general purpose, coupled to receive data and instructions from the storage system, and to transmit data and instructions to the storage system.

[0047] A software application (i.e., a software resource) may refer to computer software that causes a computing device to perform tasks. In some examples, a software application may be referred to as an "application," "app," or "program." Exemplary applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0048] These computer programs (also known as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented in high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. As used herein, "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., magnetic disk, optical disk, memory, programmable logic circuit (PLD)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives the machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0049] The processes and logic flows described herein can be executed by one or more programmable processors, also referred to as data processing hardware, which execute one or more computer programs to perform functions by operating on input data to generate output. The processors and logic flows can also be executed by special purpose logic circuitry, such as FPGAs (field programmable gate arrays) or ASICs (application specific integrated circuits). Processors suitable for executing computer programs include, by way of example, both general purpose and special purpose microprocessors, as well as one or more processors of any type of digital computer. Generally, a processor receives instructions and data from a read-only memory, a random access memory, or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer also includes one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or is operatively coupled to receive data from or transfer data to them, or both. However, a computer does not require such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including, by way of example, exemplary semiconductor memory devices such as EPROM, EEPROM, and flash memory devices, magnetic disks, such as internal hard disks or removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0050] To provide for interaction with a user, one or more aspects of the present disclosure can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor) or touch screen for displaying information to the user, and optionally a keyboard and pointing device (e.g., a mouse or trackball) by which the user can provide input to the computer. Other types of devices can also be used to provide interaction with a user, for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user can be received in any form, including acoustic, spoken language, or tactile input. Additionally, the computer can interact with the user by sending and receiving documents to a device used by the user, for example, by sending a web page to a web browser on the user's client device in response to a request received from the web browser.

[0051] Although several implementations have been described, it is understood that various modifications can be made without departing from the spirit and scope of the disclosure. Accordingly, other embodiments are within the scope of the following claims.

Claims

1. A computer-implemented method (400) that, when executed by data processing hardware (18) of a user device (10), comprises: From the message server (160), an encrypted message (152E) encrypted by a single-use Data Encryption Key (DEK) (170), said single-use DEK (170) being used only to encrypt said encrypted message (152E); and an encrypted DEK (170E) containing the single-use DEK (170) encrypted by a public key (PK) (172PK); and sending a decryption request (210) to a key access control list server (KACLS) (50) independent of said message server (160), said decryption request (210) requesting said KACLS (50) to decrypt said encrypted DEK (170E) with a private key (PRK) (172PRK) associated with said PK (172PK), said decryption request (210) including said encrypted DEK (170E); receiving the single-use DEK (170) from the KACLS (50); decrypting the encrypted message (152E) using the single-use DEK (170); The method (400), causing the data processing hardware (18) to perform operations including:

2. The decryption request (210) obtaining, via said message server (160), an encrypted PRK (172EPRK) containing said PRK (172PRK) encrypted by a KACLS encryption key (230); decrypting said encrypted PRK (172EPRK) using said KACLS encryption key (230); decrypting the encrypted DEK (170E) using the PRK (172PRK); transmitting the single-use DEK (170) to the user device (10); discarding said PRK (172PRK); The method (400) of claim 1, further configured to cause the KACLS (50) to:

3. 3. The method (400) of claim 2, wherein the KACLS encryption key (230) comprises a symmetric or asymmetric key owned exclusively by the KACLS (50).

4. The decryption request (210) authenticating a user (12) of the user device (10) with the message server (160); authenticating the user (12) of the user device (10) with a third party identity provider independent of the message server (160); The method (400) of any one of claims 1 to 3, configured to cause the KACLS (50) to:

5. The operation includes: Obtaining a second message (152); generating a second single-use DEK (170); encrypting the second message (152) using the second single-use DEK (170); sending an encryption request (212) to the KACLS (50) requesting the KACLS (50) to encrypt the second single-use DEK (170) with the PRK (172PRK); receiving from said KACLS (50) a second encrypted DEK (170E) that includes said second single-use DEK (170) encrypted by said PRK (172PRK); sending the encrypted second message (152E) and the second encrypted DEK (170E) to the message server (160); The method (400) of any one of claims 1 to 4, further comprising:

6. 6. The method (400) of claim 5, wherein the second message (152) is obtained using operations described by the Secure / Multipurpose Internet Mail Extensions (S / MIME) standard.

7. The method (400) of any one of claims 1 to 6, wherein the message server (160) does not receive the PRK (172PRK) or access to the decrypted message (152).

8. The method (400) of any one of claims 1 to 7, wherein the PK (172PK) and the PRK (172PRK) comprise an asymmetric key pair.

9. 10. The method (400) of claim 8, wherein the message server (160) stores the PK (172PK).

10. the encrypted message (152E) comprises an email; The message server (160) includes an email service. The method (400) according to any one of claims 1 to 9.

11. Data processing hardware (18) of the user device (10), and Memory hardware (16) in communication with the data processing hardware (18), the memory hardware (16) storing instructions that, when executed on the data processing hardware (18), From the message server (160), an encrypted message (152E) encrypted by a single-use Data Encryption Key (DEK) (170), said single-use DEK (170) being used only to encrypt said encrypted message (152E); and an encrypted DEK (170E) containing the single-use DEK (170) encrypted by a public key (PK) (172PK); and sending a decryption request (210) to a key access control list server (KACLS) (50) independent of said message server (160), said decryption request (210) requesting said KACLS (50) to decrypt said encrypted DEK (170E) with a private key (PRK) (172PRK) associated with said PK (172PK), said decryption request (210) including said encrypted DEK (170E); receiving the single-use DEK (170) from the KACLS (50); decrypting the encrypted message (152E) using the single-use DEK (170); the memory hardware causing the data processing hardware (18) to perform operations including A system (100).

12. The decryption request (210) obtaining, via said message server (160), an encrypted PRK (172EPRK) containing said PRK (172PRK) encrypted by a KACLS encryption key (230); decrypting said encrypted PRK (172EPRK) using said KACLS encryption key (230); decrypting the encrypted DEK (170E) using the PRK (172PRK); transmitting the single-use DEK (170) to the user device (10); discarding said PRK (172PRK); The system (100) of claim 11, configured to cause the KACLS (50) to:

13. 13. The system (100) of claim 12, wherein the KACLS encryption key (230) comprises a symmetric or asymmetric key owned solely by the KACLS (50).

14. The decryption request (210) authenticating a user (12) of the user device (10) with the message server (160); authenticating the user (12) of the user device (10) with a third party identity provider independent of the message server (160); The system (100) of any one of claims 11 to 13, configured to cause the KACLS (50) to:

15. The operation includes: Obtaining a second message (152); generating a second single-use DEK (170); encrypting the second message (152) using the second single-use DEK (170); sending an encryption request (212) to the KACLS (50) requesting the KACLS (50) to encrypt the second single-use DEK (170) with the PRK (172PRK); receiving from said KACLS (50) a second encrypted DEK (170E) that includes said second single-use DEK (170) encrypted by said PRK (172PRK); sending the encrypted second message (152E) and the second encrypted DEK (170E) to the message server (160); The system (100) of any one of claims 11 to 14, further comprising:

16. 16. The system (100) of claim 15, wherein the second message (152) is obtained using operations described by the Secure / Multipurpose Internet Mail Extensions (S / MIME) standard.

17. The system (100) of any one of claims 11 to 16, wherein the message server (160) does not receive the PRK (172PRK) or access to the decrypted message (152).

18. The system (100) of any one of claims 11 to 17, wherein the PK (172PK) and the PRK (172PRK) comprise an asymmetric key pair.

19. 20. The system (100) of claim 18, wherein the message server (160) stores the PK (172PK).

20. the encrypted message (152E) comprises an email; The message server (160) includes an email service. A system (100) according to any one of claims 11 to 19.

Images