Secure messaging system with derived keys
Abstract
This record has no abstract on file.
Term
Projected expiry 19 August 2031.
- Priority
- Filed
- Granted
- Today
- Projected expiry
6 claims: 1 independent, 5 dependent
- 1対称鍵の暗号技術を使用して、 組織計算機器に関連付けられた 組織外の送信者 に関連付けられた送信者計算機器 と、 前記 組織内または前記組織の顧客である受信者 に関連付けられた受信者計算機器 との間の安全な通信をサポートする方法であって、 前記送信者計算機器が、 前記送信者 計算機器 と前記組織 計算機器 との間に安全な通信チャネルを確立するステップと、 前記組織計算機器が 、マスター鍵から対称鍵を導出するステップと、 前記組織計算機器が 、乱数Nを生成するステップと、 前記組織計算機器が 、前記導出対称鍵および前記乱数Nに基づいて、非顧客対称メッセージ鍵を生成するステップと、 前記組織計算機器が、 前記安全な通信チャネルを通じて、前記送信者 計算機器 に、前記非顧客対称メッセージ鍵および前記乱数Nを提供するステップと、 前記送信者計算機器が、 前記受信者 計算機器 に対するメッセージを暗号化するために、前記非顧客対称メッセージ鍵を使用するステップと を含む、方法。
- 2前記 送信者計算機器が 前記メッセージを暗号化するステップは、暗号文を生成し、前記方法は、 前記送信者計算機器が、 前記組織外の前記送信者から の 前記暗号化メッセージを 前記受信者計算機器に 送信するステップをさらに含み、送信される前記暗号化メッセージは、前記暗号文および前記乱数Nを含む、請求項1に記載の方法。
- 3前記 送信者計算機器が 前記メッセージを暗号化するステップは、暗号文を生成し、前記方法は、 前記送信者計算機器が、 前記組織外の前記送信者から の 前記暗号化メッセージを 前記受信者計算機器に 送信するステップであって、送信される前記暗号化メッセージは、前記暗号文および前記乱数Nを含む、ステップと、 前記受信者計算機器が 、前記非顧客メッセージ鍵を取得するために、前記乱数Nを使用するステップと をさらに含む、請求項1に記載の方法。
- 4前記組織 計算機器 は、サーバーを 含み 、前記受信者は、受信者IDを有し、前記 送信者計算機器が 前記メッセージを暗号化するステップは、暗号文を作成し、前記方法は、 前記送信者計算機器が、 前記組織外の前記送信者から の 前記暗号化メッセージを 前記受信者計算機器に 送信するステップであって、送信される前記暗号化メッセージは、前記暗号文および前記乱数Nを含む、ステップと、 前記 受信者計算機器が 、前記サーバーから前記非顧客メッセージ鍵を取得する際に、前記乱数Nを受信して、前記受信者IDおよび前記乱数Nを使用するステップと をさらに含む、請求項1に記載の方法。
- 5前記組織 計算機器 は、サーバーおよび鍵生成器を 含み 、前記受信者は、受信者IDを有し、前記 送信者計算機器が 前記メッセージを暗号化するステップは、暗号文を生成し、前記方法は、 前記送信者計算機器が、 前記組織外の前記送信者から の 前記暗号化メッセージを 前記受信者計算機器に 送信するステップであって、送信される前記暗号化メッセージは、前記暗号文および前記乱数Nを含む、ステップと、 前記受信者 計算機器が 、前記サーバーから前記非顧客メッセージ鍵を要求するために、前記乱数Nを受信して、前記受信者IDおよび前記乱数Nを使用するステップと、 前記サーバー が 、前記鍵生成器から前記導出対称鍵を取得するために、前記受信者IDを使用して、前記鍵生成器からの前記導出対称鍵および前記受信者 計算機器 からの前記乱数Nを使用して、前記受信者 計算機器 に対する前記非顧客メッセージ鍵を計算するステップと をさらに含む、請求項1に記載の方法。
- 6前記受信者は、受信者IDを有し、 前記組織計算機器が 前記マスター鍵から前記対称鍵を導出するステップは、 前記組織計算機器が、 前記導出対称鍵を生成するために、前記マスター鍵および受信者IDにHMAC関数を適用するステップを含む、請求項1に記載の方法。
Independent claims6
133 paragraphs, as filed
This application claims the priority of US Patent Application No. 10 / 887,721 (filed July 9, 2004).
The present invention relates to a cryptosystem, and more particularly to a cryptosystem using a derived key.
Encryption of sensitive electronic communications, such as email messages, is often desirable.
Two types of keys (public key and private key) are used in public key cryptography systems. The sender can use the recipient's public key to encrypt the message. Each recipient has a private key that is used to decrypt the message to that recipient.
In symmetric key cryptography, the sender of a message uses the same key that the recipient of the message uses to decrypt the message to encrypt the message. The advantage of symmetric key cryptography is that symmetric key encryption and cryptanalysis algorithms are computationally efficient.
Secure message senders and recipients often have an existing relationship with the organization. For example, a bank may want to securely send its customer's statement of deposit. In another example, a customer who receives an encrypted deposit statement may want to reply to the bank with a secure email message to inquire.
<p num="0007"> An object of the present invention is to provide a messaging system that facilitates secure communication using a symmetric key.</p>
<p num="0008"> Symmetrical message keys can be used to send secure messages between senders and recipients. Organizations may also have a key generator that derives a symmetric message key from the master key. The key generator can generate a derived key by applying a one-way function such as an HMAC function or another hash function to the master key and the recipient's identity information (ie, the recipient ID). .. The derived key obtained is unique to each recipient. Even if the derived key fails, the master key does not fail, which helps ensure security.</p><p num="0009"> The sender can use the derived key to encrypt the message to the recipient who is the customer of the organization. Since the recipient is a customer of the organization, there is an existing relationship between the recipient and the organization. Therefore, the organization has the recipient's credential information that can be used to authenticate the recipient.</p><p num="0010"> When the recipient receives the encrypted message, the recipient can authenticate to the organization and request a copy of the derived key to decrypt the message. The derived key request includes the recipient ID. The recipient ID for which the key request from the recipient is provided can be used by the key generator to derive a new copy of the derived key. A new copy of this derived key can then be provided to the recipient through a secure communication channel. The recipient can use the decryption engine on the recipient's device to decrypt the encrypted message with a copy of the derived key received.</p><p num="0011"> The hierarchical key generator architecture can be used for organizations with multiple organizational units. Each unit may each have a delegation key generator that produces a derived symmetric key for the sender within that unit. The organization can have a super key generator, which has a super master key. The super key generator can derive a submaster key for each delegation key generator.</p><p num="0012"> The symmetric key mechanism can also be used to allow non-organizational senders who are not customers of an organization to send messages to recipients within that organization. An organization can have a key generator to create a derived key based on a master key and a recipient ID. The policy server in the organization can use the derived key and the random number N to generate (derive) the non-customer symmetric key.</p><p num="0013"> For example, a key generator can apply HMAC functions to a master key and a recipient ID to generate a derived key. The policy server can generate a random number N and can apply an HMAC function to the derived key from the key generator and the random number N to generate a non-customer message key.</p><p num="0014"> If the sender wants 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 a non-customer message key through a secure link. The sender uses the non-customer message key to encrypt the message to the recipient. The sender then sends the recipient an encrypted message containing a value of N. At the recipient, the recipient can use the recipient ID and N values 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.</p><p num="0015"> Further features, properties, and various advantages of the present invention will become more apparent from the accompanying drawings and the detailed description of the preferred embodiments below.<u style="single">For example, the present invention provides the following items.</u><u style="single">(Item 1)</u><u style="single"> In an organization, a method for a sender to send a message to a recipient who is a customer of the organization through a communication network, wherein the recipient has a recipient identity (ID).</u><u style="single"> A symmetric key in the organization for encrypting the message from the master key using a one-way function, wherein the input of the one-way function includes a master key and the recipient ID. And the steps to derive</u><u style="single"> A step of encrypting the message using the derived symmetric key in the organization and transmitting the message to the recipient through the communication network.</u><u style="single"> The step of receiving the encrypted message at the recipient, and</u><u style="single"> A step of submitting a request for a derived symmetric key to the organization through the communication network in the receiver, wherein the request for the derived symmetric key includes the recipient ID.</u><u style="single"> A step of authenticating the recipient to the organization through the communication network and establishing a secure communication channel between the organization and the recipient.</u><u style="single"> In response to the recipient's request for the derived symmetric key, the recipient generates the derived symmetric key for use in decrypting the message and provides the recipient with the derived symmetric key through the secure communication channel. Steps to provide and</u><u style="single"> Including methods.</u><u style="single">(Item 2)</u><u style="single"> The method according to item 1, wherein the step of deriving the symmetric key includes a step of using a hash function to derive the symmetric key.</u><u style="single">(Item 3)</u><u style="single"> The method according to item 1, wherein the step of deriving the symmetric key includes a step of using a digital signature function to derive the symmetric key.</u><u style="single">(Item 4)</u><u style="single"> The method of item 1, wherein the organization has a gateway and the step of encrypting the message comprises using the derived symmetric key to encrypt the message at the gateway.</u><u style="single">(Item 5)</u><u style="single"> The organization has a gateway and a key generator, and the step of encrypting the message is</u><u style="single"> A step of using the gateway in the organization to provide the key generator with a request for a derived key containing the recipient ID in the organization.</u><u style="single"> With the step of using the key generator to calculate the derived key using the one-way function in response to a request for the derived key from the gateway.</u><u style="single"> The method according to item 1, including.</u><u style="single">(Item 6)</u><u style="single"> The organization has a server and a key generator, and the step of authenticating the recipient to the organization includes the step of using the server to authenticate the recipient, the recipient having said the message. The step of generating the derivation symmetric key used in decryption is a step of using the key generator to generate the derivation symmetric key for the recipient in response to a request for the derivation key from the server. The method described in item 1, including.</u><u style="single">(Item 7)</u><u style="single"> The organization has a decryption server and a key generator, and the step of authenticating the recipient through the communication network and establishing a secure communication channel between the organization and the recipient is the decryption server. The recipient comprises the step of using the decryption server to authenticate the recipient to and establish a secure socket layer (SSL) link between the decryption server and the recipient. The step of generating the derived symmetric key used in decrypting the message is to generate the derived symmetric key for the recipient in response to a request for the derived key from the decryption server. The step of providing the decryption key to the recipient, including the step to be used, uses the decryption server to provide the decryption key from the key generator to the recipient through the SSL link. The method described in item 1, including steps.</u><u style="single">(Item 8)</u><u style="single"> In an organization, a method for a sender to send a message to a recipient, wherein the organization includes a gateway, a key generator, a server, the sender, the gateway, the key generator, and the server. The receiver is outside the organization, the recipient is a customer of the organization, and the recipient has a recipient identity (ID), said. The method is</u><u style="single"> To derive a symmetric key message for encrypting the message from the master key using the HMAC function, which is an HMAC function and the input of the HMAC function includes the master key and the recipient ID. Steps to use the key generator and</u><u style="single"> A step of providing the derived symmetric key from the key generator to the gateway through the intranet.</u><u style="single"> A step of encrypting the message at the gateway using the derived symmetric key to generate an encrypted message.</u><u style="single"> A step of providing the encrypted message from the gateway to the recipient outside the organization via the Internet.</u><u style="single"> In the recipient, the step of receiving the encrypted message and</u><u style="single"> A step of authenticating the recipient to the server and establishing a secure socket layer (SSL) link between the server and the recipient.</u><u style="single"> A step of providing a request for a derived symmetric key from the receiver to the server, wherein the request for the derived symmetric key includes the recipient ID.</u><u style="single"> To use the receiver ID to obtain the derived symmetric key from the key generator through the intranet and to provide the recipient with the derived symmetric key obtained from the key generator through the SSL link. In addition to the steps to use the server,</u><u style="single"> With the step of using the derived symmetric key provided by the server through the SSL link at the recipient to decrypt the encrypted message.</u><u style="single"> Including methods.</u><u style="single">(Item 9)</u><u style="single"> 8. The method of item 8, further comprising the step of deriving the master key from the supermaster key using a one-way function.</u><u style="single">(Item 10)</u><u style="single"> A method for using a hierarchical key generator architecture to support secure communication to an organization with multiple units, said organization with a super key generator and multiple delegation key generators. And the above method</u><u style="single"> A step in which the superkey generator is used to generate a plurality of derived submaster keys from a supermaster key, wherein each derived submaster key is delegated in each of the plurality of units. The steps provided to each one of the key generators,</u><u style="single"> In a given unit of said units, allow senders within said given unit to compose messages that are securely communicated to recipients outside the organization who are customers of said given unit. A step in which the recipient has a recipient identity (ID).</u><u style="single"> In the given unit, the one-way function whose input is provided to its delegation key generator using the one-way function containing the submaster key and the recipient ID. The step of using the delegation key generator of the given unit to derive a symmetric key for encrypting the message from the submaster key.</u><u style="single"> A step of encrypting the message using the derived symmetric key in the given unit and transmitting the message to the recipient through a communication network.</u><u style="single"> The step of receiving the encrypted message at the recipient, and</u><u style="single"> In the receiver, a step of submitting a request for a derived symmetric key to the given unit through the communication network, wherein the request for the derived symmetric key includes the recipient ID.</u><u style="single"> A step of authenticating the recipient to the given unit through the communication network and establishing a secure communication channel between the given unit and the recipient.</u><u style="single"> To generate the derived symmetric key that the recipient uses in decrypting the message, the delegated key generator of the given unit is used to the recipient through the secure communication channel. With the step of providing the derived symmetric key from a given unit</u><u style="single"> Including methods.</u><u style="single">(Item 11)</u><u style="single"> The given unit has a decryption server, and the step of authenticating the recipient to the given unit uses a pre-established recipient credit certificate to the decryption server. 10. The method of item 10, comprising the step of authenticating the recipient.</u><u style="single">(Item 12)</u><u style="single"> The method according to item 10, wherein the step of encrypting the message includes a step of encrypting the message at the sender.</u><u style="single">(Item 13)</u><u style="single"> 10. The method of item 10, wherein the step of submitting the derived symmetric key request comprises submitting a request comprising the distinguished name of the delegation key generator of the given unit.</u><u style="single">(Item 14)</u><u style="single"> Item 10. The step of generating a plurality of derived submaster keys from the supermaster key includes the step of calculating a value for an HMAC function using the supermaster key and the name associated with each unit as inputs. the method of.</u><u style="single">(Item 15)</u><u style="single"> A method of using symmetric key cryptography to support secure communication between a sender outside an organization and a recipient within the organization or a customer of said organization.</u><u style="single"> Steps to establish a secure communication channel between the sender and the organization,</u><u style="single"> In the organization, the step of deriving the symmetric key from the master key,</u><u style="single"> In the organization, the step of generating a random number N and</u><u style="single"> In the organization, a step of generating a non-customer symmetric message key based on the derived symmetric key and the random number N,</u><u style="single"> The step of providing the sender with the non-customer symmetric message key and the random number N through the secure communication channel.</u><u style="single"> With the step of using the non-customer symmetric message key in said sender to encrypt a message to said recipient</u><u style="single"> Including methods.</u><u style="single">(Item 16)</u><u style="single"> In said sender, the step of encrypting the message further comprises generating a ciphertext, and the method further comprises sending the encrypted message from said sender outside the organization to said recipient. The method according to item 15, wherein the encrypted message includes the ciphertext and the random number N.</u><u style="single">(Item 17)</u><u style="single"> The step of encrypting the message at the sender produces a ciphertext, the method of which is:</u><u style="single"> A step of transmitting the encrypted message from the sender outside the organization to the receiver, wherein the transmitted encrypted message includes the ciphertext and the random number N.</u><u style="single"> With the step of using the random number N in the recipient to obtain the non-customer message key.</u><u style="single"> The method of item 15, further comprising.</u><u style="single">(Item 18)</u><u style="single"> The organization has a server, the recipient has a recipient ID, the step of encrypting the message at the sender creates a ciphertext, the method.</u><u style="single"> A step of transmitting the encrypted message from the sender outside the organization to the receiver, wherein the transmitted encrypted message includes the ciphertext and the random number N.</u><u style="single"> When the receiver acquires the non-customer message key from the server, the step of receiving the random number N and using the recipient ID and the random number N.</u><u style="single"> The method of item 15, further comprising.</u><u style="single">(Item 19)</u><u style="single"> The organization has a server and a key generator, the recipient has a recipient ID, and the step of encrypting the message at the sender generates a ciphertext, the method.</u><u style="single"> A step of transmitting the encrypted message from the sender outside the organization to the receiver, wherein the transmitted encrypted message includes the ciphertext and the random number N.</u><u style="single"> A step of receiving the random number N and using the recipient ID and the random number N in order to request the non-customer message key from the server at the receiver.</u><u style="single"> In the server, in order to obtain the derived symmetric key from the key generator, the recipient ID is used, the derived symmetric key from the key generator and the random number N from the receiver are used. And the step of calculating the non-customer message key for the recipient</u><u style="single"> The method of item 15, further comprising.</u><u style="single">(Item 20)</u><u style="single"> The receiver has a receiver ID, and the step of deriving the symmetric key from the master key is a step of applying an HMAC function to the master key and the recipient ID in order to generate the derived symmetric key. The method of item 15, including.</u></p>
<figref num="1">FIG. 5 is a diagram of an exemplary system capable of transmitting a secure message between a sender and a receiver according to the present invention.</figref><figref num="2">FIG. 5 is a flow chart of exemplary steps associated with setting up a system of the type shown in FIG. 1 and satisfying the requirements for a derived key according to the present invention.</figref><figref num="3">FIG. 5 is a flow chart of exemplary steps involved in encrypting and transmitting a secure message using the type of system shown in FIG. 1 according to the present invention.</figref><figref num="4">FIG. 5 is a flow chart of exemplary steps involved in receiving and decoding a secure message using the type of system shown in FIG. 1 according to the present invention.</figref><figref num="5">FIG. 5 is a diagram of an exemplary hierarchical mechanism that allows a key generator to create a master key (submaster key) for a related key generator according to the present invention.</figref><figref num="6">FIG. 5 is a flow chart of exemplary steps associated with the setup and use of the types of systems shown in FIG. 5 for sending and receiving secure messages according to the present invention.</figref><figref num="7">FIG. 5 is a diagram of an exemplary system that can be used by a sender who is not a customer of an organization to allow a sender in the organization to send a secure message to a recipient in the organization.</figref><figref num="8">FIG. 5 is a flow chart of exemplary steps that can be used by a sender in the type of system shown in FIG. 7 for encrypting a secure message and sending it to a recipient according to the present invention.</figref><figref num="9">FIG. 5 is a flow chart of exemplary steps that can be used by a receiver in a system of the type shown in FIG. 7 to receive and decode a secure message from a sender according to the present invention.</figref>
The present invention relates to cryptographic systems, such as systems for supporting secure messaging. The present invention also relates to a method of using the system in question.
The type of device shown in System 10 of FIG. 1 can be used to support secure communication between the sender and the receiver. The sender is the user who sends the message. The recipient is the user who receives the message. A given user can be a sender at one time and a recipient at another, because users can generally both send and receive messages.
Some users in System 10 may belong to an organization such as Organization 18. Other users may belong to different organizations or may not belong to any organization.
In the example of FIG. 1, sender A and user B are users belonging to organization A. Recipient C and User D are users who do not belong to Organization A.
Some user activity within System 10 involves human intervention, such as sending an email message from person to person. For example, a person who wants to send a personally constructed text message must enter the message before it is encrypted and sent to the appropriate recipients. Other user activities in System 10 may be fully automated so that human intervention is largely eliminated. As an example, an organization can use a computer to automatically send a message to each of its customers. In this type of scenario, the computer acts as a kind of user (ie, sender in this example). The following description uses the terms "sender," "receiver," and "user" to describe both the person and the device.
E-mail messages are used as an example, but the messages carried by the system do not have to be e-mail messages. The message may be an email message, an instant message, or any other suitable electronically transmitted message. The message may contain any digital information (eg, text, graphics, audio, video, commands, executable code, data, etc.) that is transmitted electronically between the sender and the receiver.
Users in system 10 can use device 12 to communicate with each other. Device 12 (and devices for other entities in the system) includes, for example, personal computers, portable computers, workstations, mainframe computers, and computers connected to the Internet using host computers within a local area network. Included are network computers such as terminals or computing devices such as terminals, handheld computers, mobile phones, or other suitable electronic devices.
The devices of FIG. 1 can be interconnected by communication paths within the communication network 14 and the intranet 16.
Network 14 includes the Internet and other wide area networks, one or more intranets, local area networks, exchange telephone networks, networks such as virtual private networks, networks including dedicated lines, networks based on wired or wireless routes, or Examples include other networks formed using other suitable network technologies.
An intranet, such as an intranet 16, is a communication network used to network multiple users in a particular organization. For example, intranet 16 in FIG. 1 is associated with organization 18 and is used to interconnect devices such as device 12, key generator 20, gateway 22, and decryption server 24 for sender A and user B. Will be done. An intranet such as Intranet 16 may be a local area network or a wide area network. An exemplary intranet for a small business can be, for example, a ten-seat Ethernet® network. A large organization can have multiple campuses at remote locations. The organization's intranet can be constructed from an Ethernet®-based local area network on the Internet at each campus linked to each other by a secure route.
The system 10 can have a key generator, such as the key generator 20, for generating keys. The key generator 20 can derive a plurality of user-specific keys from the master key 26.
The message can be encrypted using an encryption engine and can be decrypted using a cryptanalysis engine. Any suitable cryptographic algorithm can be used in System 10 for message encryption and decryption. It is preferably a symmetric key cryptosystem. Suitable symmetric key algorithms include AES (Advanced Encryption Standard), DES (Data Encryption Standard), Triple DES, and the like.
In one preferred mechanism, all messages from the sender of organization 18 are forwarded to network 14 via intranet 16 and gateway 22. The gateway 22 can have an encryption engine 28 for encrypting messages. After receiving the encrypted message, the recipient can use a cryptanalysis engine such as Recipient C's cryptanalysis engine 34 to decrypt the message.
Symmetric key cryptography uses the same key for both encryption and cryptanalysis operations. Recipients such as Recipient C outside of Organization 18 can obtain a copy of the key at the gateway 22 used for encryption by the encryption engine 28 making a key request to Organization 18. .. Once the key is obtained, the recipient can use a cryptanalysis engine, such as cryptanalysis engine 34, to decrypt the message and access its contents.
The decryption server 24 can be used to process the request for the key. The authentication service 30 can be used to authenticate the user before the requested key is provided to the user. The key delivery service 32 can be used to satisfy the key request of the authenticated requester.
In one preferred scenario, the user may use an e-mail application, an e-mail application with a web browser engine (ie, built-in web browser functionality), a web browser application, a document creation and editing application, an image viewer, a media player, etc. Has a software application (client software), such as. Cryptography and cryptanalysis engine functionality may be provided using standalone cryptography and cryptanalysis applications, or using cryptographic and cryptanalysis software components integrated with these applications. Good. As an example, an email program, such as the email program used by the recipient, can have a decryption engine. The encryption engine may be provided as part of the native code within the email application or may be included as a plug-in module. As another example, the software used to manage the gateway, such as Gateway 22, may have a built-in cryptographic engine, or the cryptographic engine may be provided as a separate software component.
Various computers can be used for system 10. For example, a computing device can be used to perform the functions of a server or other computer device at each key generator 20, gateway 22, and decryption server 24. Servers can also be used to support the functionality of certificate authorities, mail servers, and other entities. The server may be co-located with the sender or sender's organization, connected to network 14 as an independent third party service, part of network 14's infrastructure, or given reception. It can be associated with a person's organization, co-located with the recipient, key generator, or other device, or used in one or more of these locations. These are just exemplary mechanisms that do not need to be mutually exclusive.
The server can be formed using a single computer or multiple computers. You can run multiple servers on one computer. If desired, the functionality of a single server can be provided by computers distributed through multiple different physical locations. Functions performed using the servers in System 10 can generally be performed using the configuration of other computer equipment, if desired, but the computing equipment to perform these functions is Sometimes referred to as a "server" or "servers".
The sender can send the message through system 10 to a given recipient using any suitable messaging format. For example, sending an email message, instant message (eg AOL instant message, Yahoo instant message, MSN messenger instant message, and ICQ instant message, IBM / Lotus Sametime instant message), or other email message. Can be done.
During the operation of System 10, a particular entity, such as Cryptanalysis Server 24, may download new client software (including, for example, a cryptanalysis algorithm) for a given party to obtain a key. You may need to make sure that you have permission to access the content of a particular message or to perform other functions. In general, the entity performing the authentication and authorization process in question can use any suitable manual or automated method. For example, a party may be required to fax or email a letter to an authenticating entity with respect to its official letterhead, where personnel or automated equipment will check the authenticity. As another example, biometric authentication techniques (eg, fingerprint analysis, eye scanning, handprint or voiceprint analysis, facial recognition, or face-to-face identification) can be used. Hardware-based mechanisms (eg, those based on hardware tokens) may be used to establish identity. The user may provide a credit certificate in the form of a predetermined username and password. A certificate authority can create a digital certificate to help verify the identity of a particular party. Digital signatures (for example, signatures from certificate authorities, or signatures from other entities that use private keys, and other entities that can be verified using public keys) are specific to the message or other signed information. It can be used to confirm that it is related to the party. The authentication process in System 10 may involve the generation of a ticket, such as a Kerberos ticket or other proof of authorization. The user authentication operation is derived from or based on the recipient's credential information, the underlying username and password, or any other recipient's credential information entered by the user herein. Distinguish information like information
Credentials and other information may need to be securely communicated between parties (eg, between the decryption server 24 and the user). It is possible to use a number of different methods to securely convey information in System 10. For example, information can be securely communicated through a secure communication path, such as a communication path that uses a secure socket layer (SSL) protocol or other suitable secure protocol (eg, TLS). The communication path is trusted because it is under the control of a trusted party (eg, because the communication path is entirely within Organization 18 and is under the control of a physically trusted party). Information can be transmitted securely by encrypting the information (eg, in a message) before transmitting it through an insecure (or secure) link.
To facilitate the interface with existing cryptographic mechanisms, or for other suitable reasons, use the first key to encrypt the content of the message, and to encrypt the first key. It may be desirable to use a "two-step" encryption technique that uses two keys. During decryption, the second key is used to decrypt the encrypted version of the first key, which can then be used to unlock the contents of the message. These two-step processes (and similar higher-order multi-step processes) can be more efficient than "pure" or "single-step" cryptographic algorithms and can be used as needed. For clarity, the present invention will be described in the context of a single step algorithm.
Public-key cryptography is often used in secure messaging systems. Public key cryptography allows a sender to use the recipient's public key to encrypt a message to the recipient. The recipient uses the matching private key for decryption. Public-key cryptography is generally satisfactory, but can be unnecessarily unwieldy in an environment where there is already a relationship between the sender and the receiver.
Consider an exemplary scenario where organization 18 is a bank. Banks have a set of existing customers who are required to securely deliver electronic deposit statements. Banks and customers already have a trusting relationship with each other. For example, a bank has an account name and number already assigned to its customer. When customers open their accounts, banks collect information such as social security number information, phone numbers, relatives' names, dates of birth, place of birth, and email addresses. This information can be used by banks to verify their customers' identities. Bank customers can also have a personal identification number (PIN) for withdrawing cash from automated teller machines, as well as a username and password for authentication before performing online banking tasks.
In this type of environment, banks and their customers are not strangers. Therefore, banks and their customers need not rely solely on cryptography, such as public key cryptography, designed to treat senders and recipients as strangers to each other.
The present invention can take advantage of pre-existing relationships between banks and their customers. Efficient symmetric key encryption can be used instead of public key encryption. Pre-existing relationships between banks and their customers can also be used to facilitate operations such as authentication and key distribution.
In the following description, the organization 18 may be a company or company, or other suitable type of business entity. Users of an organization may be employees, volunteers, contractors, or other preferred types of members of the organization (or their equipment). Users within an organization are distinguished from users outside the organization by access to intranet 16 and devices networked with each other within the organization using intranet 16 such as gateway 22.
Some of the users outside the organization may be independent third parties unrelated to the organization.
Other users outside the organization may be customers of the organization. For example, as mentioned above, the bank account holder is a customer of the bank. A customer is a client, contractor, temporary employee who does not have the same access rights as an employee working in the organization, or a customer who is associated with the organization as a customer but is not part of the organization itself. It may be a suitable user.
When a user is associated with a given organization as a customer, the relationship between the user and that organization can be utilized to support the secure communication technology of the present invention. In a common scenario, the bank 18 automated deposit statement distribution server sends an encrypted deposit statement message to a recipient who is a customer, such as recipient C. Sender A sends each message via gateway 22. Gateway 22 uses an encryption engine 28 to encrypt each message using a symmetric key. The symmetric key is derived from the master key 26 by the key generator 20 and is therefore referred to as the "derived key". Since many different keys can be derived in this way, the derived key can be uniquely generated for each recipient. By using a deterministic key derivation mechanism, the derived key does not need to be stored by the key generator, since the key of any user can be redistributed from the user ID as needed.
After the gateway encrypts the message to recipient C using the derived symmetric key of recipient C, the gateway can relay the encrypted message to recipient C. The encrypted message can be delivered to recipient C through the communication network 14. Upon receiving the encrypted message, recipient C can obtain a copy of the derived key from organization A so that the decryption engine 34 can be used to decrypt the content of the message.
Recipient C can obtain the derived key of Recipient C by sending the key request to the decryption server 24. Since Recipient C is a customer of the bank, Authentication Service 30 can use pre-existing Recipient Credit Certificates such as Recipient C's account name and PIN to authenticate Recipient C. .. When the authentication service 30 confirms the identity of the recipient C and determines that the recipient C is authorized to obtain a copy of the derived key, the derived key to the recipient C is the recipient using the key derivation service 32. It can be delivered to C.
Figure 2 shows the exemplary steps involved in setting up system 10 and responding to a derivation key request.
The configuration operation is performed in step 36. During setup, the key generator 20 can generate the master key 26. The master key 26 can be generated, for example, from a random string with sufficient entropy (ie, as many entropies as the size of the master key). The random string can contain any suitable symbol. In general, there is equivalence between numbers, letters, and other symbols and other schemes in question for representing information. Techniques that involve the conversion of letters or symbols to numbers, or techniques for representing multiple numbers or strings as a single number or other such operation, due to the unique equivalence between these different representative schemes. Will not be detailed in the specification of the present application. Key generator, as the master secret no failure occurs, like be performed on a secure server arbitrariness.
After a configuration operation such as the generation of the master key 26 has been performed, the key generator 20 can respond to the request for the derived key from another device in the organization 18. The derived key is a key derived from the master key 26 for a specific purpose (eg, to accommodate a specific recipient). Failure of one or more derived keys does not compromise the security of other operations that depend on other derived keys. Moreover, the master key cannot be conveniently derived from any set of derived keys and protects the master key.
The process of responding to the derived key request involves steps 38, 40, and 42. These steps are typically performed at a different time than the setup operation in step 36, as indicated by the dashed line 37. Organization 18 entities capable of generating derived key requests can include gateway 22, decryption server 24, and user 12. A user who requests a derived key directly from the key generator 20 uses the encryption engine in the client software to perform encryption instead of using an encryption engine on the gateway such as the encryption engine 28. It is possible. Therefore, using a gateway such as Gateway 22 is optional and dictated by the organization's policies. In a system with a gateway, the gateway can request a derivation key for use with the crypto engine 28. The decryption server 24 can request the key on behalf of a user outside the organization. The key request can be provided to the key generator 20 through the intranet 16.
At step 38, key generator 20 receives a request from a trusted entity within the organization, such as gateway 22, decryption server 24, or a user within the organization such as sender A. Derivation key requests are preferably approved only by these trusted entities. Since the derived key is unique to a particular user (eg, a customer), the derived key request preferably includes a user identifier (user ID). For example, if a derived key is required to encrypt a message to a recipient, the request for that key must include information about the recipient's identity (ie, the recipient ID).
At step 40, the key generator 20 calculates the requested derived key. The requested derivation key is unique to the recipient ID provided in the request. If desired, the derived key may be otherwise unique or may not include the recipient's identity information. For example, a derived key can be unique for a particular date or date range for added security. Each message will greatly increase the burden on the key generator, but requires the derived key to have its own associated derived key so that it is unique to both the recipient and the message. can do. The derivation key can be generated based on the information of the e-mail address (a kind of user ID) or the domain name. For clarity, the current description focuses primarily on the mechanism by which the derived key is derived from the master key based on the user ID. However, this is just an example. When deriving the derived key, the key generator 20 can use any suitable input.
The key generator 20 can use any suitable one-way function to generate the derived key from the master key and the recipient ID. As an example, the key generator 20 can use a hash function, such as the hash function in Equation 1, to calculate the derived key for recipient A (dkeyA). dkeyA = HMAC (master-key: recipient_ID) (1) In Equation 1, the master-key is the master key 26 and the recipient_ID is information about the recipient's identity. The value dKeyA is the derived symmetric key. The function HMAC is a well-known keyed hash message authentication code function. In equations 1 and other symbols used herein, the function argument before the colon is the key information used by the cryptographic function (here, the HMAC function). The argument after the colon represents the non-key information (in this case, the recipient ID).
Using the function of Equation 1, the key generator 20 can calculate the keyed hash value of the recipient's identity. However, the key derivation function in Equation 1 is just an example. Use any suitable one-way function that can act on the master key and recipient ID to keep the master key confidential while making the derived key unique to the recipient ID. Is possible. Suitable one-way functions are deterministic so that the sender and receiver copies of the derived key match, without requiring the key generator to store any information specific to each derived key. .. Also, a suitable one-way function will be collision-resistant so that the request to user X (as an example) does not accidentally or hostilely generate a derived key to user Y. Suitable one-way functions include hash functions, keyed hash functions, digital signature functions and the like.
After generating the derived key in response to the request for the derived key, in step 42, the key generator 20 can provide the derived key to the requesting source. The key generator 40 can transmit the derived key to the gateway 22, the sender in the organization 18, or the decryption server 24, for example, through the organization's intranet 16. Intranet 16 can be considered safe because it is controlled by organization 18.
The derivation key can be stored locally by the gateway 22, the sender within the organization 18, or the decryption server 24 (eg, until the time stamped derivation key expires). By storing the derived key in the local cache in this way, the number of requests for the derived key processed by the key generator 20 can be reduced. When using local storage, the source of the derived key can identify the local storage for copying the derived key when the key is needed. If the current version of the derived key is available in local storage, there is no need to make a key request to key generator 20.
Figure 3 shows an exemplary step involved in encrypting a message and sending it from within Organization 18 to an external recipient who is a customer of Organization 18.
In step 44, the sender of Organization 18 such as Sender A creates a message that is securely sent to a recipient such as Recipient C who is a customer of Organization 18. The sender's client software may create the message content, or the message content may be retrieved by sender A from another suitable source.
At step 46, sender A sends a message to the recipient. As an example, sender A's email client can send an email message addressed to a recipient through intranet 16. Intranet 16 is considered secure, so it is generally not necessary to encrypt the message at this point.
At step 48, the gateway 22 can receive the outgoing message from the sender. The gateway can have message management software or other suitable software used to execute policies such as encryption policies, virus scanning policies, archiving policies, and so on. 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 process each message. For example, the gateway can examine the domain name portion of each recipient's email address to determine if a particular message needs to be encrypted.
Any suitable cryptographic policy can be implemented using the gateway 22. For example, gateway 22 encrypts all outgoing messages, messages sent to a particular recipient or list recipient (ie, a particular customer), and its email address is predetermined. It is possible to encrypt a message containing a domain name, encrypt a message to a recipient based on the state of the message or the date associated with the organization, and so on.
If the gateway 22 determines that the message needs to be encrypted, the gateway 22 can obtain a suitable derivation key for the decryption process from the key generator 20. The gateway 22 may use a locally stored version of the derived key if the appropriate derived key is available locally. If the appropriate derived key is not available locally, the gateway generates a derived key request in step 50 and provides the derived key request to the key generator 20 through the intranet 16. The derived key request includes the recipient's identity. Any suitable format can be used to provide the key generator with the recipient's identity information in the request for the derived key. For example, the recipient's identity information can be provided in the form of a recipient ID (eg, information based on recipient C's email address or recipient C's email address).
At step 52, the key generator 20 receives and processes the request for the derived key. The derived key can be generated using the process of steps 38, 40, and 42 in Figure 2. After generating the derivation key, the derivation key can be provided to the gateway 22 through the intranet 16.
At step 54, gateway 22 receives the derived key from key generator 20. The gateway can then use the encryption engine 28 to encrypt the message content to generate the ciphertext. The encryption engine 28 can be a symmetric key encryption engine that uses a symmetric key encryption algorithm such as AES, or can use other suitable encryption algorithms. The input to the encryption engine 28 includes the recipient and the derivation key of the unencrypted message content. The output of the encryption engine 28 contains the encrypted version of the message (ciphertext) it contains.
At step 56, gateway 22 can relay the encrypted version of the message to recipient C. Encrypted messages may go through one or more mail servers (including internal and external mail servers in Organization 18) before Recipient C receives them.
Figure 4 shows an exemplary step involved in receiving and decrypting an encrypted message.
At step 58, the recipient (receiver C in this example) receives the message through the communication network 14. The message can be received by the recipient's client software running on the recipient's device 12.
If the recipient's client software has a copy of the appropriate derivation key available in the local cache, the client software can use that derivation key to decrypt the message. If the derived key is not available locally, the recipient can obtain a copy of the derived key from Organization 18.
In particular, in step 60, the recipient can generate a derivation key request and provide the decryption server 24 with the derivation key request. Any suitable mechanism can be used to create the derivation key request. For example, the sender A or gateway 22 client can automatically include a clickable link (eg, a web link) in the outgoing message. When recipient C receives the message, the instructions in the message can prompt recipient C to click on the link. By clicking the link, Recipient C's web browser or other suitable client software can be instructed to send certain information to a particular web address through the communications network 14. The information transmitted can include the identity information of the recipient and can serve as a request for the derived key. The web address can be associated with the decryption server 24. This is one exemplary method in which a derivation key request can be provided to the decryption server 24. If desired, any suitable mechanism can be used.
At step 62, the decryption server 24 can process the derived key request by authenticating the recipient and establish a secure communication channel between the server 24 and the device of recipient C. If desired, any suitable authentication technique can be used. For example, the recipient's client can provide the recipient's credit certificate to the decryption server in the form of username and password information. The user name and password information can be, for example, bank account name information and PIN information if the organization 18 is a bank. During the authentication process, the decryption server uses the authentication service 30 to verify the recipient credit certificate. If the recipient credential matches the credential information held by the organization (and matches the recipient ID in the derivation key request), the decryption server 24 receives the request for the derivation key. Can determine that a person is authorized to obtain a copy of the recipient's derived key. During the authentication process, server 24 and device 12 on recipient C establish a secure communication channel (eg, an SSL link). This secure communication channel can be used to deliver the derived key.
In step 64, after the decryption server 24 determines that the requesting recipient (receiver C in this example) is authorized to obtain a copy of the derived key, the decryption server 24 requests the derived key. Can be obtained from the key generator 20. The key request created by the decryption server 24 can be created through the intranet 16 and include the recipient ID. Since the decryption server 24 is the same organization as the key generator 20, the key generator 20 trusts the decryption server. Accordingly, the key generator 20 may use the recipient ID information from the decryption server and the derivation key generation process in steps 38, 40, and 42 (Figure 2) to generate the derivation key. It is possible. The derived key can be provided to the decryption server through the intranet 16.
In step 64, after the decryption server 24 obtains the derived key for recipient C from the key generator 20, in step 66, the decryption server 24 provides the derived key to recipient C through the communication network 14. be able to. The decryption server 24 can securely provide the derived key to recipient C using the secure communication channel established in step 62 (eg, through an SSL link).
At step 68, receiver C receives the derived symmetric key from the decryption server 24 through a secure communication channel. The recipient can then use the cryptanalysis engine 34 to decrypt the encrypted message (ie, decrypt the ciphertext). The inputs to the cryptanalysis engine 34 are the encrypted version of the message (ie, the ciphertext) and the derivation key of recipient C. The output of the decryption engine 34 is the message content of the unencrypted version.
The cryptanalysis engine 24 uses the same type of cryptographic algorithm used by the cryptanalysis engine 28, such as the symmetric key cryptanalysis algorithm using AES. For this type of symmetric key mechanism, the derivation key that the recipient uses to decrypt the message is the derivation that the sender used to encrypt the message (using the encryption engine 28 at gateway 22). It's the same as the key. The cryptanalysis engine 34 can be part of a stand-alone software package or incorporated into existing client software (eg, as a plug-in to an email client).
If desired, the recipient can request Organization 18 to decrypt the encrypted message instead of requesting a copy of the derived key. With this type of mechanism, the cryptanalysis server can include a cryptanalysis engine such as the cryptanalysis engine 34. The recipient can request the decryption server 24 for decryption instead of requesting the decryption server 24 for the derived key. The decryption request can include the recipient's ID. The encrypted version of the message can be provided to the decryption server 24 with the decryption request or by using other suitable mechanisms. Following successful authentication of the recipient, the decryption server 24 can use a local decryption engine to obtain the derived key from the key generator 20 and decrypt the contents of the message. The content of the decrypted message can be provided to the recipient through a secure link, such as an SSL link, during the authentication process.
In large organizations, it may be useful to use a hierarchical mechanism to limit the extent to which the various components of the organization must trust each other. For example, an organization can have a North American unit and a European unit. Employees of a North American unit can be associated with one key generator within that organization. Employees of a European unit can be associated with another key generator within that organization. This type of mechanism enhances security by allowing parallel and independent security mechanisms to be maintained within the same organization. For example, even if the master key of one key generator fails, the communication protected by the other key generator remains secure.
Hierarchical security mechanisms can also facilitate the introduction of intranet 16 into an organization. For example, in one place all entities connected to a local Ethernet® can trust each other, and in another location all entities connected to a local Ethernet® You can trust each other. Each Ethernet® network can form a local intranet to its associated location, but each local intranet (as an example) is provided with its own delegated key generator. So you don't have to network the two locations with the same level of reliability and security.
The derivation key mechanism described with respect to FIG. 2 can be used to derive the master key for each delegation key generator. Supermaster keys can be used to derive these master keys. Since each of the derived master keys is associated with a smaller part of the organization, they are sometimes referred to as submaster keys. A delegation key generator is an independent business unit within an organization or other distinct unit (eg, a unit divided by geographical area, management level or other state, organizational lineage, employee duties, etc.). Can be placed under the control of.
If each organizational unit has its own delegation key generator, that delegation key generator can be used to generate a derived key for the associated customer. For example, in an organization, a North American unit can use the North American unit's key generator to derive a key for a North American unit's customers. The key generator of the European unit can be used to derive the key for the customer of the European unit. Customers in this type of scenario are not necessarily exclusive, but will be quite different (ie, customers can be customers of both North American and European units, in which case. Customers use their respective derivation keys to communicate with each unit).
In a hierarchical key generator architecture, the super key generator has a super master key (sometimes called a master key), and each delegated key generator has a derived master key (master key or submaster). Sometimes called a key). By using a single supermaster key, a single gateway, such as gateway 22, can be used to encrypt all transmissions.
Figure 5 shows a diagram of an exemplary system 10 using a hierarchical architecture for the key generator. The super key generator 70 has a master key 72. The super key generator 70 is operated by Organization 18 (Figure 1) and can be used to derive submaster keys for various units of the organization. Figure 5 shows two organizational units (Unit E and Unit F). In general, a tissue can have any suitable number of units.
By one suitable mechanism, the units of the organization are interconnected with the super key generator 70 via the communication network 14, which may be an intranet or other suitable network. This kind of mechanism allows the super key generator 70 to electronically distribute the derived master key to the unit. If desired, the derived master key can also be delivered manually (eg, on disk or other medium).
The organization controls the super key generator 70 to verify the confidentiality of the super master key 72. Each unit has its own delegation key generator, and each has its own submaster key derived from the supermaster key. In the example of FIG. 5, unit E has a delegation key generator 20E. The delegation key generator 20E uses the submaster key 26E to generate a derived key for the sender and customer of unit E. The submaster key 26E was derived from the supermaster key 72 by the superkey generator 72 during the system configuration operation. Unit F has a delegation key generator 20F. The delegation key generator 20F uses the submaster key 26F to generate the derived key. The submaster key 26F is derived from the supermaster key 72.
The hierarchical key generator mechanism can have any suitable number of layers. For example, an additional sublayer of the key generator can be provided to the subunits of unit E, each having an additional layer of the derived master key. For clarity, the present invention describes a two-layer mechanism in which a single superkey generator in an organization generates derived submaster keys for various units within the organization.
The hierarchical key generator architecture can be used in various system configurations. For example, system 10 can have a central gateway (such as gateway 22 in FIG. 1). The central gateway can act as an information center for all outgoing messages and can have an encryption engine (such as the encryption engine 28 in FIG. 1) for encrypting the messages. The encryption engine in the central gateway can use the derived keys of various recipients to encrypt the message. The derived key can be provided to the central gateway by the delegation key generator.
The exemplary mechanism shown in Figure 5 does not use a gateway. Rather, each sender uses client software with an encryption engine to encrypt outgoing messages.
In a standard scenario, a user within a particular unit of an organization requires the customer of that unit to send an encrypted message. For example, the sender X of unit E requests the sending of an encrypted message to the recipient Y, who is a customer of unit E. The sender X obtains a derived key for encrypting the message of the receiver Y from the delegation key generator 20E. The encrypted message is sent to recipient Y through the communication network 14. Recipient Y generates a request for a derived key. The derivation key request is processed by the organization, and the requested derivation key is provided to recipient Y to decrypt the message.
One or more cryptanalysis servers can be used within System 10 based on the hierarchical key generator architecture.
In one preferred mechanism, the central cryptanalysis server is used to process the derived key request from the recipient. Each recipient's derived key request contains information that identifies the recipient. Each recipient's derivation key request also contains information that identifies which unit's key generator was used to generate the derivation key that the sender used to encrypt the message. You can also. The central decryption server can process this information to determine which delegation key generator created the derived key. The central decryption server can then send the key request to the delegation key generator in the appropriate unit of the organization.
If necessary, a decryption server can be provided to each unit. This type of mechanism is shown in Figure 5. The decryption server 24E in unit E is used to obtain the derived key from the delegation key generator 20E. The derived key from the delegation key generator 20E is provided to the customer of unit E to decrypt the message from the sender in unit E. The decryption server 24F in unit F is used to obtain the derived key from the delegation key generator 20F. The derived key from the delegation key generator 20F is used by the customer of unit F to decrypt the message from the sender of unit F.
Figure 6 shows the exemplary steps involved in using a system with a hierarchical key generator mechanism, such as system 10 in Figure 5, to support secure messaging between the sender and the receiver. Shown.
In step 74, the setting operation is performed. Organizations to which Unit E and Unit F are part use the Super Key Generator 70 to generate derived master keys for various delegation key generators. The super key generator 70 can use Equation 2a to derive the submaster key 26E from the supermaster key 72. sub-master_key_E = HMAC (super_master_key: unitE) (2a) In Equation 2a, sub-master_key_E is the value of submaster key 26E in FIG. super_master_key is the value of the supermaster key 72 held by the superkey generator 70. unitE is the name of the key generator 20E. As described with respect to FIG. 2, any suitable one-way key derivation function can be used to generate a derivation master key for a delegation key generator such as the key generator 20E. The example in Equation 2a uses the HMAC function.
The process of deriving the submaster key is repeated for all units in the organization. For example, the super key generator 70 can use Equation 2b to derive the submaster key 26F of FIG. 5 from the supermaster key 72. sub-master_key_F = HMAC (super_master_key: unitF) (2b) The master keys sub-master_key_E and sub-master_key_F can be delivered securely and can be stored locally by the delegated key generators 20E and 20F, respectively, as shown in Figure 5. The super key generator 70 can be networked with the delegated key generators 26E and 26F via a secure intranet. This allows the key to be delivered through a trusted route within the organization or securely over another suitable communication network 14.
After configuring the delegation key generator by deriving the submaster key of the delegation key generator using Equations 2a and 2b, or any other suitable key derivation function, the message is in steps 76, 78, 80. , 82, 84, and 86 can be sent securely. Steps 76, 78, 80, 82, 84, and 86 can be performed at different times than the configuration operation in step 74, as indicated by the dashed line 75.
At step 76, a sender, such as sender X, in unit E obtains a derivation key for a desired recipient, such as receiver Y, who is a customer of unit E. The sender's client software can obtain the appropriate derivation key 20E to use for message encryption by requesting the derivation key from the delegation key generator through the intranet 16 in unit E. The key request made by the sender contains information about the recipient to whom the message is intended.
In this example, the target recipient is recipient Y, so the key request can include information that identifies recipient Y, such as the recipient ID for recipient Y (eg, recipient_Y_ID). The delegation key generator can then calculate the locally derived key using Equation 3 or using other suitable key derivation functions as described with respect to FIG. key_Y = HMAC (sub-master_key_E: recipient_Y_ID) (3) In Equation 3, sub-master_key_E is used by the delegation key generator 20E in generating derived keys for users of unit E and their associated customers. recipient_Y_ID is information that identifies the recipient who is the target of the message. Key_Y is a derived key. After calculating the Key_Y, the delegation key generator 20E provides the key_Y to the requesting sender. The client software at the requesting sender includes an encryption engine, such as the encryption engine 28 in Figure 1, which uses Key_Y to encrypt the message to the recipient. The client software then sends an encrypted message to the recipient.
The encrypted message contains the encrypted content of the message (ciphertext) and is suitable for the recipient to communicate when the recipient requests a copy of the derived key (Key_Y) to decrypt the message. Contains unencrypted information that identifies the unit (ie, in this example, unit E, which includes the delegation key generator 20E and the decryption server 24E). Any suitable mechanism can be used to provide a message for the information that identifies the delegation key generator and its units. For example, the client software at Sender X automatically embeds the weblink in the outgoing message containing the recipient_Y_ID and also automatically embeds a unique name for the delegation key generator 20E and / or the decryption server 24E. The web link can also include web address information (eg, domain name) associated with the decryption server 24E that the recipient can use to communicate with the decryption server 24E by requesting a key. The recipient can click this web link to initiate a key request to the decryption server 24E using the recipient's web browser.
In step 78, after the receiver Y receives the encrypted message from the sender X over the network 14, the receiver Y generates a derivation key request and provides this request to the decryption server 24E. The key request contains information that identifies the recipient (eg, recipient_Y_ID). The key request can also include information that helps the decryption server send the derived key request to the appropriate delegation master key server. For example, the key request can include the name of the appropriate delegation master key server that was sent with the message to the recipient.
In an environment with a central decryption server, information about the name of the appropriate delegation key generator can be used to determine which delegation key generator will communicate with the requested copy of the derived key. It is possible. In the type of mechanism shown in Figure 5, where there is a one-to-one correspondence between the delegation key generator and the decryption server, the recipient sends the derived key to a specific one of the decryption servers. It is possible to use the information in the embedded web link. This serves to implicitly define the delegation key generator associated with the request.
In step 80, the decryption server 20E authenticates the recipient Y and establishes a secure channel (eg, SSL link) between the decryption server 20E and the recipient Y. Upon confirmation of recipient Y's approval to obtain a copy of Key_Y, the decryption server 20E uses the information in the request to identify the delegation key generator 20E to generate a key request for key_Y. It is possible. The key request includes recipient_Y_ID so that the delegated key generator 20E can use Equation 3 to generate Key_Y.
At step 82, the delegation key generator 20E receives the key request from the decryption server 24E. Since the delegation key generator 20E and the decryption server 24E operate in the same unit through the same intranet 16, the decryption server 24E is trusted by the delegation key generator 20E. Therefore, the delegation key generator 20E generates a derived key for the recipient Y. In particular, the delegation key generator 20E can use the information from the request for the recipient's identity (recipient_Y_ID) and the submaster key 26E of Equation 3 to derive the Key_Y. The delegation key generator 20E can then securely provide Key_Y to the decryption server 24E through the intranet 16 in unit E.
At step 84, the decryption server provides Key_Y to recipient Y through a secure communication channel between the decryption server 24E and recipient Y.
At step 86, recipient Y uses a cryptanalysis engine 34 and Key_Y, such as the cryptanalysis engine of Figure 1, to decrypt the ciphertext and access the unencrypted version of the message content.
If desired, each unit may have a gateway for encrypting outgoing messages from senders within that unit. The delegation key generator in each unit can generate the derivation key required for encryption.
In mechanisms where a global gateway is used to encrypt outgoing messages from senders in multiple units, the superkey generator 70 may use equations 4a and 4b to generate a derived key. it can. Unit_j_key = HMAC (super_master_key: unit_j) (4a) key<sub>j, k</sub>= HMAC (Unit_j_key: recipient_k_ID) (4b) Expressions 4a and 4b use the superkey generator to generate the submaster key Unit_j_key, which in turn is the recipient of the message (recipient k in this example) and the appropriate unit and Derived key Key that is unique to both the key generator (unit j and key generator j in this example)<sub>j, k</sub>Is combined with the recipient identity (recipient_k_ID) for recipient k to generate.
If desired, a hierarchical mechanism can be used for subdivided recipient identities. For example, there may be multiple sub-identities such as recipient_k_ID_1, recipient_k_ID_2, etc., whose ID is recipient_k_ID and are associated with recipient k who is a customer of the organization that has the master key of master_key. The derivation key for each sub-recipient of recipient_k_ID can be calculated using formulas such as formulas 5, 6a, and 6b. Key_k = HMAC (master_key: recipient_k_ID) (5) Key_k_1 = HMAC (Key_k: recipient_k_ID_1) (6a) Key_k_2 = HMAC (Key_k: recipient_k_ID_2) (6b) Equation 5 can be used to calculate the derived key Key_k from the master key and the identity of the recipient k. Equation 6a can be used to calculate the derived key for the recipient's sub-identity recipient_k_ID_1 based on the key for recipient k and the identity of recipient_k_ID_1. Equation 6b can be used to calculate the derived key for the recipient's sub-identity recipient_k_ID_2. Derivation keys for other recipient sub-identities associated with recipient_k_ID can be calculated in the same way. The HMAC function is used to derive the keys of equations 5, 6a, and 6b. As described with respect to FIG. 2, other suitable key derivation functions can be used as needed.
The organization only needs to be aware of the recipient's identity recipient_k_ID. However, outside the organization, the derived key for each sub-recipient can be calculated using the derived key for recipient_k_ID (ie Key_k). This allows Key_k to be used as a master key for a group of users managed by recipient k outside the organization.
The receiver hierarchy can have a suitable number of layers. The examples of equations 5, 6a, and 6b involve a two-layer scheme. In addition, the system 10 can have a hierarchy of recipients and a hierarchy of key generators, if desired.
Another aspect of the invention relates to an authenticated derived key. In particular, it may be desirable to be able to authenticate the derived key in an environment without a gateway. In a system without a gateway, the sender must obtain a derivation key before the outgoing message can be encrypted. Problems can arise if the sender obtains an incorrect derived key due to an accidental or malicious transmission error, or if an attacker impersonating a key generator provides the sender with a fake key. There is sex. The authenticated derived key can be used to guarantee the sender and receiver who have properly obtained the requested key.
One preferred technique that can be used to authenticate keys is to use digital signatures. In this situation, the HMAC-based version of Equation 1 becomes Equation 1'. dkeyA = sign (private-key: recipient_ID) (1') In Equation 1', the keyed hash function of Equation 1 is replaced by the deterministic digital signature function "sign". Furthermore, the master key in Equation 1 has been replaced with a private key (private key). Equation 1'acts as the same derived key derivation function as Equation 1 in System 10, which allows entities to authenticate the derived keys they obtain.
The public key (called the public key) that corresponds to the private key becomes publicly accessible. The public key can be issued, for example, by placing the public key on a suitable server inside or outside the organization that has access to the public key and / or organization 18 through the communication network 14. The public key can also be made accessible only to entities within the organization (for example, by placing the public key on an internal server connected to intranet 16).
In systems that use this key authentication process, the derived key (dkeyA) can be verified using the authentication operation in Equation 7. valid = verify (public-key: recipient_ID, dKeyA) (7) In Equation 7, the function "verify" is used to calculate the parameter valid based on the public key and the values of recipient_ID and dKeyA. If dKeyA is not a valid derived key, the parameter valid will be incorrect and it will be found that the sender or other entity will not use that derived key. If the parameter valid is true, then the derived key is valid. Due to the non-counterfeiting of digital signature functions such as sign, derivation key calculations are not feasible without knowledge of the private key. The function "sign" is deterministic (or derandomized appropriately to act deterministically) and the same derivation key if both the sender and the receiver use Equation 1'. To calculate.
The system described above allows a sender within an organization to send an encrypted message to a recipient who is a customer of the organization. The recipient can communicate with the organization to obtain a copy of the appropriate derived symmetric key used to decrypt the encrypted message. The recipient (which acts as the sender) can also use the derived key to encrypt the message to the organization (for example, the recipient encrypts to the sender in the organization). You can reply to the response message you made).
A sender who is outside an organization and not a customer of that organization may want to send an encrypted message to a recipient within the organization or a recipient who is a customer of that organization. Since this sender does not belong to an organization, the sender has no pre-established relationship that allows the organization to authenticate the sender in the same way that it can authenticate its customers.
Figure 7 shows an exemplary system that can be used by a non-customer sender to send a secure message to an organization's recipients or recipients who are customers of that organization.
In system 10 of FIG. 7, the key generator 20 has a master key 26 used to generate a derived key. Sender P, who wants recipient Q, a customer of organization 18, to send an encrypted message, can use a key derived from key generator 20 to encrypt the message. The message can be encrypted on the sender's device 12 or by the gateway 22. When the recipient Q receives the encrypted message, the recipient Q can request a copy of the derived key from the decryption server 24. The decryption server 24 can authenticate the recipient Q and obtain a copy of the derived key from the key generator 20. The decryption server 24 can then provide the derived key to recipient Q through 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 to sender P (eg, a response message in response to sender P's original message). Since the sender P has (or can obtain) a copy of the derived key, the sender P can decrypt the encrypted response of the receiver Q.
Unlike Recipient Q, Sender S is not a customer of Organization 18. Organization 18 does not have a credit certificate to use to authenticate sender S because there is no pre-existing relationship between sender S and organization 18. Therefore, the sender S cannot authenticate to the decryption server 24 in order to obtain the derived key in the same way that the receiver Q can authenticate to the decryption server 24. Since sender S is not a member of organization 18, it is not desirable to delegate the derived key of recipient Q to sender S.
According to the present invention, the organization 18 is provided with a policy server 88. The policy server 88 is shown as an independent server in the example of FIG. 7, but if necessary, the policy server 88 is part of the gateway 22 and part of the decryption server 24, the key generator 20. It can be used as part of or as part of another entity belonging to Organization 18. The policy server handles the generation of derived keys for non-customer senders such as sender S. Sender S may obtain the non-customer message key if he is a customer of that organization or wishes to send a secure message to the sender of organization 18.
The exemplary recipient R of FIG. 7 is located within organization 18, but recipient R may also be a recipient, such as recipient Q, who is a customer of the organization.
Figure 8 shows an exemplary step that a non-customer sender S can take when encrypting a message and sending a secure message to a recipient, such as recipient R.
At step 90, sender S communicates with policy server 88 to request a key to send a message to recipient R. Sender S can use, for example, a web browser running on Sender S's device to access a web page associated with Policy Server 88.
At step 92, the sender's web browser authenticates the policy server. Standard web browsers have built-in capabilities for using public key infrastructure (PKI) technology to perform this type of authentication (for example, by checking the certificate associated with the policy server's web page). Have. During the process of authenticating the policy server, a secure communication channel (eg SSL link) is established between the policy server 88 and the sender S.
The key request from sender S contains information about the target recipient's identity (recipient_R_ID).
In step 94, the policy server 88 requests and obtains a derived symmetric key (Der_Key) for the sender S from the key generator 20. Policy server 88 also generates a random number N. The number N need not be truly random, but each of those numbers is preferably used only once for each recipient. For example, the technique requires a key generator, respectively, to hold a clock or counter, where N can be based on a timestamp or counter. The key request created by Policy Server 88 contains information about the recipient's identity (ie, the value of recipient_R_ID provided by sender S). The key generator 20 can use Equation 8 to calculate the derived key Der_Key. Der_Key = HMAC (master-key: recipient_R_ID) (8) In Equation 8, the master key is the master key of key generator 20, and recipient_R_ID is a unique identifier for recipient R. The HMAC function of Equation 8 (and other key derivation equations herein) is merely exemplary. Any suitable hash function or other one-way function can be used to derive the Der_Key, as described with respect to FIG.
In step 96, the policy server 88 uses the derived key Der_Key and the random number N to calculate the value of the non-customer message key Key-N. The policy server 88 can use any suitable key derivation function as described with respect to FIG. For example, Policy Server 88 can use Equation 9 to generate the non-customer message key Key-N. Key-N = HMAC (Der_Key: N) (9) In step 98, policy server 88 provides sender S with a non-customer symmetric message key Key-N through a secure channel.
In step 100, sender S uses the non-customer message key Key-N to encrypt the message to recipient R. Sender S can use the encryption engine on Sender S's device to encrypt the message in order to generate the ciphertext.
At step 102, sender S sends an encrypted message to recipient R in organization 18. The sender can send both the value of N as part of the ciphertext and encrypted message created in step 100, or can provide the ciphertext and N in the associated transmission. The value of N sent from sender S to recipient R is unencrypted.
Figure 9 shows an exemplary step involved in decoding the message from sender S.
At step 104, recipient R receives an encrypted message containing an unencrypted value N and a ciphertext.
At step 106, recipient R requests a copy of the derived key Der_Key from the policy server, or simply retrieves it from the recipient's local cache, if possible. The key request includes the recipient R's identity (recipient_R_ID) so that the key generator knows which key to generate. During step 106, the recipient authenticates to the policy server. During authentication, a secure communication channel (eg SSL link) is established between Recipient R and Policy Server 88.
If both Policy Server 88 and the recipient are in the organization, the process of authenticating the recipient can be implicit (for example, Policy Server 88 communicates key requests with the policy server through the organization's intranet. All you have to do is make sure it comes from a user in your organization). If desired, it is possible to use a larger authentication technique (eg, with the authentication of recipient R's credit certificate by the policy server). This type of authentication technique can be used, for example, when the recipient is a customer of organization 18, such as recipient Q, rather than a user of organization 18.
If desired, the policy server can also be authenticated by the recipient (eg, by using PKI techniques) to ensure that the recipient has obtained the request key from a trusted source. is there.
In step 108, the policy server uses the recipient ID (recipient_R_ID) information from the recipient's key request to request the derived key Der_Key from the key generator 20.
At step 110, the key generator 20 uses Equation 8 (or any other suitable function) to generate a Der_Key for the policy server.
At step 112, policy server 88 provides the recipient with the derived key Der_Key through a secure channel.
At step 114, the recipient receives an N of N from the sender S to calculate the value of the non-customer message key Key-N (using, for example, Equation 9 or some other suitable one-way function). Use the value and the derived key (Der_Key) from the policy server 88. (The formula that the Policy Server uses to calculate the Key-N for the sender must match the formula that the recipient uses to calculate the Key-N).
At step 116, the recipient uses the non-customer message key Key-N to decrypt the ciphertext and access the content of the message.
The above description merely illustrates the principles of the present invention, and one of ordinary skill in the art can make various modifications without departing from the scope and spirit of the present invention.
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP08204702A | Cites | Japan |
| JP2001344537A | Cites | Japan |
| JP2002185443A | Cites | Japan |
10 members in 4 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 10887721 | United States of America | – | |
| 88772104 | United States of America | A | |
| 88772104 | United States of America | A | |
| 2004887721 | – | – | – |
| US20040887721 | – | – | – |
Members10
| Document | Office | Kind | |
|---|---|---|---|
| US2006010324A1 | United States of America | A1 | |
| WO2006007601A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2006007601A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1782213A2 | European Patent Office (EPO) | A2 | |
| JP2008506317A | Japan | A | |
| EP1782213A4 | European Patent Office (EPO) | A4 | |
| US7624269B2 | United States of America | B2 | |
| JP2011239476A | Japan | A | |
| JP5265744B2This record | Japan | B2 | |
| EP1782213B1 | European Patent Office (EPO) | B1 |
25 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Notification of acceptance of power of attorneyJAPANESE INTERMEDIATE CODE: R3D02RD02 | RD02 | |
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Written request for registration of change of domicileJAPANESE INTERMEDIATE CODE: R313531S531 | S531 | |
| Written request for registration of change of nameJAPANESE INTERMEDIATE CODE: R313533S533 | S533 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written measure of declining of transfer procedureJAPANESE INTERMEDIATE CODE: R370R370 | R370 | |
| Written notification for declining of transfer of rightsJAPANESE INTERMEDIATE CODE: R360R360 | R360 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written request for registration of change of domicileJAPANESE INTERMEDIATE CODE: R313531S531 | S531 | |
| Written request for registration of change of nameJAPANESE INTERMEDIATE CODE: R313533S533 | S533 | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313111S111 | S111 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 5265744
- Publication, DOCDB
- 5265744
- Publication, EPODOC
- JP5265744B
- Application
- 179515
- Application, DOCDB
- 2011179515
- Application, EPODOC
- JP20110179515
Titles2
- Japanese
- 導出鍵を用いたセキュアメッセージングシステム
- English
- Secure messaging system with derived key
Classification
- CPC, 2
- H04L9/083
- H04L9/0866
- IPC, 3
- H04L9 08
- G06F21 00
- G06F21 33