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 the 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 users encrypting messages before sending them 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. These operations include obtaining, from a message server, an encrypted message encrypted with a single-use data encryption key (DEK) and an encrypted DEK including the single-use DEK encrypted with 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 with a private key (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 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 destroy 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 the 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 the 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 embodiments, the second message is obtained using the S / MIME (Secure / Multipurpose Internet Mail Extensions) standard.

[0006] In some examples, the message server does not receive access to the PRK or the decrypted message. Optionally, the PK and PRK comprise an asymmetric key pair. The message server may store the PK. In some embodiments, 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 with a single-use data encryption key (DEK) and an encrypted DEK including the single-use DEK encrypted with 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 with 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 decrypting the encrypted message using the single-use DEK.

[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 destroy 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 the 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 the 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 embodiments, the second message is obtained using the S / MIME (Secure / Multipurpose Internet Mail Extensions) standard.

[0010] In some examples, the message server does not receive access to the PRK or the decrypted message. Optionally, the PK and PRK comprise an asymmetric key pair. The message server may store the PK. In some embodiments, 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 be apparent from the description and drawings, and from the claims. [Brief explanation of the drawings]

[0012] [Figure 1] 1 is a schematic diagram of an example system for a hybrid content architecture for message sharing. [Figure 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. 1. [Figure 3B] FIG. 2 is a sequence diagram for the operation of the system of FIG. 1. [Figure 4] 1 is a flowchart of an exemplary arrangement of operations for a method of providing a hybrid content architecture for message sharing. [Figure 5] FIG. 1 is a schematic diagram of an exemplary computing device that can be used to implement the systems and methods described herein. DETAILED DESCRIPTION OF THE INVENTION

[0013] Like reference symbols in the various drawings indicate like elements. Encryption is becoming one of the most important tools in use to ensure the 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 their messages, allowing the email servers to access unencrypted messages. To maximize privacy, some users employ client-side encryption, which involves users 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 achieved with public-key cryptography, which consists of a public key (which may be shared with others) and a private key (which cannot be shared with anyone other than its owner). Data encrypted with a pair of private keys can only be decrypted with the associated public key, and similarly, data encrypted with a pair of public keys 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, maintaining the secrecy of the private key 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 users to maintain a private key on each user device they use to share messages. Not only is this inconvenient for users (users must ensure each device is kept up to date with the latest private key), but each device also increases the risk of exposure to the private key(s). If an attacker gains access to one of the devices, the private key for that device can be compromised, allowing the attacker access to all messages decrypted with 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 from any message servers users use to send and receive messages. The key access control list server provides sole access to users' private keys, ensuring that message servers do not have access to private keys or unencrypted messages, reducing the user's burden in maintaining private keys across multiple devices. The key access control server may additionally employ auditing features that allow users detailed information about their private key usage and limit damage in the event that a 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 clients (e.g., 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 that sends and receives emails. The message server 160 may use any conventional technology for sending and receiving messages 152 (e.g., Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), Internet Message Access Protocol (IMAP), HTTPS API, custom protocols, etc.) and may include any number of subcomponents (e.g., an incoming message server, an outgoing message server, a list server, a 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 embodiments, 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 message 152E, along with the encrypted DEK 170, 170E. 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 to a PRK 172PRK owned by the first user 12a. Thus, to gain access to the encrypted message 152E, the DEK 170E must 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 an entirely 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 obtaining the encrypted message 152E and the encrypted DEK 170E, the first user device 10a 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 first user's 12a PRK 172PRK. 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 message 152 stored, maintained, sent, or received by the message server 160. The KACLS 50 may operate on completely independent hardware that communicates with the message server 160 and / or the first user device 10a over a network.

[0024] KACLS 50 uses PRK172PRK (which is a private key related to PK172PK used by second user 12b to encrypt DEK 170) to decrypt single-use DEK 170 used to encrypt message 152. First user device 10a receives the decrypted single-use DEK 170 from KACLS 50. First user device 10a uses the decrypted single-use DEK 170 received from KACLS 50 to decrypt message 152 for viewing by first user 12a. In this way, the first user 12a gains access to the message 152 composed by the second user 12b without the message server 160 gaining access to the decrypted message 152 (because the message server 160 lacks access to PRK172PRK), without the KACLS50 gaining access to the decrypted message 152 (because the 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, the KACLS 50 stores (e.g., in a database) a copy of the PRK 172PRK for each user 12 that the KACLS 50 serves. In these examples, in response to receiving the decryption request 210, the KACLS 50 retrieves from storage the PRK 172PRK associated with the user 12 of the decryption request 210. However, in other examples, the KACLS 50 decrypts the DEK 170 in a stateless manner. That is, the KACLS 50 does not maintain a repository of the PRK 172PRK. Instead, during an initialization or setup routine that provisions or creates an account for the user 12a, the KACLS 50 encrypts the PRK 172PRK for the user 12a with the KACLS encryption key 230. The KACLS encryption key 230 is, for example, a symmetric key available only to the KACLS 50. KACLS 50 or user 12a then provides encrypted PRK 172EPRK (i.e., PRK 172PRK encrypted by KACLS encryption key 230) to message server 160, which stores encrypted PRK 172EPRK on behalf of user 12a. For example, message server 160 includes PRK data store 240 that stores encrypted PRKs 172EPRK, 172EPRKa-172EPRKn, for each user 12 of message server 160.

[0028] In these examples, in response to user 12 sending decryption request 210 to KACLS 50, KACLS 50 obtains encrypted PRK172EPRK from message server 160. For example, KACLS 50 uses key request 220 to request the appropriate encrypted PRK172EPRK from message server 160 (e.g., by user ID or other identifier that identifies which encrypted PRK172EPRK message server 160 should obtain). Decryption request 210 may include an identifier for identifying the encrypted PRK172EPRK message server 160 should obtain from message server 160. Because message server 160 never has access to the decrypted PRK172PRK, KACLS 50 obtains encrypted PRK172EPRK from data store 240 and sends encrypted PRK172EPRK to KACLS 50. After receiving encrypted PRK172EPRK from message server 160, KACLS 50 decrypts encrypted PRK172EPRK using KACLS encryption key 230. 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 must 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, when message server 160 delivers encrypted message 152E and encrypted DEK 170E to user device 10a, it also includes encrypted PRK 172EPRK. That is, message server 160 automatically includes encrypted PRK 172EPRK in each encrypted message 152E delivered to user device 10a. In these examples, user device 10a includes encrypted PRK 172EPRK in decryption request 210, allowing KACLS 50 to recover PRK 172PRK without having to query message server 160.

[0030] 3A , a sequence diagram 300a provides an exemplary sequence of operations for a first user device 10a to receive and decrypt an encrypted message 152E sent by a 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 an 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 identifying the user 12a and / or the user device 10a. In some implementations, the KACLS 50 obtains 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, in operation 308, the KACLS 50 sends a key request 220 to the message server 160. The key request 220 may include identification and / or authentication of the user 12a or 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 the confidentiality of the decrypted DEK170. In operation 316, the first user device 10a uses the decrypted DEK 170 to decrypt the encrypted message 152E 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 a constructed message 152 in a manner similar to decrypting a received message 152. For example, to enable a recipient of the message 152 (e.g., a 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 its 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 to the KACLS 50, including the generated DEK 170. The KACLS 50 then encrypts the DEK 170 using 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, a 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 an encrypted PRK 172EPRK associated with the first user 12a in operation 326. The message server 160 returns the encrypted PRK 172EPRK associated with the first user 12a to the KACLS 50 in operation 328. The KACLS 50 encrypts the DEK 170 with the PRK 172PRK to generate an encrypted DEK 170E in operation 330. The KACLS 50 returns the encrypted DEK 170E to the first user device 10a in operation 332. The first user device 10a sends the signed message 152S, along with the encrypted DEK 170E, to the message server 160 in operation 336. 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, thereby 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 understood 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 executes a client encryption controller 180, but the second user device 10b does not. In these scenarios, the system 100 may implement various features of the S / MIME (Secure / Multipurpose Internet Mail Extensions) standard, for example, 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 execute a 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 execute 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 provide services to both users 12a and 12b (e.g., both users 12a and 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 a first user 12a and a second user 12b. For example, the message server 160 maintains a list 162 associating 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 another user's 12's public key 172PK for encrypting or decrypting 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 the 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 for the PRK172PRK. For example, all authorized users 12 of the PRK172PRK may be associated with roles that limit the scope of use of the PRK172PRK. For example, only users 12 with the role of “signer” may be permitted to sign a message 152 using the PRK172PRK. As another example, only users 12 with the role of “decryptor” may be permitted to decrypt an encrypted message 152E using the PRK172PRK, but may not be 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 various other security roles. For example, the auditor 52 may perform certificate validation to ensure that the 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 authenticates and / or authorizes the user 12 a and / or the user device 10 a and then utilizes the HSM / KSM to perform encryption / decryption operations. The HSM may be a physical computing device configured to manage and protect digital keys through various tamper-resistant means. 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 12 a to access the HSM. That is, because HSMs typically require complex levels of trust to be established for communications (e.g., server-to-server communications), the KACLS 50 may function as a gateway for the user 12 a to access the encryption and decryption capabilities of the HSM.

[0039] FIG. 4 is a flowchart of an exemplary operational arrangement of a method 400 for providing a hybrid content protection architecture for transmitting encrypted messages. When executed by data processing hardware 18 of user device 10, computer-implemented method 400 causes data processing hardware 18 to perform operations. Method 400 includes, at operation 402, obtaining, from message server 160, an encrypted message 152E encrypted with a single-use DEK 170. The single-use DEK may be used only to encrypt the encrypted message 152E. Operation 402 also includes obtaining an encrypted DEK 170E that includes the single-use DEK 170 encrypted with a PK 172PK. At operation 404, method 400 includes sending a decryption request 210 to KACLS 50, requesting KACLS 50 to decrypt the encrypted DEK 170E with a PRK 172PRK associated with PK 172PK. The decryption request 210 may include the encrypted DEK 170E. KACLS 50 is independent of 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 forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The components shown here, their connections and relationships, and their functionality are for illustrative purposes only and are not intended to limit the scope of the invention as described and / or claimed in this document.

[0041] Computing device 500 includes a processor 510, memory 520, a storage device 530, a high-speed interface / controller 540 connecting to memory 520 and a high-speed expansion port 550, and a low-speed bus 570 and a low-speed interface / controller 560 connecting to storage device 530. Each of the components 510, 520, 530, 540, 550, and 560 are interconnected using various buses and may reside on a common motherboard or exist in other ways as needed. Processor 510 processes instructions for execution within computing device 500, including instructions stored in memory 520 or storage device 530, and can display graphical information for a graphical user interface (GUI) on an external input / output device, such as a display 580 connected to 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. Multiple computing devices 500 may also be connected, each performing a portion 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] Storage device 530 can provide mass storage for computing device 500. In some implementations, storage device 530 is a computer-readable medium. In various different implementations, storage device 530 can be a device array including a floppy disk drive, a hard disk drive, an optical disk drive, or a tape drive, a flash memory or other similar solid-state memory device, or a storage area network or other configuration of devices. In additional implementations, a computer program product is tangibly embodied on 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 memory 520, storage device 530, or memory on processor 510.

[0044] The high-speed controller 540 manages more bandwidth-intensive operations of the computing device 500, while the low-speed controller 560 manages less bandwidth-intensive operations. This allocation of duties is merely exemplary. In some implementations, the high-speed controller 540 is coupled to memory 520, a 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 a storage device 530 and a low-speed expansion port 590. The low-speed expansion port 590 may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet, etc.) that can connect to one or more input / output devices, such as a keyboard, pointing device, scanner, or network devices, such as a switch or router, via a network adapter or the like.

[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, at least one input device, and at least one output device, coupled to receive data and instructions from and 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 may be implemented in a high-level procedural and / or object-oriented programming language, and / or assembly / machine language. As used herein, the terms "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 may be implemented by one or more programmable processors, also referred to as data processing hardware, that execute one or more computer programs to perform functions by operating on input data and generating output. The processors and logic flows may also be implemented by special-purpose logic circuitry, such as an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit). 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. Typically, 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 operably coupled to receive data from or transfer data to them, or both. However, a computer need not include 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 the 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) or 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 for 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, verbal, or tactile input. Additionally, a computer can interact with a 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] While several implementations have been described, it will, of course, be 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 with 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 the message server (160), the decryption request (210) requesting the KACLS (50) to decrypt the encrypted DEK (170E) with a private key (PRK) (172PRK) associated with the PK (172PK), the decryption request (210) including the encrypted DEK (170E); receiving the single-use DEK (170) from the KACLS (50); decrypting the encrypted message (152E) using the single-use DEK (170); causing said data processing hardware (18) to perform operations including The decryption request (210) Obtaining an encrypted PRK (172EPRK) via the message server (160) that includes the PRK (172PRK) encrypted with 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 the PRK (172PRK); The method (400) is configured to cause the KACLS (50) to perform the following.

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

3. 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 claim 1 or 2, configured to cause the KACLS (50) to:

4. A computer-implemented method (400) that, when executed by data processing hardware (18) of a user device (10), From the message server (160), an encrypted message (152E) encrypted with 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 the message server (160), the decryption request (210) requesting the KACLS (50) to decrypt the encrypted DEK (170E) with a private key (PRK) (172PRK) associated with the PK (172PK), the decryption request (210) including the encrypted DEK (170E); receiving the single-use DEK (170) from the KACLS (50); decrypting the encrypted message (152E) using the single-use DEK (170); 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 the KACLS (50) a second encrypted DEK (170E) containing the second single-use DEK (170) encrypted by the PRK (172PRK); sending the encrypted second message (152E) and the second encrypted DEK (170E) to the message server (160); a first operation of the data processing hardware to perform the operations of the first operation;

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

6. 3. The method (400) of claim 1 or 2, wherein the message server (160) does not receive access to the PRK (172PRK) or the decrypted message (152).

7. The method (400) of claim 1 or 2, wherein the PK (172PK) and the PRK (172PRK) comprise an asymmetric key pair.

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

9. the encrypted message (152E) comprises an email; The message server (160) includes an email service.

3. The method (400) of claim 1 or 2.

10. 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 with 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 the message server (160), the decryption request (210) requesting the KACLS (50) to decrypt the encrypted DEK (170E) with a private key (PRK) (172PRK) associated with the PK (172PK), the decryption request (210) including the 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) comprising: The decryption request (210) Obtaining an encrypted PRK (172EPRK) via the message server (160) that includes the PRK (172PRK) encrypted with 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 the PRK (172PRK); The system (100) is configured to cause the KACLS (50) to perform the above.

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

12. 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 claim 10 or 11, configured to cause the KACLS (50) to:

13. Data processing hardware (18) of a 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 with 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 the message server (160), the decryption request (210) requesting the KACLS (50) to decrypt the encrypted DEK (170E) with a private key (PRK) (172PRK) associated with the PK (172PK), the decryption request (210) including the 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) comprising: The operation is 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 the KACLS (50) a second encrypted DEK (170E) containing the second single-use DEK (170) encrypted by the PRK (172PRK); sending the encrypted second message (152E) and the second encrypted DEK (170E) to the message server (160); The system (100) further comprises:

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

15. 12. The system (100) of claim 10 or 11, wherein the message server (160) does not receive access to the PRK (172PRK) or the decrypted message (152).

16. 12. The system (100) of claim 10 or 11, wherein the PK (172PK) and the PRK (172PRK) comprise an asymmetric key pair.

17. 17. The system (100) of claim 16, wherein the message server (160) stores the PK (172PK).

18. the encrypted message (152E) comprises an email; The message server (160) includes an email service. A system (100) according to claim 10 or 11.

Images