Abstract:
A method and system is described to authenticate the sender of digital content, by combining the functionality of a key distribution server with the one of a mail server. This system allows the distribution of a person&#39;s public key or keys by simply knowing that person&#39;s email address. Senders upload a public encryption key onto their account on a mail server and use the corresponding private key to digitally sign outgoing digital content. Recipients verify the digital signature of incoming digital content using the sender&#39;s public key, which can be easily downloaded from the mail server and account coordinates specified by the return address field of the digital content.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates to a method and system for authenticating digital content. More particularly, it relates to a method for authenticating the sender of electronic mail, digital music, digital videos, electronic documents, or similar digital content by combining the functionality of a key distribution server with a mail server. 
       BACKGROUND OF THE INVENTION 
       [0002]    Recipients of email messages and other digital content are frequently subject to spam, forgery, fraud, and other crimes. Authentication of digital content assures the recipients that the return address exists, that the sender of the digital content owns such address, and that the digital content was not tampered with during its transmission and subsequent delivery. Additionally, as a byproduct of the authentication process, recipients have an opportunity to inspect the credentials of the server hosting the return address and possibly verify the identity of the sender with such information as the sender&#39;s full name or employer. 
         [0003]    Many different protocols exist today claiming to perform authentication of email messages. In reality, these protocols only validate the outgoing mail server from which a message originates. In other words, they check whether the server is authorized to relay email messages or not. However, these techniques fail in exposing a fake sender and even in such fundamental tasks as verifying the existence of a return address. 
         [0004]    One known identification protocol is discussed in U.S. Pat. No. 6,986,049 to Delany, issued on Jan. 10, 2006. This patent involves the use of digital signatures for authenticating messages. However, this protocol has several limitations. First, it makes use of a public/private key pair only for each outgoing mail server. Second, the protocol relies on outgoing mail servers to digitally sign messages rather than client software. Third, the signature verification involves the download of the outgoing server&#39;s public key from a special DNS entry associated with the originating domain. Because of these limitations, authentication by this protocol only proves that an email message originated from an authorized server but says nothing about the sender of the message. 
         [0005]    Another known protocol is Microsoft Sender ID, which is based on an older protocol called Sender Policy Framework (SPF). SPF allows the owner of an Internet domain to use special DNS records to specify which machines are authorized to transmit email for that domain. Receivers can then reject any email that claims to come from that domain but fails in a check against the IP addresses listed in the SPF record of the domain. 
         [0006]    Both of these protocols filter out emails originating from an unauthorized mail server. However, these two protocols only authenticate the domain from which a message originates, and they do not authenticate the sender. The present invention overcomes this disadvantage by assigning a key pair to each user of the system. Client software is in charge of signing outgoing messages before they are transmitted through the network, which is done using the private key of the sender. The present invention proves that the sender owns the return address of the message, that the mail server hosting the return address is authentic, and that the sender is who he or she claims to be. 
       SUMMARY OF THE INVENTION 
       [0007]    An objective of the invention is to provide a method and system for authenticating digital content. 
         [0008]    Another objective of the invention is to provide a method and system for authenticating the sender of digital content. 
         [0009]    The present invention is a method for authenticating digital content. The first step is generating a public/private key pair for a sender of digital content. The second step is uploading the public component of the pair onto the sender&#39;s account. The third step is using the corresponding private key of the key pair to generate a digital signature for the outgoing digital content. The fourth step is sending the digital content to a recipient&#39;s server. The fifth step is verifying the digital signature associated with the digital content using the public component of the key pair. 
     
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]      FIG. 1  is a schematic illustration of a system for authenticating digital content in accordance with one embodiment of the present invention. 
           [0011]      FIG. 2  is a schematic illustration of a system for authenticating digital content in accordance with another embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
       [0012]    The present invention authenticates digital content. The digital content can be email, video, music, text documents, or any type of electronic media. Examples may reference a specific type of digital content; however, one of ordinary skill in the art would appreciate that the present invention can be applied to all types of digital content. 
         [0013]    The authentication process of the present invention creates a collaboration between both the sending and receiving sides. In the authentication process, outgoing digital content contains some extra information needed by the recipients of the message to validate its authenticity. This information consists of a digital signature and a key identifier (KID). 
         [0014]    As utilized hereinafter, a “key pair” is meant to generally refer to both the public key and its corresponding private key. 
         [0015]    As utilized hereinafter, a “public key” is meant to generally refer to a piece of cryptographic information used to verify the digital signature generated by one and only one private key. Given today&#39;s technology, it is impossible to derive a private key from its corresponding public key. For this reason, a public key may be freely distributed. 
         [0016]    As utilized hereinafter, a “private key” is meant to generally refer to a piece of cryptographic information used, among other things, to digitally sign any kind of data, such as an email message. The owner should keep this cryptographic key secret. 
         [0017]    As utilized hereinafter, a “digital signature” is meant to generally refer to a very large alpha-numeric array of elements generated from some input data of any length (such as an email message) and a private key. The digital signature is unique to the given data and key that are used as inputs. The inverse of a digital signature function, that is, the verification function, requires the initial input data and the public component of the key pair used to generate the signature. 
         [0018]    A digital signature serves two purposes. First, it guarantees that the contents of the digital content were not tampered with. Second, it proves that the digital content originated from the claimed sender. A digital signature is generated using a private key, which is kept secret by the sender on a local host. The corresponding public key is freely distributed so that the digital signature of the digital content can be verified. Together, the public key and the private key comprise a key pair. The public key is freely distributed by keeping the public key on the mail server hosting the return address of the outgoing message. Specifically, the key is uploaded onto the sender&#39;s account on that server, where it can be freely downloaded by anyone that requests it. Because multiple keys may be stored in the same account, a key identifier is utilized to specify which public key should be used to verify a signature. 
         [0019]    The client software can generate a public/private key pair automatically, usually at the time the software is installed. Alternatively, the user may provide a key pair, with its public component possibly embedded in a certificate signed by a trusted Certificate Authority. In both cases, the public component of the key pair is copied into the sender&#39;s remote account. 
         [0020]    A certificate is meant to generally refer to a public key bundled with additional information used for identification purposes. The owner of a certificate may be an individual user or a company. A certificate may be assigned to a server or to an individual user. A certificate should be digitally signed by a Certificate Authority to be trusted. 
         [0021]    In copying the public key to the sender&#39;s account, a secure connection is established with the server hosting the user&#39;s account. The name of the server is determined by the last portion of the user&#39;s email address, starting after the “@” symbol. For instance, if the address is “john@example.com,” then a secure connection is established with example.com. 
         [0022]    Then, the account belonging to the user is selected. The name of the account is determined by the first portion of the user&#39;s email address up to the “@” symbol. For instance, if the address is “john@example.com,” then the account “john” is selected. 
         [0023]    Next, owner privileges are obtained. This may be achieved by providing a password or other authentication information associated with the account. 
         [0024]    Finally, the new public key is added to the key database of the selected account. On success, the server returns an integer key identifier referencing the new key. This identifier is embedded in every outgoing digital content signed using the key&#39;s matching private component. 
         [0025]    A key identifier is useful when multiple computers are used to send and receive digital content. The multiple computers could be a workstation, laptop computer, desktop computer, hand-held device, or any device capable of sending and receiving digital content. Each platform may hold a different key pair, whose public component needs to be uploaded onto the user&#39;s account. Multiple public keys may be in the same account, and each of them is associated with a unique KID. 
         [0026]    When handling multiple accounts belonging to the same user, the client software may choose a different key pair for every account owned by the user, a single key pair for all accounts owned by the user, or any combination thereof. 
         [0027]    In verifying the authenticity of incoming digital content, the digital content contains a digital signature and a key identifier. The authentication process simply comprises verifying the digital signature of any digital content using the public key of the sender. The public key of the sender is downloaded from the mail server and account coordinates specified in the return address field of the incoming message. 
         [0028]    In order to verify the authenticity, a secure connection is established with the mail server specified in the return address field of the digital content. The name of the server is determined by the last portion of the return address, starting after the “@” symbol. For instance, if the return address is “john@example.com,” then a secure connection is established with example.com. 
         [0029]    Then, the certificate of the mail server is examined. In particular, the certificate is checked for whether the certificate was signed by a trusted Certificate Authority, the Internet domain associated with the certificate matches the expected domain, and the certificate has not expired. 
         [0030]    Next, the account belonging to the sender is selected. As stated above, the name of the account is determined by the first portion of the return email address up to the “@” symbol. 
         [0031]    After that step, the public key associated with the KID that is embedded in the incoming digital content is retrieved. If the key is provided in the form of a certificate, the certificate is examined. In particular, it is determined whether the certificate was signed by a trusted Certificate Authority, the certificate has expired, the email address associated with the certificate matches the expected address, and the name of the owner matches the sender&#39;s name. 
         [0032]    Once the public key of the sender is downloaded, it can be used to verify the digital signature of the message. A valid signature proves that the message was not tampered with, the return address of the message is valid, the sender owns the indicated return address, the sender is who he or she claims to be, and the mail server hosting the sender&#39;s account can be trusted. 
         [0033]    Upon the successful authentication of the digital content, the sender definitely owns the return address of the digital content since only the sender could have placed the public key needed for signature verification into his account. 
         [0034]      FIG. 1  shows one embodiment of the present invention. A sender  12  wants to send some digital content  22  to recipient  14 . First, a public/private key pair  16  is generated for the sender  12 . The public/private key pair consists of a public key  18  and a private key  20 . The public component  18  of the pair  16  is uploaded into the sender&#39;s account  26  while the corresponding private key  20  is used to generate a digital signature  24  for the outgoing digital content  22 . The digital content  22  is then sent to the recipient&#39;s server  28 . Next, the recipient  14  downloads the digital content  22  and verifies its signature  24  using the sender&#39;s public key  18 , which is available from the sender&#39;s account  26 . 
         [0035]      FIG. 2  illustrates another embodiment. In this embodiment, the recipient server  28  performs the authentication process in place of the recipient host  14 . Therefore, the server  28  may act as a filter, allowing only authenticated digital content  22  to pass through and reach the recipient host  14 . 
         [0036]    As in  FIG. 1 , the steps begin when sender  12  sends digital content  22  to a recipient  14 . First, a public/private key pair  16  is generated for the sender  12 . The public component  18  of the pair  16  is uploaded into the sender&#39;s account  26  while the corresponding private key  20  is used to generate a digital signature  24  for the outgoing digital content  22 . The digital content  22  is then sent to the recipient&#39;s server  28 . 
         [0037]    After this step, this embodiment differs from the previous embodiment. The recipient&#39;s server  28  verifies the digital signature  24  of the digital content  22  using the sender&#39;s public key  18 , which can be downloaded from the sender&#39;s account  26 . If the signature  24  is valid, the digital content  22  is stored in the recipient host  14  and later downloaded. If the signature  24  is not valid, then the digital content  22  is discarded. 
         [0038]    After authenticating the digital content, the public key or certificate of its sender may be cached on the recipient&#39;s local host. If this is done, future digital content coming from the same sender can be authenticated immediately using the cached key as long as the KID in the message matches the KID of the cached key and the cached key has not expired. 
         [0039]    In the presence of a key cache, the key identifier and digital signature from the received digital content is extracted. Then, it is determined whether a public key associated with the given sender and KID is present in the cache. 
         [0040]    If the key is not cached, the public key of the sender is downloaded as described above. If the key is cached, then two scenarios are possible. If the public key is embedded in a certificate, then it is verified that the certificate has not expired. Otherwise, the key is checked at regular intervals throughout the life of the key to determine whether the key is still valid. 
         [0041]    To determine whether a cached key is still valid, a secure connection is established with the server from which the cached key was originally downloaded. Then, the certificate of the server is examined. In particular, it is examined to verify that the certificate has not expired. Next, the account is selected from which the key was originally downloaded. The corresponding key database is queried from the KID of the cached key. A simply query is sufficient, it is not necessary to download the key data again. 
         [0042]    After it has been determined that the cached key is still valid or that the certificate it was embedded in was not expired, the digital signature of the message is verified using the sender&#39;s public key. If the signature is valid and the sender&#39;s key was not cached, then the public key is added to the cache. 
         [0043]    A key may be revoked by its owner or by a server administrator in the event that the corresponding private key is compromised. The key could also be periodically revoked as a security precaution, and then a newer key would regularly replace the key. 
         [0044]    To limit the risk of using a compromised key, the recipient host can perform regular checks on the validity of a cached key before using it. The rate at which a cached key could be checked depends on the preferences and security needs of a given user. 
         [0045]    Furthermore, the present invention can be layered on top of any network protocol used for the exchange of digital content. For instance, it can be used with SMTP, POP3, or IMAP, which are current protocols from the delivery and retrieval of email messages, as well as other proprietary protocols. 
       EXAMPLES 
       [0046]    The following examples show some embodiments of the present invention. The first example is illustrated by  FIG. 1 . Alice (alice@paradoxity.com) wants to send an email message to Bob (bob@example.com). First, a public/private key pair is generated for Alice. The public component of the pair is uploaded into Alice&#39;s account on paradoxity.com, while the corresponding private key is used to generate a digital signature for the outgoing message. 
         [0047]    The email is then sent to the example.com mail server, where Bob owns a mailbox. Next, Bob downloads the new message from his mailbox and verifies its signature using Alice&#39;s public key, which is available from Alice&#39;s email account on paradoxity.com. 
         [0048]    A second example is illustrated by  FIG. 2 . Alice (alice@paradoxity.com) wants to send an email message to Bob (bob@example.com). First, a public/private key pair is generated for Alice. The public component of the pair is uploaded into Alice&#39;s account on paradoxity.com, while the corresponding private key is used to generate a digital signature for the outgoing message. 
         [0049]    The email is then sent to the example.com mail server, where Bob owns a mailbox. Bob&#39;s mail server verifies the digital signature of the message using Alice&#39;s public key, which can be downloaded from her email account on paradoxity.com. If the signature is valid, the email message is stored in Bob&#39;s mailbox and later downloaded by Bob. Otherwise, the email message is discarded. 
         [0050]    The embodiments described above and shown in  FIGS. 1-2  disclose a new method and system for authenticating digital content. One of ordinary skill in the art would appreciate that the present invention can be used on any hardware system such as a workstation, laptop computer, desktop computer, hand-held device, or any similar system. Further, one of ordinary skill in the art would appreciate that hardware systems are capable of communicating to each other through a digital, analog, wireless, or other similar signal. 
         [0051]    While the invention has been described with reference to the preferred embodiments, it will be understood by those skilled in the art that various obvious changes may be made, and equivalents may be substituted for elements thereof, without departing from the essential scope of the present invention. Therefore, it is intended that the invention not be limited to the particular embodiments disclosed, but that the invention includes all embodiments falling within the scope of the appended claims.