Secure messaging system with derived keys

BACKGROUND OF THE INVENTION

0001This invention relates to cryptographic systems, and more particularly, to cryptographic systems using derived keys.

0002It is often desirable to encrypt sensitive electronic communications such as email messages.

0003With public key cryptographic systems, two types of keys are used—public keys and private keys. Senders may encrypt messages using the public keys of recipients. Each recipient has a private key that is used to decrypt the messages for that recipient.

0004With symmetric key cryptographic arrangements, the sender of a message uses the same key to encrypt the message that the recipient of the message uses to decrypt the message. An advantage of symmetric key cryptography is that symmetric key encryption and decryption algorithms are computationally efficient.

0005Often senders and recipients of secure messages have existing relationships with organizations. For example, a bank may wish to send its customers account statements securely. As another example, a customer who receives an encrypted account statement may wish to send a secure email message back to the bank to ask a question.

0006It is an object of the present invention to provide secure messaging systems that use symmetric keys to facilitate secure communications.

SUMMARY OF THE INVENTION

0007Secure messages may be sent between senders and recipients using symmetric message keys. An organization may have a key generator that derives symmetric message keys from a master key. The key generator may produce the derived keys by applying a one-way function such as an HMAC function or other hash function to the master key and recipient identity information (i.e., a recipient ID). The resulting derived keys are specific to each recipient. The compromise of a derived key will not compromise the master key, which helps to ensure security.

0008A sender may use a derived key to encrypt a message for a recipient who is a customer of the organization. Because the recipient is a customer of the organization, there is a preexisting relationship between the recipient and the organization. The organization therefore has recipient credential information that can be used to authenticate the recipient.

0009When the recipient receives an encrypted message, the recipient can authenticate to the organization and can request a copy of the derived key to use in decrypting the message. The derived key request includes the recipient ID. The recipient ID that is provided with the key request from the recipient may be used by the key generator to derive a new copy of the derived key. This new copy of the derived key may then be provided to the recipient over a secure communications channel. The recipient may use a decryption engine on the recipient's equipment to decrypt the encrypted message with the received copy of the derived key.

0010A hierarchical key generator architecture may be used for an organization with multiple organizational units. Each unit may have a respective delegated key generator that generates derived symmetric keys for senders in its unit. The organization may have a super key generator that has a super master key. The super key generator may derive sub-master keys for each delegated key generator.

0011Symmetric key arrangements can also be used to allow senders outside of an organization who are not customers of the organization to send messages to recipient inside the organization. The organization may have a key generator for creating derived keys based on a master key and recipient IDs. A policy server in the organization may use the derived keys and a random number N to generate (derive) non-customer symmetric keys.

0012For example, the key generator may apply an HMAC function to a master key and recipient ID to produced a derived key. The policy server may generate a random number N and may apply an HMAC function to the derived key from the key generator and the random number N to produce the non-customer message key.

0013When a sender desires to send a message to a recipient in the organization, the sender and policy server establish a secure link. The policy server provides the sender with the non-customer message key over the secure link. The sender uses the non-customer message key to encrypt a message for the recipient. The sender then sends the encrypted message including the value of N to the recipient. At the recipient, the recipient can use the recipient ID and the value of N to obtain a copy of the non-customer message key from the policy server. The recipient can then decrypt the encrypted message from the sender.

0014Further features of the invention, its nature and various advantages will be more apparent from the accompanying drawings and the following detailed description of the preferred embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

0015<figref idref="DRAWINGS">FIG. 1</figref> is a diagram of an illustrative system in which secure messages may be conveyed between senders and recipients in accordance with the present invention.

0016<figref idref="DRAWINGS">FIG. 2</figref> is a flow chart of illustrative steps involved in setting up a system of the type shown in <figref idref="DRAWINGS">FIG. 1</figref> and satisfying derived key requests in accordance with the present invention.

0017<figref idref="DRAWINGS">FIG. 3</figref> is a flow chart of illustrative steps involved in encrypting and sending secure messages using a system of the type shown in <figref idref="DRAWINGS">FIG. 1</figref> in accordance with the present invention.

0018<figref idref="DRAWINGS">FIG. 4</figref> is a flow chart of illustrative steps involved in receiving and decrypting secure messages using a system of the type shown in <figref idref="DRAWINGS">FIG. 1</figref> in accordance with the present invention.

0019<figref idref="DRAWINGS">FIG. 5</figref> is a diagram of an illustrative hierarchical arrangement that allows a key generator to create master keys (sub-master keys) for associated key generators in accordance with the present invention.

0020<figref idref="DRAWINGS">FIG. 6</figref> is a flow chart of illustrative steps involved in setting up and using a system of the type shown in <figref idref="DRAWINGS">FIG. 5</figref> to send and receive secure messages in accordance with the present invention.

0021<figref idref="DRAWINGS">FIG. 7</figref> is a diagram of an illustrative system that may be used to allow a sender who is not a customer of an organization to send a recipient at the organization a secure message in accordance with the present invention.

0022<figref idref="DRAWINGS">FIG. 8</figref> is a flow chart of illustrative steps that may be used by a sender in a system of the type shown in <figref idref="DRAWINGS">FIG. 7</figref> to encrypt and send a secure message to a recipient in accordance with the present invention.

0023<figref idref="DRAWINGS">FIG. 9</figref> is a flow chart of illustrative steps that may be used by a recipient in a system of the type shown in <figref idref="DRAWINGS">FIG. 7</figref> to receive and decrypt a secure message from a sender in accordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

0024The present invention relates to cryptographic systems such as systems for supporting secure messaging. The invention also relates to methods for using such systems.

0025Equipment of the type shown in system <b>10</b> of <figref idref="DRAWINGS">FIG. 1</figref> may be used to support secure communications between senders and recipients. A sender is a user who sends a message. A recipient is a user who receives a message. Because users can generally both send and receive messages, a given user may at one time be a sender and at another time be a recipient.

0026Some users in system <b>10</b> may belong to an organization such as organization <b>18</b>. Other users may belong to a different organization or may not be affiliated with any organization.

0027In the example of <figref idref="DRAWINGS">FIG. 1</figref>, sender A and user B are users who belong to organization A. Recipient C and user D are users who are not affiliated with organization A.

0028Some user activities in system <b>10</b>, such as sending person-to-person email messages, involve manual intervention. For example, a person who desires to send a personally-composed text message must type the message before it is encrypted and sent to the appropriate recipient. Other user activities in system <b>10</b> may be entirely automated so that no human intervention is generally required. As an example, an organization may use a computer to automatically send messages to each of its customers. In this type of scenario the computer serves as a type of user (i.e., a sender in this example). In the following discussion, the terms “sender,” “recipient,” and “user” are used to describe both people and their equipment.

0029The messages that are carried by the system need not be email messages, although email messages are used as an example. The messages may be email messages, instant messages, or any other suitable electronically-conveyed message. Messages may include any digital information (e.g., text, graphics, audio, video, commands, executable code, data, etc.) that it is desired to convey electronically between senders and recipients.

0030Users in system <b>10</b> may communicate with each other using equipment <b>12</b>. Equipment <b>12</b> (and the equipment for the other entities in the system) may, for example, include computing equipment such as a personal computers, portable computers, workstations, mainframe computers, networked computers or terminals such as computer terminals that are connected to the Internet using a host computer in a local area network, handheld computers, cellular phones, or any other suitable electronic equipment.

0031The equipment of <figref idref="DRAWINGS">FIG. 1</figref> may be interconnected by communications paths in communications network <b>14</b> and intranet <b>16</b>.

0032Network <b>14</b> may include the Internet and other wide area networks, one or more intranets, local area networks, switched telephone networks, networks such as virtual private networks, networks including dedicated leased lines, networks based on wired or wireless paths, or any other networks formed using any other suitable network technology.

0033Intranets such as intranet <b>16</b> are communications networks that are used to network the users at a particular organization. For example, the intranet <b>16</b> of <figref idref="DRAWINGS">FIG. 1</figref> is associated with an organization <b>18</b> and is used to interconnect equipment such as the equipment <b>12</b> for sender A and user B, a key generator <b>20</b>, a gateway <b>22</b>, and a decryption server <b>24</b>. Intranets such as intranet <b>16</b> may be local area networks or wide area networks. An illustrative intranet for a small company might be, for example, a ten-seat Ethernet network. A large organization might have multiple campuses at widely spaced locations. Such an organization's intranet might be built from Ethernet-based local area networks at each campus linked together by secure paths over the Internet.

0034System <b>10</b> may have a key generator such as key generator <b>20</b> for generating keys. Key generator <b>20</b> may derive multiple user-specific keys from a master key <b>26</b>.

0035Messages may be encrypted using encryption engines and may be decrypted using decryption engines. Any suitable cryptographic algorithm may be used for encryption and decryption of messages in system <b>10</b>. A symmetric-key cryptographic arrangement is preferred. Suitable symmetric key algorithms include AES (Advanced Encryption Standard), DES (Data Encryption Standard), Triple-DES, etc.

0036In one suitable arrangement, all messages from senders at organization <b>18</b> are routed to network <b>14</b> through intranet <b>16</b> and gateway <b>22</b>. The gateway <b>22</b> may have an encryption engine <b>28</b> for encrypting the messages. After an encrypted message has been received by a recipient, it may be decrypted using a decryption engine such as decryption engine <b>34</b> of recipient C.

0037In symmetric key cryptography, the same key is used for both encryption and decryption operations. A recipient such as recipient C who is outside of the organization <b>18</b> may obtain a copy of the key that the encryption engine <b>28</b> at gateway <b>22</b> used for encryption by making a key request to organization <b>18</b>. Once the key has been obtained by the recipient, a decryption engine such as decryption engine <b>34</b> may be used to decrypt the message and access its contents.

0038Decryption server <b>24</b> may be used to handle requests for keys. An authentication service <b>30</b> may be used to authenticate users before they are provided with requested keys. Key delivery service <b>32</b> may be used to fulfill the key requests of authenticated requesters.

0039In one suitable scenario, users have software applications (“client software”) such as email applications, email applications with web browser engines (i.e., built-in web browser capabilities), web browser applications, document creation and editing applications, image viewers, media players, etc. The functions of the encryption and decryption engines may be provided using stand-alone encryption and decryption applications or using encryption and decryption software components that are integrated with these applications. As an example, an email program such as an email program used by a recipient may have a decryption engine. The encryption engine may be provided as part of the native code in the email application or may be installed as a plug-in module. As another example, software used to manage a gateway such as gateway <b>22</b> may have a built in encryption engine or the encryption engine may be provided as a separate software component.

0040Various computing devices may be used in system <b>10</b>. For example, computing equipment may be used to implement the functions of a server or other computer equipment at each key generator <b>20</b>, gateway <b>22</b>, and decryption server <b>24</b>. Servers may also be used to support the functions of a certificate authority, mail servers, and other entities. Such servers may be co-located with a sender or sender's organization, may be connected to the network <b>14</b> as an independent third-party service, may be part of the infrastructure of network <b>14</b>, may be associated with a given recipient's organization, may be co-located with the recipient, key generator, or other equipment, or may used at more than one of these locations. These are merely illustrative arrangements which need not be mutually exclusive.

0041A server may be formed using a single computer or multiple computers. Multiple servers may be implemented on one computer. If desired, the functions of a single server may be provided by computers that are distributed over a number of different physical locations. The functions implemented using servers in system <b>10</b> may generally be performed using other computer equipment configurations if desired, but the computing equipment for implementing these functions is sometimes referred to as a “server” or “servers.”

0042A sender may send a message to a given recipient over system <b>10</b> using any suitable messaging format. For example, an email message, an instant message (e.g., an AOL instant message, a Yahoo instant message, an MSN Messenger instant message, and ICQ instant message, an IBM/Lotus Sametime instant message, etc.), or other electronic message may be sent.

0043During operation of system <b>10</b>, certain entities such as decryption server <b>24</b> may need to verify that a given party has permission to obtain a key, to download new client software (including, e.g., a decryption algorithm), to access the contents of a particular message, or to perform other functions. In general, the entity performing such authentication and authorization processes may use any suitable manual or automatic techniques. For example, a party may be asked to fax or mail a letter to an authenticating entity on the party's official letterhead, which is examined for authenticity by personnel or automated equipment at the authenticating entity. As another example, biometric identification techniques (e.g., fingerprint analysis, eye-scanning, handprint or voiceprint analysis, facial recognition methods, or in-person identification checks) may be used. Hardware-based arrangements (e.g., based on hardware tokens) may be used to establish identity. A user may provide credentials in the form of a pre-established user name and password. Certificate authorities may create digital certificates that help to verify the identities of certain parties. Digital signatures (e.g., signatures from a certificate authority or other entity that use private keys and that can be verified using matching public keys) may be used to ensure that a message or other signed information is associated with a particular party. Sometimes an authentication process in system <b>10</b> may involve the generation of a ticket such as a Kerberos ticket or other proof of authorization. User authentication operations are generally described herein without need to distinguish between information such as ticket information that is derived from or based on recipient credential information and the underlying username and password or other recipient credential information that is entered by a user.

0044Sometimes authentication information and other information must be conveyed between parties securely (e.g., between decryption server <b>24</b> and a user). A number of different approaches may be used to convey information in system <b>10</b> securely. For example, information may be conveyed securely over a secure communications path such as a communications path that uses the secure sockets layer protocol (SSL) or other suitable secure protocol (e.g., TLS), a communications path may be trusted because it is under the control of a trusted party (e.g., because the communications path is entirely within organization <b>18</b> and is therefore physically under the control of a trusted party), and information may be conveyed securely by encrypting the information (e.g., in a message) before sending it over an insecure (or secure) link.

0045For ease of interfacing with existing encryption mechanisms or for other suitable reasons, it may sometimes be desired to use a “two-step” encryption technique in which a first key is used to encrypt the contents of a message and a second key is used to encrypt the first key. During decryption, the second key is used to decrypt the encrypted version of the first key, which may then be used to unlock the message contents. These two-step processes (and analogous higher-order multi-step processes) may be more efficient than “pure” or “single step” encryption algorithms and may be used if desired. For clarity, the present invention is described in the context of single-step algorithms.

0046Public key cryptography is often used in secure messaging systems. With public key cryptography, a sender may encrypt a message for a recipient using that recipient's public key. The recipient uses a matching private key for decryption. Although public key cryptography is generally satisfactory, it can be unnecessarily cumbersome in environments in which there is already a preexisting relationship between sender and recipient.

0047Consider the illustrative scenario in which organization <b>18</b> is a bank. The bank has an existing set of customers to whom it is desired to securely distribute electronic account statements. The bank and customers already have a trusted relationship with each other. For example, the bank has already assigned account names and numbers to its customers. When the customers opened their accounts, the bank collected personal information such as social security number information, telephone numbers, the names of relatives, birth dates, birth places, email addresses, etc. This information can be used by the bank to verify customers' identities. The bank's customers may also have personal-identification numbers (PINs) for withdrawing cash from automatic teller machines and usernames and passwords for authentication prior to performing on-line banking tasks.

0048In this type of environment, the bank and its customers are not strangers. It is therefore unnecessary for the bank and its customers to rely exclusively on a cryptographic approach such as public-key cryptography that is designed to allow senders and recipients to treat each other as strangers.

0049The present invention can leverage the preexisting relationship between the bank and its customers. Efficient symmetric key encryption can be used rather than public-key encryption. The preexisting relationship between the bank and its customers can also be used to facilitate operations such as authentication and key distribution.

0050In the following discussion, organization <b>18</b> may be a company or corporation or any other suitable type of enterprise. The users at the organization may be employees, volunteers, contractors, or any other suitable types of members of the organization (or their equipment). Users in the organization are distinguished from users outside of the organization by their access to intranet <b>16</b> and the equipment that is networked together inside of the organization using intranet <b>16</b> such as gateway <b>22</b>.

0051Some of the users outside of the organization may be independent third parties who have no relationship with the organization.

0052Other users outside of the organization may be the customers of the organization. For example, account holders at a bank are customers of the bank, as discussed above. Customers may be clients, contractors, temporary employees without the same access rights as employees working at the organization, or any other suitable users who are associated with the organization as customers but who are not part of the organization itself.

0053Once a user has become associated with a given organization as a customer, the relationship between the user and the organization can be leveraged to support the secure communications techniques of the present invention. In a typical scenario, a sender A such as an automated account statement distribution server at a bank <b>18</b> sends encrypted account statement messages to recipients who are customers such as recipient C. The sender A sends each message through gateway <b>22</b>. Gateway <b>22</b> uses encryption engine <b>28</b> to encrypt each message using a symmetric key. The symmetric key is derived from the master key <b>26</b> by the key generator <b>20</b> and is therefore referred to as a “derived key.” Many different keys can be derived in this way, so derived keys may be produced that are unique for each recipient. By using a deterministic key derivation mechanism, derived keys need not be stored by the key generator, since any user's key can easily be re-derived as needed from the user ID.

0054After the gateway has encrypted the message for recipient C using recipient C's derived symmetric key, the gateway may relay the encrypted message to recipient C. The encrypted message may be delivered to recipient C over communications network <b>14</b>. Upon receiving the encrypted message, recipient C may obtain a copy of the derived key from the organization A, so that recipient C may use decryption engine <b>34</b> to decrypt the message's contents.

0055Recipient C can obtain recipient C's derived key by sending a key request to decryption server <b>24</b>. Because recipient C is a customer of the bank, the authentication service <b>30</b> may use preexisting recipient credentials such as recipient C's account name and PIN to authenticate recipient C. Once authentication service <b>30</b> has verified the identity of recipient C and determined that recipient C is authorized to obtain a copy of the derived key, the derived key for recipient C may be delivered to recipient C using key delivery service <b>32</b>.

0056Illustrative steps involved in setting up system <b>10</b> and in responding to derived key requests are shown in <figref idref="DRAWINGS">FIG. 2</figref>.

0057Set-up operations are performed at step <b>36</b>. During setup, master key <b>26</b> may be generated by the key generator <b>20</b>. Master key <b>26</b> may be generated, for example, from a random string with sufficient entropy (i.e., as many bits of entropy as the size of the master key). The random string may contain any suitable symbols. In general, there is an equivalency between numbers, letters, and other symbols, and other such schemes for representing information. Because of the inherent equivalency between these different representational schemes, the techniques involved in converting letters or symbols into numbers or for representing multiple numbers or strings as a single number or other such operations are not described in detail herein. The key generator is preferably implemented on a secure server so that the master secret cannot be compromised.

0058After setup operations such as the generation of the master key <b>26</b> have been performed, the key generator <b>20</b> can respond to requests for derived keys from other equipment at organization <b>18</b>. Derived keys are keys that are derived from the master key <b>26</b> for a specific purpose (e.g., to correspond to a particular recipient). If one or any number of derived keys is compromised, the security of other operations that rely on other derived keys is not also compromised. Moreover, the master key cannot feasibly be deduced from any collection of derived keys, which protects the master key.

0059The process of responding to a derived key request involves steps <b>38</b>, <b>40</b>, and <b>42</b>. These steps are typically performed at a different time than the set-up operations of step <b>36</b>, as indicated by dotted line <b>37</b>. Entities at organization <b>18</b> that can generate requests for derived keys may include gateway <b>22</b>, decryption server <b>24</b>, and users <b>12</b>. Users who request derived keys directly from key generator <b>20</b> may perform encryption using an encryption engine in their client software, without using a encryption engine on the gateway such as encryption engine <b>28</b>. The use of gateways such as gateway <b>22</b> is therefore optional, and may be dictated by organization policies. In systems with gateways, the gateway can request derived keys to use in encryption engine <b>28</b>. Decryption server <b>24</b> may request keys on behalf of users outside the organization. Key requests may be provided to key generator <b>20</b> over intranet <b>16</b>.

0060At step <b>38</b>, key generator <b>20</b> receives the derived key request from a trusted entity within the organization such as a gateway <b>22</b>, decryption server <b>24</b>, or a user in the organization such as sender A. Derived key requests are preferably only accepted from these trusted entities. Because the derived key is specific to a particular user (e.g., a customer), the derived key request preferably includes a user identifier (user ID). For example, when a derived key is being requested to encrypt a message for a recipient, the request for that key should include information on the identity of the recipient (i.e., a recipient ID).

0061At step <b>40</b>, the key generator <b>20</b> computes the derived key that has been requested. The derived key that has been requested is unique to the recipient ID that was provided in the request. If desired, the derived key may be made unique in other respects or may not include recipient ID information. For example, the derived key may be made unique to a particular date or date range, to enhance security. Each message may be required to have its own associated derived key, so that derived keys will be unique to both recipients and messages, although this greatly increases the burden on the key generator. Derived keys may be produced based on email addresses (a type of user ID) or on domain name information. For clarity, the present discussion focuses primarily on arrangements in which derived keys are derived from the master key based on user IDs. This is, however, merely illustrative. Any suitable inputs may be used by the key generator <b>20</b> when deriving the derived keys.

0062Any suitable one-way function may be used by the key generator <b>20</b> to produce a derived key from the master key and the recipient ID. As an example, the key generator <b>20</b> may compute the derived key for recipient A (dkeyA) using a hash function such as the hash function of equation 1. <br /><i>dkeyA=HMAC </i>(<i>master</i>-<i>key:recipient</i>_—<i>ID</i>)  (1)

0063In equation 1, master-key is the master key <b>26</b> and recipient_ID is information on the identity of the recipient. The value dKeyA is the derived symmetric key. The function HMAC is the well-known keyed-hash message authentication code function. In the notation used for equation 1 and the other equations herein, the argument of the function that appears before the colon is key information used by the cryptographic function (here an HMAC function). The argument(s) after the colon represent non-key information—in this case a recipient ID.

0064Using the function of equation 1, the key generator <b>20</b> can compute the keyed-hash value of the recipient's identity. The key derivation function of equation 1 is, however, merely illustrative. Any suitable one-way function that can operate on the master key and recipient ID to preserve the secrecy of the master key while making the derived key unique to the recipient ID may be used. Suitable one-way functions will be deterministic so that senders' and recipients' copies of the derived keys will match, without requiring the key generator to store any information specific to the individual derived keys. Suitable one-way functions will also be collision resistant so that a request for user X will not accidentally or adversarially produce a derived key for user Y (as an example). Suitable one-way functions include hash functions, keyed hash functions, digital signature functions, etc.

0065After producing the derived key in response to the derived key request, the key generator <b>20</b> may provide the derived key to the requester at step <b>42</b>. The key generator <b>40</b> may, for example, send the derived key to gateway <b>22</b>, a sender in the organization <b>18</b>, or decryption server <b>24</b> over the intranet <b>16</b> of the organization. Intranet <b>16</b> is controlled by the organization <b>18</b> and may therefore be assumed to be secure.

0066The derived key can be stored locally by the gateway <b>22</b>, sender in organization <b>18</b>, or decryption server <b>24</b> (e.g., until a time-stamped derived key expires). Storing the derived key in a local cache in this way may reduce the number of derived key requests that are handled by key generator <b>20</b>. When local storage is used, the requester of a derived key can check the local storage for a copy of the derived key when the key is needed. If a current version of the derived key is available in the local storage, the key request to the key generator <b>20</b> need not be made.

0067Illustrative steps involved in encrypting and sending a message from within organization <b>18</b> to an outside recipient who is a customer of the organization <b>18</b> are shown in <figref idref="DRAWINGS">FIG. 3</figref>.

0068At step <b>44</b>, a sender at the organization <b>18</b> such as sender A creates a message that is to be sent securely to a recipient such as recipient C who is a customer of the organization <b>18</b>. The sender's client software may create the message content or the message content may be obtained by sender A from another suitable source.

0069At step <b>46</b>, sender A sends the message to the recipient. As an example, sender A's email client may send an email message that is addressed to the recipient over intranet <b>16</b>. The message generally need not be encrypted at this point, because intranet <b>16</b> is assumed to be secure.

0070The outbound message from the sender may be received by the gateway <b>22</b> at step <b>48</b>. The gateway may have message management software or other suitable software that is used to implement policies such as encryption policies, virus scanning policies, archiving policies, etc. The gateway can use these policies and message attribute information such as message content information, source and destination address information, header information, etc. to determine how to handle each message. For example, the gateway can examine the domain name portion of each recipient's email address to determine whether or not a particular message should be encrypted.

0071Any suitable encryption policies may be implemented using gateway <b>22</b>. For example, gateway <b>22</b> may encrypt all outgoing messages, may encrypt messages being sent to a particular recipient or list of recipients (i.e., particular customers), may encrypt messages to those recipients whose email addresses contain a predetermined domain name, may encrypt messages to recipients based on their status or date of association with the organization, etc.

0072If the gateway <b>22</b> determines that the message should be encrypted, the gateway <b>22</b> may obtain a suitable derived key for the decryption process from key generator <b>20</b>. If the appropriate derived key is available locally, the gateway <b>22</b> may use the locally-stored version of the derived key. If the derived key is not available locally, the gateway generates a derived key request and provides the derived key request to the key generator <b>20</b> over intranet <b>16</b> at step <b>50</b>. The derived key request includes the identity of the recipient. Any suitable format may be used to provide recipient identity information to the key generator in the derived key request. For example, the recipient identity information may be provided in the form of a recipient ID (e.g., recipient C's email address or information based on recipient C's email address).

0073At step <b>52</b>, the key generator <b>20</b> receives and processes the derived key request. The derived key may be generated using the process of steps <b>38</b>, <b>40</b>, and <b>42</b> of <figref idref="DRAWINGS">FIG. 2</figref>. After the derived key has been generated, the derived key may be provided to the gateway <b>22</b> over intranet <b>16</b>.

0074At step <b>54</b>, the gateway <b>22</b> receives the derived key from the key generator <b>20</b>. The gateway may then use the encryption engine <b>28</b> to encrypt the message contents to produce ciphertext. Encryption engine <b>28</b> may be a symmetric key encryption engine that uses a symmetric key encryption algorithm such as AES or may use any other suitable encryption algorithm. The inputs to the encryption engine <b>28</b> include the derived key of the recipient and the unencrypted message contents. The output of the encryption engine <b>28</b> includes the encrypted version of the message (ciphertext).

0075At step <b>56</b>, the gateway <b>22</b> may relay the encrypted version of the message to recipient C. The encrypted message may pass through one or more mail servers (including mail servers inside and outside of organization <b>18</b>) before being received by recipient C.

0076Illustrative steps involved in receiving and decrypting the encrypted message are shown in <figref idref="DRAWINGS">FIG. 4</figref>.

0077At step <b>58</b>, the recipient (recipient C in this example) receives the message over communications network <b>14</b>. The message may be received by the recipient's client software running on the recipient's equipment <b>12</b>.

0078If the recipient's client software has a copy of an appropriate derived key available in a local cache, the client software may use that derived key to decrypt the message. If the derived key is not available locally, the recipient may obtain a copy of the derived key from organization <b>18</b>.

0079In particular, at step <b>60</b>, the recipient may generate a derived-key request and may provide the derived key request to the decryption server <b>24</b>. Any suitable arrangement may be used to make the derived key request. For example, the client of sender A or the gateway <b>22</b> may automatically include a clickable link (e.g., a web link) in the outgoing message. When recipient C receives the message, instructions in the message may prompt recipient C to click on the link. Clicking on the link may instruct recipient C's web browser or other suitable client software to transmit certain information in the link to a particular web address over communications network <b>14</b>. The information that is transmitted may include recipient identity information and may serve as a derived key request. The web address may be associated with decryption server <b>24</b>. This is merely one illustrative way in which a derived key request may be provided to decryption server <b>24</b>. Any suitable arrangement may be used if desired.

0080At step <b>62</b>, the decryption server <b>24</b> may process the derived key request by authenticating the recipient and establishing a secure communications channel between server <b>24</b> and the equipment of recipient C. Any suitable authentication technique may be used if desired. For example, the recipient's client may provide recipient credentials to the decryption server in the form of username and password information. The username and password information might be, for example, bank account name information and PIN information if organization <b>18</b> is a bank. During the authentication process, the decryption server uses authentication service <b>30</b> to verify the recipient's credentials. If the recipient's credentials match credential information maintained at the organization (and are consistent with the recipient ID in the derived key request), the decryption server <b>24</b> can conclude that the recipient who is requesting the derived key is authorized to obtain a copy of that recipient's derived key. During the authentication process, the server <b>24</b> and recipient C's equipment <b>12</b> establish a secure communications channel (e.g., an SSL link). This secure communications channel can be used for derived key delivery.

0081At step <b>64</b>, after the decryption server <b>24</b> has determined that the requesting recipient (recipient C in this example) is authorized to obtain a copy of the derived key, the decryption server <b>24</b> may request and obtain the derived key from key generator <b>20</b>. The key request made by decryption server <b>24</b> may be made over intranet <b>16</b> and may include the recipient ID. The decryption server <b>24</b> is at the same organization as the key generator <b>20</b>, so the key generator <b>20</b> trusts the decryption server. Accordingly, the key generator <b>20</b> may use the recipient ID information from the decryption server and the derived key generation process of steps <b>38</b>, <b>40</b>, and <b>42</b> (<figref idref="DRAWINGS">FIG. 2</figref>) to produce the derived key. The derived key may be provided to the decryption server over intranet <b>16</b>.

0082After the decryption server <b>24</b> obtains the derived key for recipient C from key generator <b>20</b> at step <b>64</b>, the decryption server <b>24</b> may provide the derived key to recipient C over communications network <b>14</b> at step <b>66</b>. The decryption server <b>24</b> may provide the derived key to recipient C securely by using the secure communications channel that was established at step <b>62</b> (e.g., over the SSL link).

0083At step <b>68</b>, recipient C receives the derived symmetric key from the decryption server <b>24</b> over the secure communications channel. The recipient may then use decryption engine <b>34</b> to decrypt the encrypted message (i.e., to decrypt the ciphertext). The inputs to decryption engine <b>34</b> are the encrypted version of the message (i.e., the ciphertext) and the derived key of recipient C. The output of the decryption engine <b>34</b> is the unencrypted version of the message contents.

0084The decryption engine <b>24</b> uses the same type of cryptographic algorithm that was used by encryption engine <b>28</b> (e.g., a symmetric key decryption algorithm using AES, etc.). With this type of symmetric key arrangement, the derived key that is used by the recipient to decrypt the message is the same as the derived key that was used by the sender to encrypt the message (using encryption engine <b>28</b> at gateway <b>22</b>). The decryption engine <b>34</b> may be part of a stand-alone software package or may be incorporated into existing client software (e.g., as a plug-in to an email client, etc.).

0085If desired, the recipient can ask the organization <b>18</b> to decrypt the encrypted message instead of asking for a copy of the derived key. In this type of arrangement, the decryption server may include a decryption engine such as decryption engine <b>34</b>. Rather than making a derived key request to the decryption server <b>24</b>, the recipient may make a decryption request to decryption server <b>24</b>. The decryption request can include the recipient's ID. The encrypted version of the message may be provided to the decryption server <b>24</b> with the decryption request or using any other suitable arrangement. Following successful authentication of the recipient, decryption server <b>24</b> may obtain the derived key from the key generator <b>20</b> and may use the local decryption engine to decrypt the contents of the message. The decrypted message contents may be provided to the recipient over a secure link such as an SSL link established during the authentication process.

0086In large organizations, it may be useful to use a hierarchical arrangement to limit the extent to which various components of the organization must trust each other. For example, an organization may have a North American unit and a European unit. The employees of the North American unit may be associated with one key generator within the organization. The employees of the European unit may be associated with another key generator within the organization. Because this type of arrangement allows parallel and separate security arrangements to be maintained within the same organization, it enhances security. For example, even if the master key of one key generator is compromised, the communications that are secured by the other key generator will remain secure.

0087A hierarchical security arrangement may also make it easier to deploy intranets <b>16</b> within the organization. For example, all entities connected to a local Ethernet at one location may trust one another and all entities connected to a local Ethernet at another location may trust one another. Each Ethernet network may form a local intranet for its associated location, but with a hierarchical security arrangement, it is not necessary to network the two locations together with the same level of trust and security, as each local intranet may be provided with its own delegated key generator (as an example).

0088The derived key mechanism described in connection with <figref idref="DRAWINGS">FIG. 2</figref> may be used to derive master keys for each delegated key generator. A super master key may be used to derive these master keys. Because each of the derived master keys is associated with a smaller portion of the organization, they may be referred to as sub-master keys. The delegated key generators may be placed under the control of separate business units within organization or other distinct units (e.g., units divided by geographic region, by management level or other status, by organizational lines, by employee function, etc.).

0089Once each organizational unit has its own delegated key generator, that delegated key generator may be used to generate derived keys for its associated customers. For example, the North American unit at an organization can use the North American unit's key generator to derive keys for the customers of the North American unit. The European unit's key generator may be used to derive keys for the customers of the European unit. The customers in this type of scenario will be fairly distinct, although they will not necessarily be mutually exclusive (i.e., a customer might be a customer of both the North American unit and the European unit, in which case the customer interacts with each unit using the respective derived key).

0090In a hierarchical key generator architecture, a super key generator has a super master key (sometimes called a master key) and each delegated key generator has a derived master key (sometimes called a master key or sub-master key). By using a single super master key, a single gateway such as gateway <b>22</b> may be used to perform all outgoing encryptions.

0091A diagram of an illustrative system <b>10</b> in which a hierarchical architecture has been used for the key generators is shown in <figref idref="DRAWINGS">FIG. 5</figref>. Super key generator <b>70</b> has a master key <b>72</b>. Super key generator <b>70</b> is operated by an organization <b>18</b> (<figref idref="DRAWINGS">FIG. 1</figref>) and may be used to derive sub-master keys for the various units of the organization. In <figref idref="DRAWINGS">FIG. 5</figref>, two organizational units are shown—unit E and unit F. In general, an organization may have any suitable number of units.

0092With one suitable arrangement, the organization's units are interconnected with the super key generator <b>70</b> through communications network <b>14</b>, which may be an intranet or other suitable network. This type of arrangement allows the super key generator <b>70</b> to distribute derived master keys to the units electronically. If desired, derived master keys may also be distributed manually (e.g., on disks or other media).

0093The organization controls the super key generator <b>70</b> and ensures the secrecy of the super master key <b>72</b>. Each unit has its own delegated key generator, each of which has its own sub-master key that has been derived from the super master key. In the example of <figref idref="DRAWINGS">FIG. 5</figref>, unit E has a delegated key generator <b>20</b>E. Delegated key generator <b>20</b>E uses a sub-master key <b>26</b>E to generate derived keys for the senders and customers of unit E. Sub-master key <b>26</b>E was derived from super master key <b>72</b> by super key generator <b>72</b> during system setup operations. Unit F has a delegated key generator <b>20</b>F. Delegated key generator <b>20</b>F uses a sub-master key <b>26</b>F to generate derived keys. Sub-master key <b>26</b>F was derived from super master key <b>72</b>.

0094Hierarchical key generator arrangements may have any suitable number of layers. For example, additional sub-layers of key generators each with an additional layer of derived master keys could be provided for sub-units of unit E. For clarity, the present invention will be described in connection with a two-layer arrangement in which a single super key generator of the organization generates derived sub-master keys for various units in the organization.

0095Hierarchical key generator architectures may be used in various system configurations. For example, system <b>10</b> may have a central gateway (such as gateway <b>22</b> of <figref idref="DRAWINGS">FIG. 1</figref>). The central gateway may operate as a clearinghouse for all outbound messages and may have an encryption engine (such as encryption engine <b>28</b> of <figref idref="DRAWINGS">FIG. 1</figref>) for encrypting messages. The encryption engine in the central gateway may encrypt messages using the derived keys of various recipients. The derived keys may be provided to the central gateway by the delegated key generators.

0096In the illustrative arrangement shown in <figref idref="DRAWINGS">FIG. 5</figref>, no gateway is used. Rather, each sender uses client software with an encryption engine to encrypt outgoing messages.

0097In a typical scenario, a user in a particular unit of the organization desires to send an encrypted message to a customer of that unit. For example, sender X of unit E may desire to send an encrypted message to recipient Y, who is a customer of unit E. Sender X obtains a derived key for encrypting recipient Y's message from delegated key generator <b>20</b>E. The encrypted message is sent to recipient Y over communications network <b>14</b>. Recipient Y generates a derived key request. The derived key request is processed by the organization and the requested derived key is provided to recipient Y to decrypt the message.

0098One or more decryption servers may be used in a system <b>10</b> that is based on a hierarchical key generator architecture.

0099In one suitable arrangement, a central decryption server is used to handle derived key requests from recipients. Each recipient's derived key request includes information identifying the recipient. Each recipient's derived key request may also include information identifying which unit's key generator was used to produce the derived key that the sender used in encrypting the message. The central decryption server can process this information to determine which delegated key generator created the derived key. The central decryption server can then route the key request to the delegated key generator in the appropriate unit of the organization.

0100If desired, a decryption server may be provided in each unit. This type of arrangement is shown in <figref idref="DRAWINGS">FIG. 5</figref>. Decryption server <b>24</b>E in unit E is used to obtain derived keys from delegated key generator <b>20</b>E. The derived keys from delegated key generator <b>20</b>E are provided to the customers of unit E for decrypting messages from senders in unit E. Decryption server <b>24</b>F in unit F is used to obtain derived keys from delegated key generator <b>20</b>F. The derived keys from delegated key generator <b>20</b>F are used by the customers of unit F to decrypt messages from senders of unit F.

0101Illustrative steps involved in using a system with a hierarchical key generator arrangement such as system <b>10</b> of <figref idref="DRAWINGS">FIG. 5</figref> to support secure messaging between senders and recipients are shown in <figref idref="DRAWINGS">FIG. 6</figref>.

0102At step <b>74</b>, set-up operations are performed. The organization of which unit E and unit F are a part uses super key generator <b>70</b> to produce derived master keys for various delegated key generators. The super key generator <b>70</b> may derive sub-master key <b>26</b>E from super master key <b>72</b> using equation 2a. <br /><i>sub</i>-<i>master</i>_—<i>key</i>_—<i>E=HMAC</i>(<i>super</i>_—<i>master</i>_—<i>key:unitE</i>)  (<b>2</b><i>a</i>) <br /> In equation 2a, sub-master_key_E is the value of sub-master key <b>26</b>E of <figref idref="DRAWINGS">FIG. 5</figref>. Super_master_key is the value of the super master key <b>72</b> that is maintained by super key generator <b>70</b>. UnitE is the name of the key generator <b>20</b>E. As described in connection with <figref idref="DRAWINGS">FIG. 2</figref>, any suitable one-way key derivation function may be used to produce the derived master keys for the delegated key generators such as key generator <b>20</b>E. In the example of equation 2a, the HMAC function is used.

0103The sub-master key derivation process is repeated for all units in the organization. For example, the super key generator <b>70</b> may derive sub-master key <b>26</b>F of <figref idref="DRAWINGS">FIG. 5</figref> from super master key <b>72</b> using equation 2b. <br /><i>sub</i>-<i>master</i>_—<i>key</i>_—<i>F=HMAC</i>(<i>super</i>_—<i>master</i>_—<i>key: unitF</i>)  (<b>2</b><i>b</i>) <br /> The master keys sub-master_key_E and sub-master_key_F may be distributed securely and stored locally by the respective delegated key generators <b>20</b>E and <b>20</b>F, as shown in <figref idref="DRAWINGS">FIG. 5</figref>. The super key generator <b>70</b> may be networked with the delegated key generators <b>26</b>E and <b>26</b>F through a secure intranet that allows keys to be distributed over trusted paths within the organization or keys may be distributed securely though any other suitable communications network <b>14</b>.

0104After the delegated key generators have been set up by deriving their sub-master keys using equations 2a and <b>2</b><i>b </i>or other suitable key derivation functions, messages may be sent securely at steps <b>76</b>, <b>78</b>, <b>80</b>, <b>82</b>, <b>84</b>, and <b>86</b>. Steps <b>76</b>, <b>78</b>, <b>80</b>, <b>82</b>, <b>84</b>, and <b>86</b> may be performed at a different time than the set-up operations of step <b>74</b>, as indicated by dotted line <b>75</b>.

0105At step <b>76</b>, a sender such as sender X in unit E obtains a derived key for a desired recipient such as recipient Y, who is a customer of unit E. The sender's client software may obtain the appropriate derived key to use in message encryption by making a derived key request to delegated key generator <b>20</b>E over the intranet <b>16</b> in unit E. The key request made by the sender includes information on the intended recipient of the message.

0106In this example, the intended recipient is recipient Y, so the key request may include information identifying recipient Y such as a recipient ID for recipient Y (e.g., recipient_Y_ID). The delegated key generator can then compute a locally derived key using equation 3 or any other suitable key derivation function, as described in connection with <figref idref="DRAWINGS">FIG. 2</figref>. <br /><i>key</i>_—<i>Y=HMAC </i>(<i>sub</i>-<i>master</i>_—<i>key</i>_—<i>E:recipient</i>_—<i>Y</i>_—<i>ID</i>)  (3) <br /> In equation 3, sub-master_key_E is the master key used by the delegated key generator <b>20</b>E in generating derived keys for the users of unit E and their associated customers. Recipient_Y_ID is information identifying the intended recipient of the message. Key_Y is the derived key. After Key_Y has been computed, the delegated key generator <b>20</b>E provides Key_Y to the requesting sender. The client software at the requesting sender includes an encryption engine such as encryption engine <b>28</b> of <figref idref="DRAWINGS">FIG. 1</figref> that uses Key_Y to encrypt the message for the recipient. The client software then sends the encrypted message to the recipient.

0107The encrypted message includes the encrypted content of the message (ciphertext) and unencrypted information that identifies the appropriate unit for the recipient to contact (i.e., unit E containing delegated key generator <b>20</b>E and decryption server <b>24</b>E in this example) when the recipient requests a copy of the derived key (Key_Y) for decrypting the message. The information identifying the delegated key generator and its unit may be provided with the message using any suitable arrangement. For example, the client software at sender X may automatically embed a web link in the outgoing message that contains recipient_Y_ID and a unique name for the delegated key generator <b>20</b>E and/or decryption server <b>24</b>E. The web link may also include web address information (e.g., a domain name) associated with decryption server <b>24</b>E that the recipient can use in contacting the decryption server <b>24</b>E with a key request. The recipient can click on this web link to initiate a key request to decryption server <b>24</b>E using the recipient's web browser.

0108At step <b>78</b>, after recipient Y receives the encrypted message from sender X over network <b>14</b>, recipient Y generates a derived key request and provides this request to the decryption server <b>24</b>E. The key request includes information identifying the recipient (e.g., recipient_Y_ID). The request may also include information that helps the decryption server route the derived key request to the appropriate delegated master key server. For example, the request may include the name of the appropriate delegated master key server that was sent to the recipient with the message.

0109In environments in which there is a central decryption server, the information on the name of the appropriate delegated key generator may be used to determine which delegated key generator to contact for a copy of the requested derived key. In arrangements of the type shown in <figref idref="DRAWINGS">FIG. 5</figref> in which there is a one-to-one correspondence between delegated key generators and decryption servers, the recipient may use information in the embedded web link to send the derived key request to a particular one of the decryption servers. This serves to implicitly define the delegated key generator associated with the request.

0110At step <b>80</b>, the decryption server <b>20</b>E authenticates recipient Y and establishes a secure channel between decryption server <b>20</b>E and recipient Y (e.g., an SSL link). Once recipient Y's authorization to obtain a copy of Key_Y has been verified, the decryption server <b>20</b>E may use the information in the request that identifies delegated key generator <b>20</b>E to generate a key request for Key_Y. The key request includes recipient_Y_ID, so that the delegated key generator <b>20</b>E can use equation 3 to generate Key_Y.

0111At step <b>82</b>, the delegated key generator <b>20</b>E receives the key request from decryption server <b>24</b>E. Key generator <b>20</b>E and decryption server <b>24</b>E operate in the same unit over the same intranet <b>16</b>, so decryption server <b>24</b>E is trusted by delegated key generator <b>20</b>E. The delegated key generator <b>20</b>E therefore generates the derived key for recipient Y. In particular, delegated key generator <b>20</b>E may use the information from the request on the recipient's identity (recipient_Y_ID) and the sub-master key <b>26</b>E in equation 3 to derive Key_Y. The delegated key generator <b>20</b>E may then provide Key_Y to the decryption server <b>24</b>E securely over the intranet <b>16</b> in unit E.

0112At step <b>84</b>, the decryption server provides Key_Y to recipient Y over the secure communications channel between decryption serer <b>24</b>E and recipient Y.

0113At step <b>86</b>, recipient Y uses a decryption engine such as decryption engine <b>34</b> of <figref idref="DRAWINGS">FIG. 1</figref> and Key_Y to decrypt the ciphertext and thereby access an unencrypted version of the message contents.

0114If desired, each unit may have a gateway for encrypting outgoing messages from the senders in that unit. The delegated key generator in each unit may produce the necessary derived keys for encryption.

0115In arrangements in which a global gateway is used to encrypt outgoing messages from senders in multiple units, the super key generator <b>70</b> may generate the derived keys using equations <b>4</b><i>a </i>and <b>4</b><i>b. </i><br /><i>Unit</i>_—<i>j</i>_—<i>key=HMAC </i>(<i>super</i>_—<i>master</i>_—<i>key:unit</i>_—<i>j</i>)  (<b>4</b><i>a</i>) <br /><i>Key</i>_j,k<i>=HMAC </i>(<i>Unit</i>_—<i>j</i>_—<i>key: recipient</i>_—<i>k</i>_—<i>ID</i>)  (<b>4</b><i>b</i>) <br /> In equations <b>4</b><i>a </i>and <b>4</b><i>b</i>, the super key generator uses the super-master key and the unit name to generate the sub-master key Unit_j_key, which is then combined with the recipient identity for recipient k (recipient_k_ID) to produce a derived key Key_j,kthat is specific to both the intended recipient of the message (recipient k in this example) and the appropriate unit and key generator (unit j and key generator j in this example).

0116If desired, a hierarchical mechanism may be used to sub-divide recipient identities. For example, there may be a number of sub-identities such as recipient_k_ID_<b>1</b>, recipient_k_ID_<b>2</b>, etc. associated with a recipient k whose ID is recipient_k_ID and who is a customer of an organization with a master key of master_key. The derived key for each sub-recipient of recipient_k_ID may be calculated using equations such as equations 5, 6a, and <b>6</b><i>b. </i><br /><i>Key</i>_—<i>k=HMAC </i>(<i>master</i>_—<i>key: recipient</i>_—<i>k</i>_—<i>ID</i>)  (5) <br /><i>Key</i>_—<i>k</i>_<b>1</b>=<i>HMAC </i>(<i>Key</i>_—<i>k: recipient</i>_—<i>k</i>_—<i>ID</i>_<b>1</b>)  (<b>6</b><i>a</i>) <br /><i>Key</i>_—<i>k</i>_<b>2</b>=HMAC (<i>Key</i>_—<i>k: recipient</i>_—<i>k</i>_—<i>ID</i>_<b>2</b>) (<b>6</b><i>b</i>) <br /> Equation 5 may be used to calculate the derived key Key_k from the master key and the identity of recipient k. Equation 6a can be used to calculate a derived key for recipient sub-identity recipient_k_ID_<b>1</b> based on the key for recipient k and the identity of recipient_k_ID_<b>1</b>. Equation 6b can be used to calculate a derived key for recipient sub-identity recipient_k_ID_<b>2</b>. Derived keys for other recipient sub-identities associated with recipient_k_ID may be calculated in the same way. The HMAC function is used to derive the keys of equations 5, 6a, and <b>6</b><i>b</i>. As described in connection with <figref idref="DRAWINGS">FIG. 2</figref>, other suitable key derivation functions may be used if desired.

0117The organization need only be aware of recipient identity recipient_k_ID. However, outside of the organization, the derived key for each sub-recipient can be calculated using the derived key for recipient_k_ID (i.e., Key_k). This allows Key_k to be used as a master key for a group of users managed by recipient k outside of the organization.

0118Recipient hierarchies may have any suitable numbers of layers. The example of equations 5, 6a and <b>6</b><i>b</i>, involves a two-layer scheme. Moreover, system <b>10</b> may have both a recipient hierarchy and a key generator hierarchy if desired.

0119Another aspect of the invention relates to authenticated derived keys. It may be desirable to be able to authenticate derived keys, particularly in environments without gateways. In systems without gateways, senders must obtain derived keys before they can encrypt an outgoing message. Problems can arise if a sender obtains an incorrect derived key due to an accidental or malicious transmission error or if an attacker masquerading as a key generator provides a sender with a fake key. Authenticated derived keys may be used to assure senders and recipients that they have properly obtained the keys that they have requested.

0120One suitable technique that may be used for key authentication is to use digital signatures. In this situation, the HMAC-based version of equation 1 becomes equation 1′. <br /><i>dkeyA=sign </i>(<i>private</i>-<i>key: recipient</i>_—<i>ID</i>)  (1′) <br /> In equation 1′, the keyed-hash function of equation 1 has been replaced with a deterministic digital signature function “sign.” In addition, the master key of equation 1 has been replaced with a private key (private-key). Equation 1′ serves the same derived key generation function as equation 1 in system <b>10</b>, but allows for entities to authenticate the derived keys they obtain.

0121A public key corresponding to the private key (called public-key) is made publicly accessible. The public key may, for example, be published by placing public-key on a suitable server inside or outside of the organization that is accessible to the public and/or to the organization <b>18</b> through a communications network <b>14</b>. The public key may also be made accessible only to entities within the organization (e.g., by placing public-key on an internal server connected to an intranet <b>16</b>).

0122In a system that uses this key authentication process, a derived key (dkeyA) may be verified using the verification operation of equation 7. <br />valid=verify(<i>public</i>-<i>key:recipient</i>_—<i>ID, dKeyA</i>)  (7) <br /> In equation 7, the function “verify” is used to compute the parameter valid based on the public key and the values of recipient_ID and dKeyA. If dKeyA is not an authentic derived key, the parameter valid will be false and a sender or other entity will know not to use the derived key. If parameter valid is true, the derived key is authentic. Because of the unforgeability property of digital signature functions such as sign, it is infeasible to compute a derived key without knowledge of the private key. The function “sign” is deterministic (or suitably derandomized to behave deterministically), which ensures that the sender and recipient will both compute the same derived key when equation 1′ is used.

0123With the systems described above, a sender in an organization can send an encrypted message to a recipient who is a customer of the organization. The recipient can contact the organization to obtain a copy of an appropriate derived symmetric key to use in decrypting the encrypted message. Recipients (acting as senders) can also use the derived symmetric keys to encrypt messages to the organization (e.g., a recipient can send an encrypted reply message back to a sender in the organization).

0124Sometimes a sender who is outside of an organization and who is not a customer of the organization would like to send an encrypted message to a recipient inside the organization or a recipient who is a customer of the organization. Because the sender is not affiliated with the organization, the sender does not have a preestablished relationship that allows the organization to authenticate the sender in the same way that a customer of the organization can be authenticated.

0125An illustrative system that may be used to enable non-customer senders to send secure messages to recipients at an organization or recipients who are customers of the organization is shown in <figref idref="DRAWINGS">FIG. 7</figref>.

0126In system <b>10</b> of <figref idref="DRAWINGS">FIG. 7</figref>, key generator <b>20</b> has a master key <b>26</b> that is used to produce derived keys. A sender P who desires to send an encrypted message to a recipient Q who is a customer of organization <b>18</b> may use a derived key from key generator <b>20</b> to encrypt the message. The message may be encrypted at the sender's equipment <b>12</b> or by a gateway <b>22</b>. When recipient Q receives the encrypted message, recipient Q may request a copy of the derived key from the decryption server <b>24</b>. Decryption server <b>24</b> may authenticate recipient Q and obtain a copy of the derived key from key generator <b>20</b>. The decryption server <b>24</b> can then provide the derived key to recipient Q over a secure channel. Recipient Q can use the derived key to decrypt the encrypted message from sender P. Recipient Q can also use the derived key to encrypt a new message for sender P (e.g., a reply message that is responding to sender P's original message). Sender P has a copy of the derived key (or can obtain one), so sender P can decrypt recipient Q's encrypted reply.

0127Unlike recipient Q, sender S is not a customer of the organization <b>18</b>. Because there is no preexisting relationship between sender S and the organization <b>18</b>, organization <b>18</b> does not have credentials to use in authenticating sender S. Sender S therefore cannot authenticate to the decryption server <b>24</b> to obtain a copy of a derived key in the same way that recipient Q can authenticate to the decryption server <b>24</b>. Because sender S is not part of organization <b>18</b>, it is not desired to entrust sender S with the derived key of recipient Q.

0128In accordance with the present invention, organization <b>18</b> is provided with a policy server <b>88</b>. Policy server <b>88</b> is shown as a separate server in the example of <figref idref="DRAWINGS">FIG. 7</figref>, but, if desired, policy server <b>88</b> can be implemented as part of gateway <b>22</b>, as part of decryption server <b>24</b>, as part of key generator <b>20</b>, or as part of any other entity affiliated with organization <b>18</b>. Policy server handles the generation of derived keys for non-customer senders such as sender S. A sender S can obtain such a non-customer message key when it is desired to send a secure message to a recipient who is a customer of the organization or who is at the organization <b>18</b>.

0129The illustrative recipient R of <figref idref="DRAWINGS">FIG. 7</figref> is located within organization <b>18</b>, but recipient R could also be a recipient such as recipient Q who is a customer of the organization.

0130Illustrative steps involved when a non-customer sender such as sender S encrypts and sends a secure message to a recipient such as recipient R are shown in <figref idref="DRAWINGS">FIG. 8</figref>.

0131At step <b>90</b>, sender S contacts policy server <b>88</b> to request a key for sending a message to recipient R. Sender S may, for example, use a web browser running on sender S's equipment to access a web page that is associated with the policy server <b>88</b>.

0132At step <b>92</b>, the sender's web browser authenticates the policy server. Standard web browsers have built-in capabilities for using public-key infrastructure (PKI) techniques to perform this type of authentication (e.g., by verifying a certificate associated with the policy server's web page). During the process of authenticating the policy server, a secure communications channel (e.g., an SSL link) is established between the policy server <b>88</b> and sender S.

0133The key request from sender S includes information on the identity of the intended recipient (recipient_R_ID).

0134At step <b>94</b>, the policy server <b>88</b> requests and obtains a derived symmetric key (Der_Key) for sender S from key generator <b>20</b>. The policy server <b>88</b> also generates a random number N. The number N need not be truly random, but each such number is preferably only used once for each recipient. For instance, N could be based on a time stamp or a counter, although such approaches would respectively require the key generator to maintain a clock or a counter. The key request made by the policy server <b>88</b> includes information on the identity of the recipient (i.e., the value of recipient_R_ID that was provided by sender S). The key generator <b>20</b> can compute the derived key Der_Key using equation 8. <br /><i>Der</i>_—<i>Key=HMAC </i>(<i>master</i>-<i>key: recipient</i>_—<i>R</i>_—<i>ID</i>)  (8) <br /> In equation 8, master-key is the master key of the key generator <b>20</b> and recipient_R_ID is a unique identifier for recipient R. The HMAC function of equation 8 (and the other key derivation equations herein) is merely illustrative. Any suitable hash function or other one-way function may be used to derive Der_Key, as described in connection with <figref idref="DRAWINGS">FIG. 2</figref>.

0135At step <b>96</b>, the policy server <b>88</b> uses the derived key Der_Key and the random number N to compute the value of the non-customer message key Key-N. The policy server <b>88</b> may use any suitable key derivation function as described in connection with <figref idref="DRAWINGS">FIG. 2</figref>. For example, the policy server <b>88</b> may produce the non-customer message key Key-N using equation 9. <br /><i>Key</i>-<i>N=HMAC </i>(<i>Der</i>_—<i>Key:N</i>)  (9)

0136At step <b>98</b>, the policy server <b>88</b> provides the non-customer symmetric message key Key-N to sender S over the secure channel.

0137At step <b>100</b>, sender S uses the non-customer message key Key-N to encrypt a message for recipient R. Sender S may use an encryption engine on sender S's equipment to encrypt the message using Key-N to produce ciphertext.

0138At step <b>102</b>, sender S sends the encrypted message to recipient R at organization <b>18</b>. The sender may send both the ciphertext produced at step <b>100</b> and the value of N as part of the encrypted message or may provide the ciphertext and N in separate associated transmissions. The value of N that is transmitted from sender S to recipient R is unencrypted.

0139Illustrative steps involved in decrypting the message from sender S are shown in <figref idref="DRAWINGS">FIG. 9</figref>.

0140At step <b>104</b>, recipient R receives the encrypted message including the unencrypted value of N and the ciphertext.

0141At step <b>106</b>, recipient R requests a copy of the derived key Der_Key from the policy server or simply retrieves it from recipient's local cache if available. The key request includes the identity of recipient R (recipient_R_ID), so that the key generator will know which key to generate. During step <b>106</b>, the recipient authenticates to the policy server. A secure communications channel (e.g., an SSL link) is established between recipient R and the policy server <b>88</b> during authentication.

0142If the policy server <b>88</b> and recipient are both within the organization, the process of authenticating the recipient may by implicit (e.g., policy server <b>88</b> may only need to confirm that the key request is from a user at the organization who is contacting the policy server over the organization's intranet). More extensive authentication techniques (e.g., involving the verification of recipient R's credentials by the policy server) may be used if desired. This type of authentication approach may be used, for example, when the recipient is a customer of organization <b>18</b> such as recipient Q rather than a user at organization <b>18</b>.

0143If desired, the policy server may also be authenticated by the recipient (e.g., using PKI techniques) to ensure that the recipient is obtaining the requested key from a trusted source.

0144At step <b>108</b>, the policy server uses the recipient ID information (recipient_R_ID) from the recipient's key request to request the derived key Der_Key from the key generator <b>20</b>.

0145At step <b>110</b>, the key generator <b>20</b> uses equation 8 (or other suitable function) to produce Der_Key for the policy server.

0146At step <b>112</b>, the policy server <b>88</b> provides the derived key Der_Key to the recipient over the secure channel.

0147At step <b>114</b>, the recipient uses the received value of N from the sender S and the derived key (Der_Key) from the policy server <b>88</b> to compute the value of the non-customer message key Key-N (e.g., using equation 9 or other appropriate one-way function). (The equation that is used when the policy server computes Key-N for the sender must match the equation that is used when the recipient computes Key-N.)

0148At step <b>116</b>, the recipient uses the non-customer message key Key-N to decrypt the ciphertext and thereby access the contents of the message.

0149The foregoing is merely illustrative of the principles of this invention and various modifications can be made by those skilled in the art without departing from the scope and spirit of the invention.