CA2187035C - Computer network cryptographic key distribution system - Google Patents
Computer network cryptographic key distribution systemInfo
- Publication number
- CA2187035C CA2187035C CA002187035A CA2187035A CA2187035C CA 2187035 C CA2187035 C CA 2187035C CA 002187035 A CA002187035 A CA 002187035A CA 2187035 A CA2187035 A CA 2187035A CA 2187035 C CA2187035 C CA 2187035C
- Authority
- CA
- Canada
- Prior art keywords
- key
- decryptor
- access control
- release
- encryptor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
Abstract
Novel cryptographic key distribution techniques to be used in large computer networks are disclosed. The techniques require trusted key release agent systems in each security domain. The encryptor (10) of a data message nominates to set of authorized decryptors (30), using a set of access control attributes recognized by a key release agent (32) in a target security domain. Data enabling the message decryption key and the access control attributes to be recovered are sent to the decryptor in an access controlled decryption block, which is encrypted under a separate key. The access controlled decryption block can only be decrypted by a key release agent (32) in the correct security domain. The key release agent recovers the decryption key and supplies it to an authorized decryptor (30), which allows the decryptor to recover the original data message.
Description
COMPUTER NETWORK CRYPTOGRAPHIC KEY DISTRIBUTION SYSTEM
Technical Field The present invention relates generally to computer networks in which cryptograw is techniques are used for data confidentiality purposes. More specifically, the invention is directs ~' to a computer network in which decryption of data is only possibir when a decryptor is authorized in accordance with a set of access control attributes specified by the encryptor.
IO
Background Art Cryptographic techniques constitute a major building block used in implementing all security services in computer networks. The basic function provided by a cryptographic system (or cryptosystem) is encipherment/decipherment. A cryptosystem comprises a pair of data transformations, encryption and decryption, respectively. Encryption is applied to a data item, known as plaintext, and generates a new (unintelligible) data item, ciphertext. Decryption, applied to ciphertext, results in the regeneration of the original plaintext. An encryption transformation uses as input both the plaintext data and an independent data value known as an encryption key. Similarly, a decryption transformation uses a decryption key. There are two basic types of cryptosystems - symmetric systems and public key (or asymmetric) systems. In symmetric cryptosystems the same key is used in the encryption and decryption transformations. A public key system has a key pair comprising a public key and a private key. One of these keys is used for encryption and the other for decryption. The public key does not need to be kept confidential.
To provide confidentiality, a symmetric cryptosystem works as follows. Two parties, A and B, want to communicate securely. By some process (e.g., by a secure channel or a trusted courier), they both obtain knowledge of a data value to be used as a key. The key is kept secret from all parties other than A and B. This enables either A or B to protect a message sent to the other party by encrypting it using the shared key. The other party can decrypt the message, but outside parties cannot. A well known symmetric cryptosystem is the U.S. Data Encryption Standard (DES).
X1$70 3 5 2 In a public key cryptosystem there are two basic modes of operation, an encryption mode and an authentication mode. In the encryption mode, the data originator uses the public key for encryption and the recipient uses the private key of the same key pair for decryption. In this system, knowledge of the public key is not enough to deduce the private key. Therefore, the encryptor knows that data encrypted with a public key can only be decrypted by the holder of the corresponding private key. It is also possible to authenticate the encryptor in the authentication mode of operation. In this mode, the encryptor sends ciphertext encrypted by the private key of the key pair.
The decryptor (recipient) then knows that data encrypted with the private key can be decrypted by anyone but could only have been sent by the holder of the private key. A cryptosystem of this kind which can operate in both encryption and authentication modes is known as a reversible public key cryptosystem.
One well known reversible public key cryptosystem is the RSA
system described in U.S. Patent No. 4,405,829 issued on September 20, 1983 to Rivest et al. An RSA key pair is created as follows. An integer a is chosen, to be the public exponent. Two large prime numbers, p and q, are randomly selected, satisfying the conditions that (p-1) and a have no common divisors, and (q-1 ) and a have no common divisors. The public modulus is the value n=pq. The values of n and a together form the public key. A private exponent d is then determined, such that de-1 is divisible by both p-1 and q-1. The values of n and d (or p and q) together constitute the private key. The exponents have the important property that d functions as the inverse of e, that is, for any message M, (Me)d mod n =M. The encryption process for message M involves calculating Me mod n. This can be carried out by anyone who knows the public key, i.e., n and e. Decryption of message M' involves calculating M'd mod n. This requires knowledge of the private key.
Cryptographic techniques all depend upon cryptographic keys.
The keys must be made known in advance (distributed) to the parties that will use them and at the same time they must be protected as necessary against disclosure and/or substitution. Therefore key management, particularly key distribution, is very important. With purely symmetric systems, if the number of keys in a network is to be kept manageable, it is necessary to use trusted key centers for key T T ~ .. ~ .._.~"....__.,.e.~.,~...,..r.... ,~. ,. .. ....... .....
3 ~~8~039:
distribution. For any two systems to communicate securely, they must share a master keying relationship with a Fey center. Furthermore, that key center must be on-Iine at the time secure communications are to be established. Distribution of public keys is simpler and does not require trusted on-line servers. Distribution of a public key does not require confidentiality, but it does require integrity - the user of a public key must be assured that it is the correct public key for the remote party concerned. For this reason, a public key is usually distributed in the form of a certificate which is digitally signed by a trusted certification authority. Certificates can then be distributed by unsecured means, such as a public directory service. A user of a certificate can be assured the certificate contents have not been changed, by verifying the certification authority signature. Installation of a new private/public key pair is straightforward; keys are typically generated I5 within the owner system or a certification authority system. The only secure key transfer necessary is the transfer of one key from either the owner system to the certification authority system, or vice versa. These two systems are usually in the same network, and are typically close to one another.
In comparison with symmetric cryptosystems, public key systems have the advantage of simpler key distribution. However, countering this advantage, symmetric systems have the advantage of lower processing overheads. This makes symmetric systems particularly attractive for the bulk encryption/decryption of large volumes of data.
To benefit from all the advantages, a hybrid approach may be used. Symmetric cryptosystems are used for protecting bulk data and public key systems are used for distributing the symmetric keys (primary keys). For example, if a party A wants to establish a symmetric encryption key with party B, using RSA, it can do so as follows. Party A obtains a copy of party B's public key by obtaining the necessary certificate (possibly sent directly from Party B) and checking the certificate signature (or the signatures on a chain of certificates) to ensure the key is valid. Party A then generates a random symmetric key, and sends it to Party B, encrypted under Party B's public key. Only Party B can learn the symmetric key value, as only Party B knows the private key needed to decipher the message (the encrypted symmetric key value). Hence the two parties establish shared knowledge of the ?1 870 3 5 symmetric key, and can proceed to use it for protecting data communicated between them.
Another well known scheme of establishing a symmetric primary key is known as the Diffie-Hellman key derivation technique described in U.S. Patent No. 4,200,770 issued April 29, 1980 to Hellman et al. This works as follows. Parties A and B agree, in advance, upon a prime number p and a primitive element a in GF(p). Prime p should be such that p-I has a large prime factor. This agreement could be on the basis of published system-wide constants, or could result from previous communications. As the first step in deriving a key, party A
generates a random number x, 0<x<p-1. It then calculates ax mod p, and sends this value to party B. Party B generates a random number y, 0<y<p-1, calculates aY mod p, and sends this value to party A. Then party A calculates (aY)x mod p and party B calculates (ax)Y mod p. Both parties now know a common key, K=axY mod p.
In the traditional electronic mail encryption key distribution method, all message recipients have key pairs of a reversible public key cryptosystem (such as RSA). The message is encrypted using a symmetric cryptosystem, and copies of the encryption key, encrypted under the public key of each recipient, are attached to the message.
Each legitimate recipient can recover the encryption key by decrypting the applicable copy of it with his private key. This method has several shortcomings. Firstly, the only access control model it can support is a simple list of authorized decryptors; other models are often required, such as specifying group membership, role membership, or security clearance. Secondly, every recipient must hold sensitive information, namely the private key of a key pair; compromise of any recipient's private key results in the compromise of all encrypted messages ever sent to that recipient. Thirdly, the encrypting system must obtain and verify, for every authorized recipient, a public key certificate; this can be a lengthy process, given the need to process multiple certificate chains and revocation lists. Fourthly, every participating user is required to possess the encryption and decryption capabilities of a reversible public key cryptosystem. There may be a risk of such cryptographic capabilities being used for unintended encryption purposes.
EP 0503765, published September I6, 1992, describes an access contra in a distributed computer system in that a mechanism restricts and validates an access to a target application by a certain user in a distributed computer system. The user obtains an encrypted privilege attribute certificate (PAC) and a session key from an authentication and privilege server and by using this key it communicates with a key distribution server to obtain a basic key. Then it sends the basic key to a PAC validation facility which determines the identify of the user.
When the target application receives a request for access from the user who presents it with the encrypted PAC, it sends such PAC to the PAC
validation facility which decrypts the PAC and validates the PAC with the user identity.
A cryptographic protocol for secure communications described in EP0535863, published April 7, 1993, sets up a secure communication channel in which prior to information transmission, an asymmetric cryptosystem is used by two parties to agree on a symmetric crypto-graphic key. U.S. Patent 4,888,801, issued December I9, 1989, teaches a hierarchical key management system. The patent describes a key management system by which a secure communication channel can be set up among parties through the use of a SAD (security activation device) issued to each party by a KCA (key certification authority). The SAD is a physical key which is initially programmed by the KCA and subsequently reprogrammed by a secure terminal used by the user. The SAD is inserted into a receptacle of the terminal to enable secure communication and user authentication.
In LT.S. Patent 5,276,73, issued January 4, 1994, a sort of escrow mechanism for a public key cryptosystems is mentioned in which each user is assigned a pair of matching secret and public keys. Each user's secret key is broken into shares. Each user then provides a plurality of trustees pieces of information which enables each trustee to verify its share of the secret key. Thus all the trustees must agree to reveal to a third party the secret key of a user.
EP0343805, published November 29, 1989 describes techniques of reproducing secure keys by using distributed key generation data and a distributed encrypted prekey. Key generation data are divided into more than one part and each part is encrypted in a distributed fashion, AMENDED SHEET
first by a first key prekey to obtain a symmetric key by which information is scrambled before transmission.
The present invention addresses these problems and others which will become apparent in the following detailed description. The_ invention relates to a key distribution method which enables an encryptor of a data item to specify, in terms of any desired access control model, the set of authorized decryptors. The present invention makes use of trusted servers called key release agents. While type invention is not restricted to use within any particular application environment, it is most naturally applicable to environments where broad user populations inherently have access to encrypted information, e.g., file servers, bulletin boards, or groupware applications.
The present invention also provides for controlled release of decryption keys under special circumstances, such as authorized interception by law enforcement agencies. This can be achieved by building a special key release condition into the key release agent's decision process. When used for this purpose, the present invention overcomes deficiencies apparent in the key-escrow system described in the U.S. Government FIPS 185 Escrowed Encryption Standard which addresses the same requirements.
Ob,~ects of the Invention It is therefore an object of the present invention to provide a method and a system of securely distributing through a computer network an encryption key to decryptors who are authorized according to a set of access control attributes specified by the encryptor.
It is another object of the present invention to provide a method and a system of a decryptor recovering an encryption key from a key release agent in a secure manner.
It is yet a further object of the present invention to provide a method and a system of a key release agent recovering an encryption key from an encrypted access controlled decryption block which contains the access control attributes.
It is still a further object of the present invention to provide a method and a system of a key release agent releasing an encryption key to a party other than a decryptor that is explicitly authorized by the encryptor.
~Pr~ETIDED SHEET
Disclosure of Invention _Briefly stated, the present invention relates generally to a computer network which includes an encryptor, multiple decryptors and one or more key release agents. In one aspect, the invention is directed to a method of publicly distributing a message encryption key through the computer network. The method comprises a step of the encryptor generating an access controlled decryption block (ACD), which contains key data related to a message encryption key and a statement of access control criteria with respect to authorized decryptors, both being protected using a key release public key for which only the key release agent in a particular security domain has knowledge of the corresponding key release private key. The method further includes steps of the encryptor distributing the access controlled decryption block, a security domain identifier (Domain id), and an identifier (R key id) of the key release private key. In the method there are steps of the decryptor sending to the key release agent in a locally-protected transaction a key release request which includes the access controlled decryption block, the identifier of the key release private key, and decryptor attributes that include the decryptor's identity. There are yet further steps of the key release agent recovering the message encryption key and access control attributes using data in the access controlled decryption block and the key release private key and determining, on the basis of the decryptor attributes and the statement of access control criteria in the access controlled decryption block, if the decryptor is authorized to decrypt the message ciphertext and if the decryptor is so authorized, the key release agent sending the message encryption key to the decryptor in a locally-protected transaction.
According to another aspect, the invention is directed to a computer network in which a message encryption key is publicly distributed between an encryptor and a decrypfor by way of a key release agent. The network comprises the encryptor including a transmitting device for transmitting to the decryptor through the network a ciphertext, an access controlled decryption block (ACD), and an identifier associated with a key release public-private key pair, the access controlled decryption block including a set of access control attributes (ACA) and key data related to the message encryption key, the encryptor further including a message encryption device for 1;1~,11L~~~~:J ~ls'~~=
21 87~ 3 5 producing the ciphertext using the message encryption key and ACD
generation device for generating the access controlled decryption block using the key release public key. The network further includes the decryptor having a transaction device for sending the access controlled decryption block and the identifier together with a set of decryptor attributes to the key release agent in a locally-protected transaction.
The network yet further includes the key release agent having the key release private key and ACD processing device for recovering the message encryption key and access control attributes by using the key release private key, the key release agent further including a determining device for deciding, based on the recovered access control attributes and the decryptor attributes, whether the decryptor is authorized to decrypt the ciphertext and transmitting device for sending to the decryptor the message encryption key in a locally-protected transaction.
~IMENDED SHEET
21 ~~70~5 - , Brief Description of the Drawings Figures 1 and 2 are functional schematic diagrams of an encryptor, a decryptor and a key release agent according to a generic embodiment of the present invention;
Figures 3 and 4 are functional schematic diagrams of an encryptor, a decryptor and a key release agent according to another embodiment of the present invention which is based on a reversible public key cryptosystem;
Figures 5 and 6 are functional schematic diagrams of an encryptor, a decryptor and a key release agent according to another embodiment of the present invention which is based on the Diffie-Hellman Key Derivation technique; and Figures 7 and 8 are functional schematic diagrams of an encryptor, a decryptor and a key release agent according to yet another I5 embodiment of the present invention which is also based on the Diffie-Hellman Key Derivation technique.
Models) of Carrving'Out the Invention Figure 1 is a functional schematic diagram of the encryptor according to one embodiment of the present invention. In this embodiment, an encryptor IO determines access control criteria and generates ACA (access control attributes) to reflect such criteria. The encryptor 10 generates a local input I2 which is input, together with the ACA and a key release public key 14 to a function 16 which generates an E key (message encryption key) and a protected data construct called an ACD (access controlled decryption) block. A plaintext to be confidentiality-protected is encrypted at 18 to produce a ciphertext in a symmetric cryptosystem using the E key. An R key is a private key of a key-release key pair and is held by a trusted server system in the specified domain called a KRA (key release agent). Each KRA holds a copy of each R key used in its domain in a secure manner (e.g., in a hardware cryptomodule). Certified copies of the corresponding key-release public keys are made available to encryptors. The KRA will also be described in detail below. Thus when generating the ACD block, the AME~JDED SHEET
encryptor selects a key-release public key, which comes with an identifier- for the corresponding R key and verifies the signature on the applicable public key certificate. Stated more clearly, the key release private key (R key) and the key release public key (Pub key) form a key -release key pair which is a key pair of a public-key cryptosystem used in protecting an access controlled decryption block (ACD) against use or modification by any system other than a recognized key release agent (KRA). The key release public key is made available to encrypting systems (encryptors) and used by them in generating access controlled IO decryption blocks while the key release private key (R key) is made known only to authorized key release agents (KRA).
The ACA may comprise an access control list and/or security label set. The ACA are capable of supporting the following types of access control policies (or a combination thereof):
1:~ ~ individual-based policy: a list of names of individuals authorized to decrypt;
~ group-based policy: a list of names of groups of authorized individuals; the set of individuals constituting a particular group is maintained by one or more individuals specially authorized for this 20 purpose;
~ role-based policy: a list of role identifiers; each role implies a set of attributes that a decryptor must possess (for example, in a banking environment, distinct roles might be "teller", "branch manager", "auditor", and "customer");
25 ~ context-based controls, e.g., location of decryptor and/or time of day;
and ~ multi-level policy: the decryptor must have a clearance to a particular level, e.g., "unclassified", "confidential", "secret", and "top secret".
30 The ACD block is accompanied at 20 by an identifier of a security domain (Domain id.) and an identifier of a key-release private key (R
key id.). The ciphertext, ACD block, R key id. and Domain id. are sent to the decryptor. As they can be made freely accessible to any party, they can be sent through a nonsecured electronic mail system or by posting 35 them on a public file server. In the figure and figures which follow, all encrypted data and data which contains a Diffie-Hellman exponential are indicated in bold. in other words, the key release agent is a server ~~~.'~'a~:~:; ~E~=T
8a ~ 2~ 870 3 5 system in a computer network which is trusted to deliver decryption keys t~ decrypting systems only when the identity and attributes of the decrypting system (decryptor) match a set of access control criteria determined by the encrypting system at the time of encrypting. The access control criteria are reflected in access control attributes (ACA) described above which in turn form part of access control decryption block (ACD). ACD, on the other hand, is a data structure which accompanies an encrypted message as it traverses a computer network from an encrypting system (encryptor) to a decrypting system IO (decryptor). This data structure, which is generated by the encrypting system, contains a statement of the access control criteria relating to the encryption plus key-related data which will enable a key release agent to calculate the decryption key. The form of the access controlled decryption block is such that only a recognized key release agent can calculate the decryption key and no other entity can modify the access control attributes in a way which the key release agent would not detect.
Figure 2 is a functional schematic diagram of a decryptor and a KRA. To decrypt the ciphertext and ACD, a decryptor 30 obtains ACD
keys through an on-line key-release transaction with a KRA 32. In this embodiment, the E key is the ACD keys but in other embodiments, the ACD keys may contain the E key as well as other keys which may be used to encrypt other parts of ACD, as will be further decribed below.
Each KRA holds each R-key used in its domain. The decryptor initiates a key-release request by sending at 34 the ACD block and R key id. to the AMENDED SHEET
KRA. The KRA will also obtain decryptor privilege attribute information to verify that the requesting decryptor is appropriately authorized. This decryptor privilege attribute information may be just the decryptor's authenticated identity, which may be obtained in one embodiment through the key release transaction request using a suitable authentication mechanism. In another embodiment, more extensive decryptor privilege attribute information, e.g., group-membership, role-membership, or clearance information may be supplied by the decryptor in a certified form, e.g., a privilege attribute certificate signed by a trusted third party, or, in a yet further embodiment, the KRA may obtain decryptor privilege attributes from a supporting database as shown by a dotted line in Figure 2.
Referring further- to Figure 2, using the R key identified by R key id., the KRA processes at 36 the ACD block and recovers the ACD keys and ACA. At 38 the KRA then makes an access control decision based on comparing the ACA (access control attributes) and the decryptor privilege attributes, which may be supplied by the decryptor through the key release request or by the database. If the decryptor is determined to be authorized, the KRA recovers the ACD keys at 40 and returns the plaintext ACD keys to the decryptor 30. The decryptor uses this E key in the ACD keys to decrypt the ciphertext and obtains plaintext at 42. The key-release transaction must be conducted using protected request and release messages 44. In particular, the request 34 must be protected by communications authentication and integrity . mechanisms (e.g., by the decryptor digitally signing the reqaest), and the response 46 must be protected by a communications confidentiality mechanism (e.g., by encrypting under a symmetric key shared by KRA
and decryptor, or encrypting under a public key of the decryptor).
Figure 3 is a functional schematic diagram of the encryptor according to another embodiment of the present invention. In this embodiment, ACD block generation and processing employ a reversible public key cryptosystem. Furthermore, the F ~ 7 keys are concatenated E key and A key. Thus the encryptor ge:: tes a random E key (message encryption key), and a random A key (~~:A encryption key). A plaintext to be confidentiality-protected is encrypted at 50 to produce a ciphertext in a symmetric cryptosystem using the E key. The ACA is encrypted at 52 in a symmetric cryptosystem using the A key.
~~ g~0 3 g IO
At 54, the encryptor concatenates the E and A keys to create ACD keys and at 56 encrypts it with the key-release public key in a reversible public key cryptosystem. The ACA and ACD keys can be formatted with sufficient redundancy that encryption/decryption provides for integrity in addition to confidentiality. At 58, the encryptor inserts a copy of the encrypted ACD keys and the encrypted ACA in an ACD
block. In this embodiment, an R key is a private key of a key pair in a reversible public key cryptosystem and is held by a trusted server system (KRA). When encrypting the ACD keys, the encryptor selects a key-release public key which comes with an identifier for the corresponding R key. The ACD keys are encrypted under the public key of the key-release key pair corresponding to the identified R key. The ciphertext, ACD block, R key id. and Domain id. are sent to the decryptor.
Figure 4 is a functional schematic diagram of a decryptor and a KRA of the same embodiment. The decryptor obtains the E key and the A key through an on-line key-release transaction request 60 with a KRA. Using the R key identified by R key id., the KRA decrypts at 62 the ACD keys to obtain E and A keys from the ACD block. At 64, the KRA uses the A key to decrypt the ACA from the ACD block to recover the plaintext ACA. At 66 and 68, the KRA then makes access control decisions based on comparing the ACA and the decryptor privilege attributes. If the decryptor is determined to be authorized, the KRA
returns the plaintext E key and, optionally, the plaintext A key to the decryptor. The decryptor uses the E key to decrypt the ciphertext and obtains plaintext at 70. If the A key is returned, the decryptor may use it to decrypt the ACA at 72.
Referring now to Figures 5 and 6, yet another embodiment of the present invention is shown in which the encryptor uses the Diffie-Hellman key derivation technique instead of a reversible public key cryptosystem of Figures 3 and 4. In this embodiment, an R key is a secret random Diffie-Hellman exponent y and is identified by R key id.
80. Each KRA holds a copy of each R key used in its domain in a secure manner. Certified copies of the corresponding Diffie-Hellman y-exponential (aY mod p) 82 are made available to encryptors and thus this y-exponential is a public key. When encrypting a plaintext, the encryptor generates new random E and A keys and a random Diffie-_ , ~ J ~.
Hellman exponer, ~ x. The encryptor then selects a y exponential (D-H
public key) and may verify the signature on the applicable certificate.
The x exponential 84 is computed as ax mod p, and a D key (D-H
common key) is computed as (aY)x mod p at 86. As in the earlier embodiment, the E and A keys are concatenated to produce ACD keys which are encrypted at 88 with the D key using a symmetric cryptosystem. The ACA is encrypted at 90 with the A key. The encrypted ACD keys, encrypted ACA, and the x exponential are inserted in an ACD block at 92. The protected parts of the ACD block can be formatted with sufficient redundancy that encryption/decryption of the block provides for integrity in addition to confidentiality. Meanwhile, the plaintext data is encrypted at 94 under the E key using a symmetric cryptosystem to produce a ciphertext. The ciphertext, ACD containing the encrypted parts and plaintext x exponential, R key id. and domain id. are joined at 96 and sent to the decryptor.
Figure 6 shows the decryptor and KRA according to this embodiment. ThE ~cryptor is the same as that in the previous embodiment of Figure 4 and initiates a key release request at 100 by sending to the KRA the ACD, R key id., and decryptor attribute information if required. When the KRA receives a key release request, it computes the D key at 102 as (ax)Y mod p, using the value y indicated by the R key id. This D key is then used at 104 to decrypt the encrypted ACD keys to extract the E and A keys from the ACD block. The A key is then used at 106 to decrypt the encrypted ACA in the ACD block. If subsequent access control decisions at 108 and 110 permit, the E and/or A keys are returned to the decryptor who uses the E key to decrypt the ciphertext at 112 to obtain the plaintext data, and uses the A key to decrypt the ACA at 114. The request 100 of the key-release transaction between the decryptor and the KR.A must be protected by communications authentication and integrity mechanisms and the response I16 of the key-release transaction must be protected by a communications confidentiality mechanism.
If the system is for use strictly within a single domain, a further simplification of the previous embodiment is possible. Figures 7 and 8 are functional schematic diagrams according to this further embodiment of the invention in which the ACD key, which contains the E and A keys is derived using the Diffie-Hellman key derivation technique. In this embodiment therefore, the D key generated in connection with the embodiment illustrated in Figures 5 and 6 is split into E and A keys at 120, with the E part used for encrypting the plaintext data at 122 to obtain a ciphertext, and the A part used to encrypt the ACA at 124. The encryptor need not generate E and A keys.
They are simply computed from the x and y exponential which is a D-H
public key. It is also not necessary to include the encrypted E and A
keys in the ACD block. The decryptor functions are the same as those shown in the previous figures. Thus in Figure 8, the decryptor initiates a key release request at 130 by sending to KRA the ACD, R key id., and optional decryptor attribute information. The KRA then recovers the D key at 132 and, depending on the access control decisions at 134 and 136, returns the E and/or A keys to the decryptor.
There may be situations where the E key should legitimately be released to an entity not covered by the access control attributes, e.g., a law enforcement agency with a court order enabling access to the encrypted data, or a corporate administrator needing to recover protected information after all authorized decryptors have ceased to exist. Therefore, according to another embodiment, the KRA is provided with key-escrow capability. In this embodiment, the KRA
contains a special key release condition in its decision process. The ICIZA accepts a key release transaction from a party other than a decryptor authorized in accordance with the ACA provided special conditions are met, e.g., the request of that key release transaction is authenticated as being originated by a pre-specified number of special authorities, with keys required for authenticating special authorities being held by the KRA.
As described earlier, in the traditional electronic mail key distribution method, every participating user system is required to contain the encryption and decryption capabilities of a reversible public key cryptosystem. There may be a risk of such cryptographic capabilities being used for unintended encryption purposes. In the embodiments of the present invention, on the other hand, a participating user system is only required to have the encryption, but not decryption, capabilities of a public key cryptosystem. The decryption capabilities are only within a small number of closely controlled KRA systems. For this reason, it may be possible to obtain export approval for a stronger (e.g., r r . _ , r T _ r.
WO 95/28784 . PCTlCA95/00084 2' 8 7 0 3 5 y larger modulus) public key cryptosystem than would be possible with the traditional method. Under the embodiments which uses the Diffie-Hellman technique, concerns over unintended use of cryptographically-strong implementations do not arise.
Unlike the known distribution techniques, the present invention does not require message encryptors or decryptors (recipients) to store sensitive secret information. Multi-message compromise can only result from compromise of an R key, which is stored in a small number of tightly controlled trusted server systems.
Furthermore, the traditional method can support only simple lists of authorized individuals as decryptors but the present invention additionally supports such models as group-based models, role-based models, and mufti-level models.
It should further be noted that the key-escrowing capabilities of the present invention compare favourably to other systems such as that specified in the U. S. Government Escrowed Encryption Standard (FIPS PUB ~ 185), because:
a) It is not necessary to store large numbers of keys in a central highly protected location. Only a comparatively small number of R keys need to be stored in a highly protected manner (e.g., hardware cryptomodule) in KRAs.
b) Keys are released on a per-protected-item basis, i.e., release of the E
key for one message does not automatically enable access to other protected data involving the same encryptor and/or decryptor.
With the Escrowed Encryption Standard system, release of escrowed keying information needed to decrypt a single encrypted item means that all other encrypted data originating from the same encrypting device can also be decrypted without obtaining further interception authorization.
Technical Field The present invention relates generally to computer networks in which cryptograw is techniques are used for data confidentiality purposes. More specifically, the invention is directs ~' to a computer network in which decryption of data is only possibir when a decryptor is authorized in accordance with a set of access control attributes specified by the encryptor.
IO
Background Art Cryptographic techniques constitute a major building block used in implementing all security services in computer networks. The basic function provided by a cryptographic system (or cryptosystem) is encipherment/decipherment. A cryptosystem comprises a pair of data transformations, encryption and decryption, respectively. Encryption is applied to a data item, known as plaintext, and generates a new (unintelligible) data item, ciphertext. Decryption, applied to ciphertext, results in the regeneration of the original plaintext. An encryption transformation uses as input both the plaintext data and an independent data value known as an encryption key. Similarly, a decryption transformation uses a decryption key. There are two basic types of cryptosystems - symmetric systems and public key (or asymmetric) systems. In symmetric cryptosystems the same key is used in the encryption and decryption transformations. A public key system has a key pair comprising a public key and a private key. One of these keys is used for encryption and the other for decryption. The public key does not need to be kept confidential.
To provide confidentiality, a symmetric cryptosystem works as follows. Two parties, A and B, want to communicate securely. By some process (e.g., by a secure channel or a trusted courier), they both obtain knowledge of a data value to be used as a key. The key is kept secret from all parties other than A and B. This enables either A or B to protect a message sent to the other party by encrypting it using the shared key. The other party can decrypt the message, but outside parties cannot. A well known symmetric cryptosystem is the U.S. Data Encryption Standard (DES).
X1$70 3 5 2 In a public key cryptosystem there are two basic modes of operation, an encryption mode and an authentication mode. In the encryption mode, the data originator uses the public key for encryption and the recipient uses the private key of the same key pair for decryption. In this system, knowledge of the public key is not enough to deduce the private key. Therefore, the encryptor knows that data encrypted with a public key can only be decrypted by the holder of the corresponding private key. It is also possible to authenticate the encryptor in the authentication mode of operation. In this mode, the encryptor sends ciphertext encrypted by the private key of the key pair.
The decryptor (recipient) then knows that data encrypted with the private key can be decrypted by anyone but could only have been sent by the holder of the private key. A cryptosystem of this kind which can operate in both encryption and authentication modes is known as a reversible public key cryptosystem.
One well known reversible public key cryptosystem is the RSA
system described in U.S. Patent No. 4,405,829 issued on September 20, 1983 to Rivest et al. An RSA key pair is created as follows. An integer a is chosen, to be the public exponent. Two large prime numbers, p and q, are randomly selected, satisfying the conditions that (p-1) and a have no common divisors, and (q-1 ) and a have no common divisors. The public modulus is the value n=pq. The values of n and a together form the public key. A private exponent d is then determined, such that de-1 is divisible by both p-1 and q-1. The values of n and d (or p and q) together constitute the private key. The exponents have the important property that d functions as the inverse of e, that is, for any message M, (Me)d mod n =M. The encryption process for message M involves calculating Me mod n. This can be carried out by anyone who knows the public key, i.e., n and e. Decryption of message M' involves calculating M'd mod n. This requires knowledge of the private key.
Cryptographic techniques all depend upon cryptographic keys.
The keys must be made known in advance (distributed) to the parties that will use them and at the same time they must be protected as necessary against disclosure and/or substitution. Therefore key management, particularly key distribution, is very important. With purely symmetric systems, if the number of keys in a network is to be kept manageable, it is necessary to use trusted key centers for key T T ~ .. ~ .._.~"....__.,.e.~.,~...,..r.... ,~. ,. .. ....... .....
3 ~~8~039:
distribution. For any two systems to communicate securely, they must share a master keying relationship with a Fey center. Furthermore, that key center must be on-Iine at the time secure communications are to be established. Distribution of public keys is simpler and does not require trusted on-line servers. Distribution of a public key does not require confidentiality, but it does require integrity - the user of a public key must be assured that it is the correct public key for the remote party concerned. For this reason, a public key is usually distributed in the form of a certificate which is digitally signed by a trusted certification authority. Certificates can then be distributed by unsecured means, such as a public directory service. A user of a certificate can be assured the certificate contents have not been changed, by verifying the certification authority signature. Installation of a new private/public key pair is straightforward; keys are typically generated I5 within the owner system or a certification authority system. The only secure key transfer necessary is the transfer of one key from either the owner system to the certification authority system, or vice versa. These two systems are usually in the same network, and are typically close to one another.
In comparison with symmetric cryptosystems, public key systems have the advantage of simpler key distribution. However, countering this advantage, symmetric systems have the advantage of lower processing overheads. This makes symmetric systems particularly attractive for the bulk encryption/decryption of large volumes of data.
To benefit from all the advantages, a hybrid approach may be used. Symmetric cryptosystems are used for protecting bulk data and public key systems are used for distributing the symmetric keys (primary keys). For example, if a party A wants to establish a symmetric encryption key with party B, using RSA, it can do so as follows. Party A obtains a copy of party B's public key by obtaining the necessary certificate (possibly sent directly from Party B) and checking the certificate signature (or the signatures on a chain of certificates) to ensure the key is valid. Party A then generates a random symmetric key, and sends it to Party B, encrypted under Party B's public key. Only Party B can learn the symmetric key value, as only Party B knows the private key needed to decipher the message (the encrypted symmetric key value). Hence the two parties establish shared knowledge of the ?1 870 3 5 symmetric key, and can proceed to use it for protecting data communicated between them.
Another well known scheme of establishing a symmetric primary key is known as the Diffie-Hellman key derivation technique described in U.S. Patent No. 4,200,770 issued April 29, 1980 to Hellman et al. This works as follows. Parties A and B agree, in advance, upon a prime number p and a primitive element a in GF(p). Prime p should be such that p-I has a large prime factor. This agreement could be on the basis of published system-wide constants, or could result from previous communications. As the first step in deriving a key, party A
generates a random number x, 0<x<p-1. It then calculates ax mod p, and sends this value to party B. Party B generates a random number y, 0<y<p-1, calculates aY mod p, and sends this value to party A. Then party A calculates (aY)x mod p and party B calculates (ax)Y mod p. Both parties now know a common key, K=axY mod p.
In the traditional electronic mail encryption key distribution method, all message recipients have key pairs of a reversible public key cryptosystem (such as RSA). The message is encrypted using a symmetric cryptosystem, and copies of the encryption key, encrypted under the public key of each recipient, are attached to the message.
Each legitimate recipient can recover the encryption key by decrypting the applicable copy of it with his private key. This method has several shortcomings. Firstly, the only access control model it can support is a simple list of authorized decryptors; other models are often required, such as specifying group membership, role membership, or security clearance. Secondly, every recipient must hold sensitive information, namely the private key of a key pair; compromise of any recipient's private key results in the compromise of all encrypted messages ever sent to that recipient. Thirdly, the encrypting system must obtain and verify, for every authorized recipient, a public key certificate; this can be a lengthy process, given the need to process multiple certificate chains and revocation lists. Fourthly, every participating user is required to possess the encryption and decryption capabilities of a reversible public key cryptosystem. There may be a risk of such cryptographic capabilities being used for unintended encryption purposes.
EP 0503765, published September I6, 1992, describes an access contra in a distributed computer system in that a mechanism restricts and validates an access to a target application by a certain user in a distributed computer system. The user obtains an encrypted privilege attribute certificate (PAC) and a session key from an authentication and privilege server and by using this key it communicates with a key distribution server to obtain a basic key. Then it sends the basic key to a PAC validation facility which determines the identify of the user.
When the target application receives a request for access from the user who presents it with the encrypted PAC, it sends such PAC to the PAC
validation facility which decrypts the PAC and validates the PAC with the user identity.
A cryptographic protocol for secure communications described in EP0535863, published April 7, 1993, sets up a secure communication channel in which prior to information transmission, an asymmetric cryptosystem is used by two parties to agree on a symmetric crypto-graphic key. U.S. Patent 4,888,801, issued December I9, 1989, teaches a hierarchical key management system. The patent describes a key management system by which a secure communication channel can be set up among parties through the use of a SAD (security activation device) issued to each party by a KCA (key certification authority). The SAD is a physical key which is initially programmed by the KCA and subsequently reprogrammed by a secure terminal used by the user. The SAD is inserted into a receptacle of the terminal to enable secure communication and user authentication.
In LT.S. Patent 5,276,73, issued January 4, 1994, a sort of escrow mechanism for a public key cryptosystems is mentioned in which each user is assigned a pair of matching secret and public keys. Each user's secret key is broken into shares. Each user then provides a plurality of trustees pieces of information which enables each trustee to verify its share of the secret key. Thus all the trustees must agree to reveal to a third party the secret key of a user.
EP0343805, published November 29, 1989 describes techniques of reproducing secure keys by using distributed key generation data and a distributed encrypted prekey. Key generation data are divided into more than one part and each part is encrypted in a distributed fashion, AMENDED SHEET
first by a first key prekey to obtain a symmetric key by which information is scrambled before transmission.
The present invention addresses these problems and others which will become apparent in the following detailed description. The_ invention relates to a key distribution method which enables an encryptor of a data item to specify, in terms of any desired access control model, the set of authorized decryptors. The present invention makes use of trusted servers called key release agents. While type invention is not restricted to use within any particular application environment, it is most naturally applicable to environments where broad user populations inherently have access to encrypted information, e.g., file servers, bulletin boards, or groupware applications.
The present invention also provides for controlled release of decryption keys under special circumstances, such as authorized interception by law enforcement agencies. This can be achieved by building a special key release condition into the key release agent's decision process. When used for this purpose, the present invention overcomes deficiencies apparent in the key-escrow system described in the U.S. Government FIPS 185 Escrowed Encryption Standard which addresses the same requirements.
Ob,~ects of the Invention It is therefore an object of the present invention to provide a method and a system of securely distributing through a computer network an encryption key to decryptors who are authorized according to a set of access control attributes specified by the encryptor.
It is another object of the present invention to provide a method and a system of a decryptor recovering an encryption key from a key release agent in a secure manner.
It is yet a further object of the present invention to provide a method and a system of a key release agent recovering an encryption key from an encrypted access controlled decryption block which contains the access control attributes.
It is still a further object of the present invention to provide a method and a system of a key release agent releasing an encryption key to a party other than a decryptor that is explicitly authorized by the encryptor.
~Pr~ETIDED SHEET
Disclosure of Invention _Briefly stated, the present invention relates generally to a computer network which includes an encryptor, multiple decryptors and one or more key release agents. In one aspect, the invention is directed to a method of publicly distributing a message encryption key through the computer network. The method comprises a step of the encryptor generating an access controlled decryption block (ACD), which contains key data related to a message encryption key and a statement of access control criteria with respect to authorized decryptors, both being protected using a key release public key for which only the key release agent in a particular security domain has knowledge of the corresponding key release private key. The method further includes steps of the encryptor distributing the access controlled decryption block, a security domain identifier (Domain id), and an identifier (R key id) of the key release private key. In the method there are steps of the decryptor sending to the key release agent in a locally-protected transaction a key release request which includes the access controlled decryption block, the identifier of the key release private key, and decryptor attributes that include the decryptor's identity. There are yet further steps of the key release agent recovering the message encryption key and access control attributes using data in the access controlled decryption block and the key release private key and determining, on the basis of the decryptor attributes and the statement of access control criteria in the access controlled decryption block, if the decryptor is authorized to decrypt the message ciphertext and if the decryptor is so authorized, the key release agent sending the message encryption key to the decryptor in a locally-protected transaction.
According to another aspect, the invention is directed to a computer network in which a message encryption key is publicly distributed between an encryptor and a decrypfor by way of a key release agent. The network comprises the encryptor including a transmitting device for transmitting to the decryptor through the network a ciphertext, an access controlled decryption block (ACD), and an identifier associated with a key release public-private key pair, the access controlled decryption block including a set of access control attributes (ACA) and key data related to the message encryption key, the encryptor further including a message encryption device for 1;1~,11L~~~~:J ~ls'~~=
21 87~ 3 5 producing the ciphertext using the message encryption key and ACD
generation device for generating the access controlled decryption block using the key release public key. The network further includes the decryptor having a transaction device for sending the access controlled decryption block and the identifier together with a set of decryptor attributes to the key release agent in a locally-protected transaction.
The network yet further includes the key release agent having the key release private key and ACD processing device for recovering the message encryption key and access control attributes by using the key release private key, the key release agent further including a determining device for deciding, based on the recovered access control attributes and the decryptor attributes, whether the decryptor is authorized to decrypt the ciphertext and transmitting device for sending to the decryptor the message encryption key in a locally-protected transaction.
~IMENDED SHEET
21 ~~70~5 - , Brief Description of the Drawings Figures 1 and 2 are functional schematic diagrams of an encryptor, a decryptor and a key release agent according to a generic embodiment of the present invention;
Figures 3 and 4 are functional schematic diagrams of an encryptor, a decryptor and a key release agent according to another embodiment of the present invention which is based on a reversible public key cryptosystem;
Figures 5 and 6 are functional schematic diagrams of an encryptor, a decryptor and a key release agent according to another embodiment of the present invention which is based on the Diffie-Hellman Key Derivation technique; and Figures 7 and 8 are functional schematic diagrams of an encryptor, a decryptor and a key release agent according to yet another I5 embodiment of the present invention which is also based on the Diffie-Hellman Key Derivation technique.
Models) of Carrving'Out the Invention Figure 1 is a functional schematic diagram of the encryptor according to one embodiment of the present invention. In this embodiment, an encryptor IO determines access control criteria and generates ACA (access control attributes) to reflect such criteria. The encryptor 10 generates a local input I2 which is input, together with the ACA and a key release public key 14 to a function 16 which generates an E key (message encryption key) and a protected data construct called an ACD (access controlled decryption) block. A plaintext to be confidentiality-protected is encrypted at 18 to produce a ciphertext in a symmetric cryptosystem using the E key. An R key is a private key of a key-release key pair and is held by a trusted server system in the specified domain called a KRA (key release agent). Each KRA holds a copy of each R key used in its domain in a secure manner (e.g., in a hardware cryptomodule). Certified copies of the corresponding key-release public keys are made available to encryptors. The KRA will also be described in detail below. Thus when generating the ACD block, the AME~JDED SHEET
encryptor selects a key-release public key, which comes with an identifier- for the corresponding R key and verifies the signature on the applicable public key certificate. Stated more clearly, the key release private key (R key) and the key release public key (Pub key) form a key -release key pair which is a key pair of a public-key cryptosystem used in protecting an access controlled decryption block (ACD) against use or modification by any system other than a recognized key release agent (KRA). The key release public key is made available to encrypting systems (encryptors) and used by them in generating access controlled IO decryption blocks while the key release private key (R key) is made known only to authorized key release agents (KRA).
The ACA may comprise an access control list and/or security label set. The ACA are capable of supporting the following types of access control policies (or a combination thereof):
1:~ ~ individual-based policy: a list of names of individuals authorized to decrypt;
~ group-based policy: a list of names of groups of authorized individuals; the set of individuals constituting a particular group is maintained by one or more individuals specially authorized for this 20 purpose;
~ role-based policy: a list of role identifiers; each role implies a set of attributes that a decryptor must possess (for example, in a banking environment, distinct roles might be "teller", "branch manager", "auditor", and "customer");
25 ~ context-based controls, e.g., location of decryptor and/or time of day;
and ~ multi-level policy: the decryptor must have a clearance to a particular level, e.g., "unclassified", "confidential", "secret", and "top secret".
30 The ACD block is accompanied at 20 by an identifier of a security domain (Domain id.) and an identifier of a key-release private key (R
key id.). The ciphertext, ACD block, R key id. and Domain id. are sent to the decryptor. As they can be made freely accessible to any party, they can be sent through a nonsecured electronic mail system or by posting 35 them on a public file server. In the figure and figures which follow, all encrypted data and data which contains a Diffie-Hellman exponential are indicated in bold. in other words, the key release agent is a server ~~~.'~'a~:~:; ~E~=T
8a ~ 2~ 870 3 5 system in a computer network which is trusted to deliver decryption keys t~ decrypting systems only when the identity and attributes of the decrypting system (decryptor) match a set of access control criteria determined by the encrypting system at the time of encrypting. The access control criteria are reflected in access control attributes (ACA) described above which in turn form part of access control decryption block (ACD). ACD, on the other hand, is a data structure which accompanies an encrypted message as it traverses a computer network from an encrypting system (encryptor) to a decrypting system IO (decryptor). This data structure, which is generated by the encrypting system, contains a statement of the access control criteria relating to the encryption plus key-related data which will enable a key release agent to calculate the decryption key. The form of the access controlled decryption block is such that only a recognized key release agent can calculate the decryption key and no other entity can modify the access control attributes in a way which the key release agent would not detect.
Figure 2 is a functional schematic diagram of a decryptor and a KRA. To decrypt the ciphertext and ACD, a decryptor 30 obtains ACD
keys through an on-line key-release transaction with a KRA 32. In this embodiment, the E key is the ACD keys but in other embodiments, the ACD keys may contain the E key as well as other keys which may be used to encrypt other parts of ACD, as will be further decribed below.
Each KRA holds each R-key used in its domain. The decryptor initiates a key-release request by sending at 34 the ACD block and R key id. to the AMENDED SHEET
KRA. The KRA will also obtain decryptor privilege attribute information to verify that the requesting decryptor is appropriately authorized. This decryptor privilege attribute information may be just the decryptor's authenticated identity, which may be obtained in one embodiment through the key release transaction request using a suitable authentication mechanism. In another embodiment, more extensive decryptor privilege attribute information, e.g., group-membership, role-membership, or clearance information may be supplied by the decryptor in a certified form, e.g., a privilege attribute certificate signed by a trusted third party, or, in a yet further embodiment, the KRA may obtain decryptor privilege attributes from a supporting database as shown by a dotted line in Figure 2.
Referring further- to Figure 2, using the R key identified by R key id., the KRA processes at 36 the ACD block and recovers the ACD keys and ACA. At 38 the KRA then makes an access control decision based on comparing the ACA (access control attributes) and the decryptor privilege attributes, which may be supplied by the decryptor through the key release request or by the database. If the decryptor is determined to be authorized, the KRA recovers the ACD keys at 40 and returns the plaintext ACD keys to the decryptor 30. The decryptor uses this E key in the ACD keys to decrypt the ciphertext and obtains plaintext at 42. The key-release transaction must be conducted using protected request and release messages 44. In particular, the request 34 must be protected by communications authentication and integrity . mechanisms (e.g., by the decryptor digitally signing the reqaest), and the response 46 must be protected by a communications confidentiality mechanism (e.g., by encrypting under a symmetric key shared by KRA
and decryptor, or encrypting under a public key of the decryptor).
Figure 3 is a functional schematic diagram of the encryptor according to another embodiment of the present invention. In this embodiment, ACD block generation and processing employ a reversible public key cryptosystem. Furthermore, the F ~ 7 keys are concatenated E key and A key. Thus the encryptor ge:: tes a random E key (message encryption key), and a random A key (~~:A encryption key). A plaintext to be confidentiality-protected is encrypted at 50 to produce a ciphertext in a symmetric cryptosystem using the E key. The ACA is encrypted at 52 in a symmetric cryptosystem using the A key.
~~ g~0 3 g IO
At 54, the encryptor concatenates the E and A keys to create ACD keys and at 56 encrypts it with the key-release public key in a reversible public key cryptosystem. The ACA and ACD keys can be formatted with sufficient redundancy that encryption/decryption provides for integrity in addition to confidentiality. At 58, the encryptor inserts a copy of the encrypted ACD keys and the encrypted ACA in an ACD
block. In this embodiment, an R key is a private key of a key pair in a reversible public key cryptosystem and is held by a trusted server system (KRA). When encrypting the ACD keys, the encryptor selects a key-release public key which comes with an identifier for the corresponding R key. The ACD keys are encrypted under the public key of the key-release key pair corresponding to the identified R key. The ciphertext, ACD block, R key id. and Domain id. are sent to the decryptor.
Figure 4 is a functional schematic diagram of a decryptor and a KRA of the same embodiment. The decryptor obtains the E key and the A key through an on-line key-release transaction request 60 with a KRA. Using the R key identified by R key id., the KRA decrypts at 62 the ACD keys to obtain E and A keys from the ACD block. At 64, the KRA uses the A key to decrypt the ACA from the ACD block to recover the plaintext ACA. At 66 and 68, the KRA then makes access control decisions based on comparing the ACA and the decryptor privilege attributes. If the decryptor is determined to be authorized, the KRA
returns the plaintext E key and, optionally, the plaintext A key to the decryptor. The decryptor uses the E key to decrypt the ciphertext and obtains plaintext at 70. If the A key is returned, the decryptor may use it to decrypt the ACA at 72.
Referring now to Figures 5 and 6, yet another embodiment of the present invention is shown in which the encryptor uses the Diffie-Hellman key derivation technique instead of a reversible public key cryptosystem of Figures 3 and 4. In this embodiment, an R key is a secret random Diffie-Hellman exponent y and is identified by R key id.
80. Each KRA holds a copy of each R key used in its domain in a secure manner. Certified copies of the corresponding Diffie-Hellman y-exponential (aY mod p) 82 are made available to encryptors and thus this y-exponential is a public key. When encrypting a plaintext, the encryptor generates new random E and A keys and a random Diffie-_ , ~ J ~.
Hellman exponer, ~ x. The encryptor then selects a y exponential (D-H
public key) and may verify the signature on the applicable certificate.
The x exponential 84 is computed as ax mod p, and a D key (D-H
common key) is computed as (aY)x mod p at 86. As in the earlier embodiment, the E and A keys are concatenated to produce ACD keys which are encrypted at 88 with the D key using a symmetric cryptosystem. The ACA is encrypted at 90 with the A key. The encrypted ACD keys, encrypted ACA, and the x exponential are inserted in an ACD block at 92. The protected parts of the ACD block can be formatted with sufficient redundancy that encryption/decryption of the block provides for integrity in addition to confidentiality. Meanwhile, the plaintext data is encrypted at 94 under the E key using a symmetric cryptosystem to produce a ciphertext. The ciphertext, ACD containing the encrypted parts and plaintext x exponential, R key id. and domain id. are joined at 96 and sent to the decryptor.
Figure 6 shows the decryptor and KRA according to this embodiment. ThE ~cryptor is the same as that in the previous embodiment of Figure 4 and initiates a key release request at 100 by sending to the KRA the ACD, R key id., and decryptor attribute information if required. When the KRA receives a key release request, it computes the D key at 102 as (ax)Y mod p, using the value y indicated by the R key id. This D key is then used at 104 to decrypt the encrypted ACD keys to extract the E and A keys from the ACD block. The A key is then used at 106 to decrypt the encrypted ACA in the ACD block. If subsequent access control decisions at 108 and 110 permit, the E and/or A keys are returned to the decryptor who uses the E key to decrypt the ciphertext at 112 to obtain the plaintext data, and uses the A key to decrypt the ACA at 114. The request 100 of the key-release transaction between the decryptor and the KR.A must be protected by communications authentication and integrity mechanisms and the response I16 of the key-release transaction must be protected by a communications confidentiality mechanism.
If the system is for use strictly within a single domain, a further simplification of the previous embodiment is possible. Figures 7 and 8 are functional schematic diagrams according to this further embodiment of the invention in which the ACD key, which contains the E and A keys is derived using the Diffie-Hellman key derivation technique. In this embodiment therefore, the D key generated in connection with the embodiment illustrated in Figures 5 and 6 is split into E and A keys at 120, with the E part used for encrypting the plaintext data at 122 to obtain a ciphertext, and the A part used to encrypt the ACA at 124. The encryptor need not generate E and A keys.
They are simply computed from the x and y exponential which is a D-H
public key. It is also not necessary to include the encrypted E and A
keys in the ACD block. The decryptor functions are the same as those shown in the previous figures. Thus in Figure 8, the decryptor initiates a key release request at 130 by sending to KRA the ACD, R key id., and optional decryptor attribute information. The KRA then recovers the D key at 132 and, depending on the access control decisions at 134 and 136, returns the E and/or A keys to the decryptor.
There may be situations where the E key should legitimately be released to an entity not covered by the access control attributes, e.g., a law enforcement agency with a court order enabling access to the encrypted data, or a corporate administrator needing to recover protected information after all authorized decryptors have ceased to exist. Therefore, according to another embodiment, the KRA is provided with key-escrow capability. In this embodiment, the KRA
contains a special key release condition in its decision process. The ICIZA accepts a key release transaction from a party other than a decryptor authorized in accordance with the ACA provided special conditions are met, e.g., the request of that key release transaction is authenticated as being originated by a pre-specified number of special authorities, with keys required for authenticating special authorities being held by the KRA.
As described earlier, in the traditional electronic mail key distribution method, every participating user system is required to contain the encryption and decryption capabilities of a reversible public key cryptosystem. There may be a risk of such cryptographic capabilities being used for unintended encryption purposes. In the embodiments of the present invention, on the other hand, a participating user system is only required to have the encryption, but not decryption, capabilities of a public key cryptosystem. The decryption capabilities are only within a small number of closely controlled KRA systems. For this reason, it may be possible to obtain export approval for a stronger (e.g., r r . _ , r T _ r.
WO 95/28784 . PCTlCA95/00084 2' 8 7 0 3 5 y larger modulus) public key cryptosystem than would be possible with the traditional method. Under the embodiments which uses the Diffie-Hellman technique, concerns over unintended use of cryptographically-strong implementations do not arise.
Unlike the known distribution techniques, the present invention does not require message encryptors or decryptors (recipients) to store sensitive secret information. Multi-message compromise can only result from compromise of an R key, which is stored in a small number of tightly controlled trusted server systems.
Furthermore, the traditional method can support only simple lists of authorized individuals as decryptors but the present invention additionally supports such models as group-based models, role-based models, and mufti-level models.
It should further be noted that the key-escrowing capabilities of the present invention compare favourably to other systems such as that specified in the U. S. Government Escrowed Encryption Standard (FIPS PUB ~ 185), because:
a) It is not necessary to store large numbers of keys in a central highly protected location. Only a comparatively small number of R keys need to be stored in a highly protected manner (e.g., hardware cryptomodule) in KRAs.
b) Keys are released on a per-protected-item basis, i.e., release of the E
key for one message does not automatically enable access to other protected data involving the same encryptor and/or decryptor.
With the Escrowed Encryption Standard system, release of escrowed keying information needed to decrypt a single encrypted item means that all other encrypted data originating from the same encrypting device can also be decrypted without obtaining further interception authorization.
Claims (16)
1. A method of publicly distributing a message encryption key (E key) through the network which includes an encryptor (10), a decryptor (30) and a key release agent (32) comprising steps of:
the encryptor generating an access controlled decryption block (ACD), which contains key data related to message encryption key and a statement of access control criteria with respect to authorized decryptors, both being protected using a key release public key (14) for which only the key release agent in a particular security domain has knowledge of the corresponding key release private key;
the encryptor distributing the access controlled decryption block, a security domain indentifier (Domain id), and an identifier (R key id) of the key release private key;
the decryptor sending to the key release agent in a locally-protected transaction (44) a key release request which includes the access controlled decryption block, the identifier of the key release private key, and decryptor attributes that include the decryptor's identity;
the key release agent recovering the message encryption key and access control attributes using data in the access controlled decryption block and the key release private key and determining, on the basis of the decryptor attributes and the statement of access control criteria in the access controlled decryption block, if the decryptor is authorized to decrypt message ciphertext (20); and if the decryptor is so authorized, the key release agent sending the message encryption key to the decryptor in a locally-protected transaction.
the encryptor generating an access controlled decryption block (ACD), which contains key data related to message encryption key and a statement of access control criteria with respect to authorized decryptors, both being protected using a key release public key (14) for which only the key release agent in a particular security domain has knowledge of the corresponding key release private key;
the encryptor distributing the access controlled decryption block, a security domain indentifier (Domain id), and an identifier (R key id) of the key release private key;
the decryptor sending to the key release agent in a locally-protected transaction (44) a key release request which includes the access controlled decryption block, the identifier of the key release private key, and decryptor attributes that include the decryptor's identity;
the key release agent recovering the message encryption key and access control attributes using data in the access controlled decryption block and the key release private key and determining, on the basis of the decryptor attributes and the statement of access control criteria in the access controlled decryption block, if the decryptor is authorized to decrypt message ciphertext (20); and if the decryptor is so authorized, the key release agent sending the message encryption key to the decryptor in a locally-protected transaction.
2. The method of publicly distributing the message encryption key according to claim 1 further comprising steps of the encryptor:
encrypting (52) access control attributes under an access control encryption key (A key), the access control attributes containing the statement of access control criteria;
encrypting (56) both the access control encryption key and the message encryption key by using the key release public key; and inserting (58) the encrypted access control attributes, the access control encryption key and the message encryption key in the access control decryption block.
encrypting (52) access control attributes under an access control encryption key (A key), the access control attributes containing the statement of access control criteria;
encrypting (56) both the access control encryption key and the message encryption key by using the key release public key; and inserting (58) the encrypted access control attributes, the access control encryption key and the message encryption key in the access control decryption block.
3. The method of publicly distributing the message encryption key according to claim 2 wherein the key release public key is a key used in the Diffie-Hellman key derivation technique and the step of the encryptor sending to the decryptor includes a step of sending the access controlled decryption block, which further includes an exponential (84) used in the Diffie-Hellman key derivation technique.
4. The method of publicly distributing the message encryption key according to claim 2, wherein the key release public key is used in the Diffie-Hellman key derivation technique to generate a D key which contains the message encryption key and the access control encryption key.
5. The method of publicly distributing the message encryption key according to claim 1, wherein the step of the encryptor sending to the decryptor includes a step of sending the access controlled decryption block which further includes access control attributes describing authorization of the decryptor.
6. The method of publicly distributing the message encryption key according to claim 5 further comprising a step of the key release agent obtaining the decryptor attribute from a database on a separate channel.
7. The method of publicly distributing a message encryption key in a computer network according to any one of claims 1, 3, 4 and 6 comprising a further step of:
the encryptor using the Diffie-Hellman key derivation technique to generate the message encryption key.
the encryptor using the Diffie-Hellman key derivation technique to generate the message encryption key.
8. A computer network in which a message encryption key is publicly distributed between an encryptor (10) and a decryptor (30) by way of a key release agent (32), comprising:
the encryptor including a transmitting device for transmitting to the decryptor through the network a ciphertext, an access controlled decryption block (ACD), and an identifier associated with a key release public-private key pair, the access controlled decryption block including a set of access control attributes (ACA) and key data related to the message encryption key (E key), the encryptor further including message encryption device for producing the ciphertext using the message encryption key and an ACD generation device (16) for generating the access controlled decryption block using the key release public key (Pub key);
the decryptor (30) having transaction device for sending the access controlled decryption block and the identifier together with a set of decryptor attributes to the key release agent in a locally-protected transaction (44); and the key release agent (32) having the key release private key and an ACD
processing device (36) for recovering the message encryption key and access control attributes by using the key release private key (R key), the key release agent (32) further including determining device for deciding, based on the recovered access control attributes and the decryptor attributes, whether the decryptor is authorized to decrypt the ciphertext and transmitting device for sending to the decryptor the message encryption key in a locally-protected transaction (44).
the encryptor including a transmitting device for transmitting to the decryptor through the network a ciphertext, an access controlled decryption block (ACD), and an identifier associated with a key release public-private key pair, the access controlled decryption block including a set of access control attributes (ACA) and key data related to the message encryption key (E key), the encryptor further including message encryption device for producing the ciphertext using the message encryption key and an ACD generation device (16) for generating the access controlled decryption block using the key release public key (Pub key);
the decryptor (30) having transaction device for sending the access controlled decryption block and the identifier together with a set of decryptor attributes to the key release agent in a locally-protected transaction (44); and the key release agent (32) having the key release private key and an ACD
processing device (36) for recovering the message encryption key and access control attributes by using the key release private key (R key), the key release agent (32) further including determining device for deciding, based on the recovered access control attributes and the decryptor attributes, whether the decryptor is authorized to decrypt the ciphertext and transmitting device for sending to the decryptor the message encryption key in a locally-protected transaction (44).
9. The computer network according to claim 8, wherein the encryptor further comprising an access control encryption device (52) for encrypting the access control attributes under an access control encryption key (A key) and the ACD
generation device (16) encrypting the message encryption key and the access control encryption key using the key release public key.
generation device (16) encrypting the message encryption key and the access control encryption key using the key release public key.
10. The computer network according to claim 8, wherein a release key comprises a public key (14) and a corresponding private key used in a reversible public key cryptosystem, the encryptor having the public key and the key release agent having the private key.
11. The computer network according to claim 9, wherein a release key comprises a public key and a corresponding private key used in a reversible public key cryptosystem, the encryptor having the public key and the key release agent having the private key.
12. The computer network according to claim 8, wherein a release key comprises a key generated by the Diffie-Hellman key derivation technique.
13. The computer network according to claim 9, wherein a release key comprises a key generated by the Diffie-Hellman key derivation technique.
14. The computer network according to claim 10, wherein the message encryption key and the release key are same and comprise a key generated by the Diffie-Hellman key derivation technique.
15. The computer network according to claim 9, wherein the key release agent further comprises key escrow device for determining if a third party other than the encryptor and decryptor is authorized to decrypt the ciphertext.
16. The computer network according to claim 9, wherein the key release agent further comprises a telecommunications channel connected to a database for obtaining the decryptor attributes.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/227,871 | 1994-04-15 | ||
| US08/227,871 US5481613A (en) | 1994-04-15 | 1994-04-15 | Computer network cryptographic key distribution system |
| PCT/CA1995/000084 WO1995028784A1 (en) | 1994-04-15 | 1995-02-22 | Computer network cryptographic key distribution system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2187035A1 CA2187035A1 (en) | 1995-10-26 |
| CA2187035C true CA2187035C (en) | 1999-10-05 |
Family
ID=22854805
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002187035A Expired - Lifetime CA2187035C (en) | 1994-04-15 | 1995-02-22 | Computer network cryptographic key distribution system |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US5481613A (en) |
| EP (1) | EP0755598B1 (en) |
| JP (1) | JP3060071B2 (en) |
| CA (1) | CA2187035C (en) |
| DE (1) | DE69504823T2 (en) |
| WO (1) | WO1995028784A1 (en) |
Families Citing this family (137)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5870474A (en) * | 1995-12-04 | 1999-02-09 | Scientific-Atlanta, Inc. | Method and apparatus for providing conditional access in connection-oriented, interactive networks with a multiplicity of service providers |
| US6292568B1 (en) | 1966-12-16 | 2001-09-18 | Scientific-Atlanta, Inc. | Representing entitlements to service in a conditional access system |
| US10361802B1 (en) | 1999-02-01 | 2019-07-23 | Blanding Hovenweep, Llc | Adaptive pattern recognition based control system and method |
| IL106796A (en) * | 1993-08-25 | 1997-11-20 | Algorithmic Res Ltd | Broadcast encryption |
| US5825880A (en) | 1994-01-13 | 1998-10-20 | Sudia; Frank W. | Multi-step digital signature method and system |
| US20020013898A1 (en) * | 1997-06-04 | 2002-01-31 | Sudia Frank W. | Method and apparatus for roaming use of cryptographic values |
| US5557765A (en) * | 1994-08-11 | 1996-09-17 | Trusted Information Systems, Inc. | System and method for data recovery |
| US5557346A (en) * | 1994-08-11 | 1996-09-17 | Trusted Information Systems, Inc. | System and method for key escrow encryption |
| CA2138302C (en) * | 1994-12-15 | 1999-05-25 | Michael S. Fortinsky | Provision of secure access to external resources from a distributed computing environment |
| US6658568B1 (en) * | 1995-02-13 | 2003-12-02 | Intertrust Technologies Corporation | Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management |
| US7133846B1 (en) * | 1995-02-13 | 2006-11-07 | Intertrust Technologies Corp. | Digital certificate support system, methods and techniques for secure electronic commerce transaction and rights management |
| US6272632B1 (en) * | 1995-02-21 | 2001-08-07 | Network Associates, Inc. | System and method for controlling access to a user secret using a key recovery field |
| US5633928A (en) * | 1995-03-10 | 1997-05-27 | Bell Communications Research, Inc. | Key escrow method with warrant bounds |
| US6937729B2 (en) * | 1995-04-03 | 2005-08-30 | Scientific-Atlanta, Inc. | Representing entitlements to service in a conditional access system |
| US6252964B1 (en) * | 1995-04-03 | 2001-06-26 | Scientific-Atlanta, Inc. | Authorization of services in a conditional access system |
| US6560340B1 (en) | 1995-04-03 | 2003-05-06 | Scientific-Atlanta, Inc. | Method and apparatus for geographically limiting service in a conditional access system |
| US20040136532A1 (en) * | 1995-04-03 | 2004-07-15 | Pinder Howard G. | Partial dual-encrypted stream utilizing program map tables |
| US7224798B2 (en) * | 1995-04-03 | 2007-05-29 | Scientific-Atlanta, Inc. | Methods and apparatus for providing a partial dual-encrypted stream in a conditional access overlay system |
| US6246767B1 (en) | 1995-04-03 | 2001-06-12 | Scientific-Atlanta, Inc. | Source authentication of download information in a conditional access system |
| US6424717B1 (en) | 1995-04-03 | 2002-07-23 | Scientific-Atlanta, Inc. | Encryption devices for use in a conditional access system |
| US6157719A (en) * | 1995-04-03 | 2000-12-05 | Scientific-Atlanta, Inc. | Conditional access system |
| US8548166B2 (en) | 1995-04-03 | 2013-10-01 | Anthony J. Wasilewski | Method for partially encrypting program data |
| NZ306846A (en) * | 1995-06-05 | 2000-01-28 | Certco Llc | Digital signing method using partial signatures |
| US5687235A (en) * | 1995-10-26 | 1997-11-11 | Novell, Inc. | Certificate revocation performance optimization |
| DE19540930C1 (en) * | 1995-11-03 | 1997-04-24 | Strohschneider Sabine | Method for creating an information distribution system for any number of closed user groups using a physical unit |
| DE19549014C1 (en) * | 1995-12-28 | 1997-02-20 | Siemens Ag | Protected function activation method for communication system |
| DE872077T1 (en) * | 1995-12-29 | 1999-05-06 | Scientific Atlanta | METHOD AND DEVICE FOR CONDITIONAL ACCESS IN CONNECTION-ORIENTED INTERACTIVE NETWORKS WITH SEVERAL SERVICE PROVIDERS |
| US5768373A (en) * | 1996-05-06 | 1998-06-16 | Symantec Corporation | Method for providing a secure non-reusable one-time password |
| US6483920B2 (en) | 1996-12-04 | 2002-11-19 | Bull, S.A. | Key recovery process used for strong encryption of messages |
| FR2763192B1 (en) * | 1996-10-18 | 1999-07-02 | Bull Sa | METHOD FOR RECOVERING KEYS IMPLEMENTED FOR A STRONG MESSAGE ENCRYPTION |
| US5920630A (en) * | 1997-02-25 | 1999-07-06 | United States Of America | Method of public key cryptography that includes key escrow |
| US6035041A (en) * | 1997-04-28 | 2000-03-07 | Certco, Inc. | Optimal-resilience, proactive, public-key cryptographic system and method |
| DE19718583C5 (en) * | 1997-05-05 | 2007-04-26 | T-Mobile Deutschland Gmbh | End-to-end encryption |
| IL132961A0 (en) * | 1997-05-28 | 2001-03-19 | Young Adam Lucas | Auto-recoverable auto-certifiable cryptosystems |
| US6314190B1 (en) | 1997-06-06 | 2001-11-06 | Networks Associates Technology, Inc. | Cryptographic system with methods for user-controlled message recovery |
| US6775382B1 (en) * | 1997-06-30 | 2004-08-10 | Sun Microsystems, Inc. | Method and apparatus for recovering encryption session keys |
| US6603857B1 (en) * | 1997-07-14 | 2003-08-05 | Entrust Technologies Limited | Method and apparatus for controlling release of time sensitive information |
| US6229894B1 (en) * | 1997-07-14 | 2001-05-08 | Entrust Technologies, Ltd. | Method and apparatus for access to user-specific encryption information |
| WO1999004530A1 (en) * | 1997-07-15 | 1999-01-28 | V-One Corporation | File encryption with key recovery |
| US7515712B2 (en) * | 1997-08-01 | 2009-04-07 | Cisco Technology, Inc. | Mechanism and apparatus for encapsulation of entitlement authorization in conditional access system |
| BR9815610A (en) * | 1997-08-01 | 2004-06-22 | Scientific Atlanta | Verification of program information source in conditional access system |
| US6160891A (en) * | 1997-10-20 | 2000-12-12 | Sun Microsystems, Inc. | Methods and apparatus for recovering keys |
| US6349289B1 (en) | 1998-01-16 | 2002-02-19 | Ameritech Corporation | Method and system for tracking computer system usage through a remote access security device |
| US6192129B1 (en) | 1998-02-04 | 2001-02-20 | International Business Machines Corporation | Method and apparatus for advanced byte-oriented symmetric key block cipher with variable length key and block |
| US6243470B1 (en) | 1998-02-04 | 2001-06-05 | International Business Machines Corporation | Method and apparatus for advanced symmetric key block cipher with variable length key and block |
| US6189095B1 (en) | 1998-06-05 | 2001-02-13 | International Business Machines Corporation | Symmetric block cipher using multiple stages with modified type-1 and type-3 feistel networks |
| WO2000022787A2 (en) * | 1998-10-09 | 2000-04-20 | Bankers Trust Company | Method, system, and computer program product for providing enhanced electronic mail services |
| US6230266B1 (en) | 1999-02-03 | 2001-05-08 | Sun Microsystems, Inc. | Authentication system and process |
| EP1208412A2 (en) * | 1999-02-26 | 2002-05-29 | Reveo, Inc. | Globally time-synchronized systems, devices and methods |
| US20020026321A1 (en) | 1999-02-26 | 2002-02-28 | Sadeg M. Faris | Internet-based system and method for fairly and securely enabling timed-constrained competition using globally time-sychronized client subsystems and information servers having microsecond client-event resolution |
| US6625734B1 (en) * | 1999-04-26 | 2003-09-23 | Disappearing, Inc. | Controlling and tracking access to disseminated information |
| SE514105C2 (en) * | 1999-05-07 | 2001-01-08 | Ericsson Telefon Ab L M | Secure distribution and protection of encryption key information |
| US6694025B1 (en) | 1999-06-02 | 2004-02-17 | Koninklijke Philips Electronics N.V. | Method and apparatus for secure distribution of public/private key pairs |
| US7142676B1 (en) * | 1999-06-08 | 2006-11-28 | Entrust Limited | Method and apparatus for secure communications using third-party key provider |
| US7269261B1 (en) * | 1999-09-22 | 2007-09-11 | Raytheon Company | Key escrow systems |
| US20080082446A1 (en) * | 1999-10-01 | 2008-04-03 | Hicks Christian B | Remote Authorization for Unlocking Electronic Data System and Method |
| US20050213758A1 (en) * | 2000-02-07 | 2005-09-29 | Lenstra Arjen K | Efficient and compact subgroup trace representation ("XTR") |
| US7076061B1 (en) | 2000-02-07 | 2006-07-11 | Citibank, N.A. | Efficient and compact subgroup trace representation (“XTR”) |
| SG103257A1 (en) * | 2000-04-13 | 2004-04-29 | Kent Ridge Digital Labs | Private retrieval of digital objects |
| US6807277B1 (en) | 2000-06-12 | 2004-10-19 | Surety, Llc | Secure messaging system with return receipts |
| US20040073617A1 (en) * | 2000-06-19 | 2004-04-15 | Milliken Walter Clark | Hash-based systems and methods for detecting and preventing transmission of unwanted e-mail |
| US7587368B2 (en) * | 2000-07-06 | 2009-09-08 | David Paul Felsher | Information record infrastructure, system and method |
| US6851049B1 (en) * | 2000-10-02 | 2005-02-01 | Pgp Corporation | Method and apparatus for facilitating secure anonymous email recipients |
| US20020071567A1 (en) * | 2000-12-12 | 2002-06-13 | Kurn David Michael | Scalable computer system using remote agents to manipulate cryptographic keys |
| US8161565B1 (en) * | 2000-12-26 | 2012-04-17 | Entrust, Inc. | Key release systems, components and methods |
| US7181017B1 (en) | 2001-03-23 | 2007-02-20 | David Felsher | System and method for secure three-party communications |
| US7693508B2 (en) * | 2001-03-28 | 2010-04-06 | Qualcomm Incorporated | Method and apparatus for broadcast signaling in a wireless communication system |
| US8077679B2 (en) * | 2001-03-28 | 2011-12-13 | Qualcomm Incorporated | Method and apparatus for providing protocol options in a wireless communication system |
| US8121296B2 (en) * | 2001-03-28 | 2012-02-21 | Qualcomm Incorporated | Method and apparatus for security in a data processing system |
| US9100457B2 (en) * | 2001-03-28 | 2015-08-04 | Qualcomm Incorporated | Method and apparatus for transmission framing in a wireless communication system |
| EP1374440B1 (en) * | 2001-03-28 | 2011-05-04 | Qualcomm Incorporated | Power control for point-to-multipoint services provided in communication systems |
| JP2003023421A (en) * | 2001-07-09 | 2003-01-24 | C4 Technology Inc | Encryption method, program thereof, recording medium recorded with the program, encryption device, decoding method, and decoder |
| US7577250B2 (en) | 2004-08-12 | 2009-08-18 | Cmla, Llc | Key derivation functions to enhance security |
| US8077861B2 (en) | 2004-08-12 | 2011-12-13 | Cmla, Llc | Permutation data transform to enhance security |
| US7564970B2 (en) * | 2004-08-12 | 2009-07-21 | Cmla, Llc | Exponential data transform to enhance security |
| US20040120527A1 (en) * | 2001-08-20 | 2004-06-24 | Hawkes Philip Michael | Method and apparatus for security in a data processing system |
| US7185362B2 (en) * | 2001-08-20 | 2007-02-27 | Qualcomm, Incorporated | Method and apparatus for security in a data processing system |
| US7697523B2 (en) * | 2001-10-03 | 2010-04-13 | Qualcomm Incorporated | Method and apparatus for data packet transport in a wireless communication system using an internet protocol |
| US7352868B2 (en) * | 2001-10-09 | 2008-04-01 | Philip Hawkes | Method and apparatus for security in a data processing system |
| US7649829B2 (en) | 2001-10-12 | 2010-01-19 | Qualcomm Incorporated | Method and system for reduction of decoding complexity in a communication system |
| US7093133B2 (en) * | 2001-12-20 | 2006-08-15 | Hewlett-Packard Development Company, L.P. | Group signature generation system using multiple primes |
| US7146009B2 (en) * | 2002-02-05 | 2006-12-05 | Surety, Llc | Secure electronic messaging system requiring key retrieval for deriving decryption keys |
| FR2836609A1 (en) * | 2002-02-25 | 2003-08-29 | Thomson Licensing Sa | Data transfer process for domestic digital network includes decoding and encoding using secrets specific to transmitting and receiving domains |
| US20040117618A1 (en) * | 2002-03-13 | 2004-06-17 | Kyoko Kawaguchi | Service execution module |
| US6711678B2 (en) * | 2002-04-05 | 2004-03-23 | Expand Beyond Corporation | Pre-authenticated communication within a secure computer network |
| TW576063B (en) * | 2002-07-10 | 2004-02-11 | Benq Corp | Device and method for securing information associated with a subscriber in a communication apparatus |
| US7599655B2 (en) * | 2003-01-02 | 2009-10-06 | Qualcomm Incorporated | Method and apparatus for broadcast services in a communication system |
| US9818136B1 (en) | 2003-02-05 | 2017-11-14 | Steven M. Hoffberg | System and method for determining contingent relevance |
| DE10305730B4 (en) * | 2003-02-12 | 2005-04-07 | Deutsche Post Ag | Method for verifying the validity of digital indicia |
| EP1460796A3 (en) * | 2003-03-17 | 2005-02-16 | Broadcom Corporation | Encryption-decryption key generation and distribution |
| US8098818B2 (en) * | 2003-07-07 | 2012-01-17 | Qualcomm Incorporated | Secure registration for a multicast-broadcast-multimedia system (MBMS) |
| US8718279B2 (en) * | 2003-07-08 | 2014-05-06 | Qualcomm Incorporated | Apparatus and method for a secure broadcast system |
| US8724803B2 (en) * | 2003-09-02 | 2014-05-13 | Qualcomm Incorporated | Method and apparatus for providing authenticated challenges for broadcast-multicast communications in a communication system |
| US8332652B2 (en) * | 2003-10-01 | 2012-12-11 | International Business Machines Corporation | Computing device that securely runs authorized software |
| US8396216B2 (en) * | 2003-11-21 | 2013-03-12 | Howard G. Pinder | Partial dual-encryption using program map tables |
| JP4570626B2 (en) * | 2004-05-03 | 2010-10-27 | リサーチ イン モーション リミテッド | System and method for generating reproducible session keys |
| US7548152B2 (en) * | 2004-10-08 | 2009-06-16 | Entrust Limited | RFID transponder information security methods systems and devices |
| US20060182277A1 (en) * | 2005-02-14 | 2006-08-17 | Tricipher, Inc. | Roaming utilizing an asymmetric key pair |
| US20060182283A1 (en) * | 2005-02-14 | 2006-08-17 | Tricipher, Inc. | Architecture for asymmetric crypto-key storage |
| WO2006078572A2 (en) * | 2005-01-18 | 2006-07-27 | Tricipher, Inc. | Asymmetric crypto-graphy with rolling key security |
| US8874477B2 (en) | 2005-10-04 | 2014-10-28 | Steven Mark Hoffberg | Multifactorial optimization system and method |
| US8095960B2 (en) * | 2005-11-21 | 2012-01-10 | Novell, Inc. | Secure synchronization and sharing of secrets |
| US8135645B2 (en) * | 2005-12-06 | 2012-03-13 | Microsoft Corporation | Key distribution for secure messaging |
| US7499552B2 (en) * | 2006-01-11 | 2009-03-03 | International Business Machines Corporation | Cipher method and system for verifying a decryption of an encrypted user data key |
| US8670564B1 (en) * | 2006-08-14 | 2014-03-11 | Key Holdings, LLC | Data encryption system and method |
| US20090097657A1 (en) * | 2007-10-05 | 2009-04-16 | Scheidt Edward M | Constructive Channel Key |
| US8376381B2 (en) | 2008-12-01 | 2013-02-19 | Commonwheel Ventures, Inc. | Versatile, collapsible cart-trailer with modular components |
| US9846789B2 (en) | 2011-09-06 | 2017-12-19 | International Business Machines Corporation | Protecting application programs from malicious software or malware |
| US9298894B2 (en) * | 2009-06-26 | 2016-03-29 | International Business Machines Corporation | Cache structure for a computer system providing support for secure objects |
| US8819446B2 (en) * | 2009-06-26 | 2014-08-26 | International Business Machines Corporation | Support for secure objects in a computer system |
| US8578175B2 (en) | 2011-02-23 | 2013-11-05 | International Business Machines Corporation | Secure object having protected region, integrity tree, and unprotected region |
| US8954752B2 (en) | 2011-02-23 | 2015-02-10 | International Business Machines Corporation | Building and distributing secure object software |
| US9954875B2 (en) | 2009-06-26 | 2018-04-24 | International Business Machines Corporation | Protecting from unintentional malware download |
| US8397281B2 (en) * | 2009-12-30 | 2013-03-12 | Symantec Corporation | Service assisted secret provisioning |
| US9026805B2 (en) | 2010-12-30 | 2015-05-05 | Microsoft Technology Licensing, Llc | Key management using trusted platform modules |
| US9864853B2 (en) | 2011-02-23 | 2018-01-09 | International Business Machines Corporation | Enhanced security mechanism for authentication of users of a system |
| US20120250865A1 (en) * | 2011-03-23 | 2012-10-04 | Selerity, Inc | Securely enabling access to information over a network across multiple protocols |
| EP2700189B1 (en) * | 2011-04-01 | 2020-01-22 | BlackBerry Limited | Identity-based decryption |
| US9172529B2 (en) * | 2011-09-16 | 2015-10-27 | Certicom Corp. | Hybrid encryption schemes |
| BR112014007061A2 (en) | 2011-09-28 | 2017-03-28 | Koninklijke Philips Nv | cryptographic system, method of generating a user secret key for use in a hierarchical attribute-based cryptographic system, decryption method of a ciphertext for use in a hierarchical attribute-based cryptographic system, method of encrypting a message for use in a hierarchical attribute-based cryptographic system, and, computer program |
| US9008316B2 (en) * | 2012-03-29 | 2015-04-14 | Microsoft Technology Licensing, Llc | Role-based distributed key management |
| EP2785010A1 (en) | 2013-03-28 | 2014-10-01 | Astrium Limited | Key distribution in a satellite system |
| JP6373261B2 (en) | 2013-04-18 | 2018-08-15 | 岡本硝子株式会社 | Underwater video camera housing |
| US9223965B2 (en) | 2013-12-10 | 2015-12-29 | International Business Machines Corporation | Secure generation and management of a virtual card on a mobile device |
| US9235692B2 (en) | 2013-12-13 | 2016-01-12 | International Business Machines Corporation | Secure application debugging |
| US10002512B2 (en) | 2014-01-30 | 2018-06-19 | Le-Jun Yin | System and method for object entry and egress control in a predefined area |
| US11200560B2 (en) | 2014-12-19 | 2021-12-14 | Capital One Services, Llc | Systems and methods for contactless and secure data transfer |
| US20160292445A1 (en) | 2015-03-31 | 2016-10-06 | Secude Ag | Context-based data classification |
| JP6419660B2 (en) | 2015-07-29 | 2018-11-07 | 株式会社日立製作所 | Secret information setting method, secret information setting system, and secret information setting device |
| EP3196798A1 (en) | 2016-01-19 | 2017-07-26 | Secude AG | Context-sensitive copy and paste block |
| US10484379B2 (en) * | 2017-03-16 | 2019-11-19 | Motorola Solutions, Inc. | System and method for providing least privilege access in a microservices architecture |
| US10944733B2 (en) | 2017-07-31 | 2021-03-09 | Cisco Technology, Inc. | Dynamic disassociated channel encryption key distribution |
| CN107590748B (en) * | 2017-08-17 | 2020-07-10 | 天津大学 | Full-dimensional observation method for security domain of power distribution network |
| US11115395B2 (en) | 2019-07-23 | 2021-09-07 | Harris Global Communications, Inc. | Cross-domain information transfer system and associated methods |
| US20220382851A1 (en) * | 2019-11-06 | 2022-12-01 | Washington University | Public key encryption using self powered timers |
| US11372986B1 (en) * | 2021-01-18 | 2022-06-28 | Axiom Technologies LLC | Systems and methods for encrypted content management |
| RU2766319C1 (en) * | 2021-03-24 | 2022-03-15 | федеральное государственное казенное военное образовательное учреждение высшего образования "Военная орденов Жукова и Ленина Краснознаменная академия связи имени Маршала Советского Союза С.М. Буденного" Министерства обороны Российской Федерации | Method for generating the encryption/decryption key |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4200770A (en) * | 1977-09-06 | 1980-04-29 | Stanford University | Cryptographic apparatus and method |
| US4405829A (en) * | 1977-12-14 | 1983-09-20 | Massachusetts Institute Of Technology | Cryptographic communications system and method |
| NL8301458A (en) * | 1983-04-26 | 1984-11-16 | Philips Nv | METHOD FOR DISTRIBUTING AND USING ENCRYPTION KEYS. |
| US4888801A (en) * | 1988-05-02 | 1989-12-19 | Motorola, Inc. | Hierarchical key management system |
| US4864615A (en) * | 1988-05-27 | 1989-09-05 | General Instrument Corporation | Reproduction of secure keys by using distributed key generation data |
| JP3080382B2 (en) * | 1990-02-21 | 2000-08-28 | 株式会社日立製作所 | Cryptographic communication system |
| GB9104909D0 (en) * | 1991-03-08 | 1991-04-24 | Int Computers Ltd | Access control in a distributed computer system |
| US5200999A (en) * | 1991-09-27 | 1993-04-06 | International Business Machines Corporation | Public key cryptosystem key management based on control vectors |
| US5241599A (en) * | 1991-10-02 | 1993-08-31 | At&T Bell Laboratories | Cryptographic protocol for secure communications |
| US5265164A (en) * | 1991-10-31 | 1993-11-23 | International Business Machines Corporation | Cryptographic facility environment backup/restore and replication in a public key cryptosystem |
| US5315658B1 (en) * | 1992-04-20 | 1995-09-12 | Silvio Micali | Fair cryptosystems and methods of use |
| US5276737B1 (en) * | 1992-04-20 | 1995-09-12 | Silvio Micali | Fair cryptosystems and methods of use |
| US5341426A (en) * | 1992-12-15 | 1994-08-23 | Motorola, Inc. | Cryptographic key management apparatus and method |
-
1994
- 1994-04-15 US US08/227,871 patent/US5481613A/en not_active Expired - Fee Related
-
1995
- 1995-02-22 EP EP95908852A patent/EP0755598B1/en not_active Expired - Lifetime
- 1995-02-22 CA CA002187035A patent/CA2187035C/en not_active Expired - Lifetime
- 1995-02-22 WO PCT/CA1995/000084 patent/WO1995028784A1/en active IP Right Grant
- 1995-02-22 JP JP7526587A patent/JP3060071B2/en not_active Expired - Fee Related
- 1995-02-22 DE DE69504823T patent/DE69504823T2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US5481613A (en) | 1996-01-02 |
| DE69504823D1 (en) | 1998-10-22 |
| JP3060071B2 (en) | 2000-07-04 |
| EP0755598A1 (en) | 1997-01-29 |
| CA2187035A1 (en) | 1995-10-26 |
| EP0755598B1 (en) | 1998-09-16 |
| DE69504823T2 (en) | 1999-02-11 |
| JPH09505711A (en) | 1997-06-03 |
| WO1995028784A1 (en) | 1995-10-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2187035C (en) | Computer network cryptographic key distribution system | |
| US5748735A (en) | Securing E-mail communications and encrypted file storage using yaksha split private key asymmetric cryptography | |
| US5588061A (en) | System and method for identity verification, forming joint signatures and session key agreement in an RSA public cryptosystem | |
| US7860243B2 (en) | Public key encryption for groups | |
| US5838792A (en) | Computer system for centralized session key distribution, privacy enhanced messaging and information distribution using a split private key public cryptosystem | |
| US5535276A (en) | Yaksha, an improved system and method for securing communications using split private key asymmetric cryptography | |
| US5557678A (en) | System and method for centralized session key distribution, privacy enhanced messaging and information distribution using a split private key public cryptosystem | |
| US6694025B1 (en) | Method and apparatus for secure distribution of public/private key pairs | |
| EP0725512B1 (en) | Data communication system using public keys | |
| US5737419A (en) | Computer system for securing communications using split private key asymmetric cryptography | |
| US6092201A (en) | Method and apparatus for extending secure communication operations via a shared list | |
| US7069435B2 (en) | System and method for authentication in a crypto-system utilizing symmetric and asymmetric crypto-keys | |
| US6192130B1 (en) | Information security subscriber trust authority transfer system with private key history transfer | |
| US7366905B2 (en) | Method and system for user generated keys and certificates | |
| US5905799A (en) | Programmed computer for identity verification, forming joint signatures and session key agreement in an RSA public cryptosystem | |
| US7499551B1 (en) | Public key infrastructure utilizing master key encryption | |
| US20030115452A1 (en) | One time password entry to access multiple network sites | |
| EP1605625A2 (en) | A method and system for authorizing generation of asymmetric crypto-keys | |
| WO1995027355A1 (en) | Electronic proof of receipt | |
| EP1079565A2 (en) | Method of securely establishing a secure communication link via an unsecured communication network | |
| US8161565B1 (en) | Key release systems, components and methods | |
| Prabhu et al. | Security in computer networks and distributed systems | |
| EP1101319A1 (en) | Method and apparatus for secure creation of public/private key pairs | |
| Fumy | Key management techniques | |
| JPH09130376A (en) | User password authentication method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20150223 |