SECURE MESSAGE DELIVERY USING A TRUST BROKER

• US 20090319781A1
• Filed: 06/23/2008
• Published: 12/24/2009
• Est. Priority Date: 06/23/2008
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Corporation
• Inventors: Nelte, Michael, Jain, Chandresh, Gourevitch, Greg, Conceicao, Ladislau, Barnes, Chris, Kress, Brian, Mehta, Mayank, Byrum, Frank
• Granted Patent: US 8,732,452 B2
• Time in Patent Office: Days
• US Class Current: 713/156
• CPC Class Codes: H04L 51/00 User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
• CPC Class Codes: H04L 63/0428 wherein the data content is protected, e.g. by encrypting or encapsulating the payload
• CPC Class Codes: H04L 63/0435 wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption cryptographic mechanisms or cryptographic arrangements for symmetric key encryption H04L9/06
• CPC Class Codes: H04L 63/0807 using tickets, e.g. Kerberos cryptographic mechanisms or cryptographic arrangements for entity authentication using tickets or tokens H04L9/3213

Abstract

An email security system is described that allows users within different organizations to securely send email to one another. The email security system provides a federation server on the Internet or other unsecured network accessible by each of the organizations. Each organization provides identity information to the federation server. When a sender in one organization sends a message to a recipient in another organization, the federation server provides the sender'"'"'s email server with a secure token for encrypting the message to provide secure delivery over the unsecured network.

Claims

1. A computer-implemented method for securely exchanging email between two email systems connected by an insecure network using a trust broker, the method comprising:

receiving a message from an email client connected to a first email system;

identifying a domain of a recipient of the message based on information associated with the message;

sending a request to the trust broker requesting a token for securely sending email to a second email system associated with the recipient, wherein the trust broker manages security information for multiple email systems and provides tokens that assure an email system receiving a message that the received message is secure;

receiving a response to the request that contains the requested token;

encrypting the message using the received token; and

sending the encrypted message to the second email system over an unsecure network.

2. The method of claim 1 wherein the first email system is associated with a first organization and the second email system is associated with a second organization.

3. The method of claim 1 wherein the first and second email systems are associated with the same organization but are connected via an insecure network.

4. The method of claim 1 wherein identifying the domain of the recipient comprises reading the SMPT RCPT TO protocol information.

5. The method of claim 1 wherein identifying the domain of the recipient comprises accessing a MAPI property containing message recipients.

6. The method of claim 1 further comprising, if the message has recipients at multiple domains, repeating the steps of sending a request to the trust broker, receiving a response to the request, encrypting the message, and sending the encrypted message for each of the domains.

7. The method of claim 1 wherein the request to the trust broker includes identity information for verifying the identity of the first email system email server to the federation server

8. The method of claim 1 wherein the request to the trust broker identifies the purpose of the token as secure messaging.

9. The method of claim 1 wherein the token includes information encrypted using a public key associated with the recipient'"'"'s domain.

10. The method of claim 1 wherein the token includes a proof of possession key.

11. The method of claim 1 wherein encrypting the message comprises adding security information using S/MIME to the message.

12. The method of claim 1 wherein encrypting the message comprises adding control flags to the message that specify processing that the first email system performed on the message.

13. A computer system for delivering secure email between domains, the system comprising:

a federation server component configured to collect organization identifying information, verify the identity of requesters, and distribute tokens for securely communication with organizations;

a first email server component configured to send email communicate with the federation server to obtain tokens for securely communicating with domains associated with email recipients, and encrypt email messages using the obtained tokens;

a second email server component configured to receive encrypted email, verify signature information of the first email server, decrypt email, and deliver email securely to recipients; and

an unsecure network communicatively connected to the federation server component, first email server component, and second email server component.

14. The system of claim 13 wherein the first email server sends email on behalf of a first domain, and the second email server receives email on behalf of a second domain.

15. A computer-readable medium containing instructions for controlling a computer system to provide tokens for sending and receiving secure messages, by a method comprising:

receiving a request for a token that verifies the identity of a request sender and contains a shared secret provided by a destination of a message, wherein the request contains an indication of an organization with which the request sender is associated;

verifying the identity of the request sender based on the indication of the organization associated with the request sender and identity information accessible by the computer system about the organization.

retrieving a domain with which the request sender wants to communicate from the request;

providing the requested token to the sender with which the sender can send a secure message to the domain.

16. The computer-readable medium of claim 15 further comprising, before receiving a request receiving organization identity information for one or more organizations that want to use the services of the federation server as a trust broker with other organizations and storing the identity information.

17. The computer-readable medium of claim 15 wherein verifying the identity of the request sender comprises reading a signature from the request and using a public key of the organization to determine that the signature was signed with a private key of the organization.

18. The computer-readable medium of claim 15 wherein verifying the identity of the request sender comprises determining whether the request sender is invalid, and when the request sender is invalid, denying the request.

19. The computer-readable medium of claim 15 wherein the token includes a specified purpose of the token.

20. The computer-readable medium of claim 15 wherein the token includes the domain for which the token can be used for secure communication.