Patent Grant
7986778
The present invention relates to a cryptographic method and apparatus; in particular, the present invention relates to an identifier-based cryptographic method and apparatus. Preferred embodiments of the invention utilise the identifier-based (IB) cryptographic methods and apparatus described in our co-pending US patent applications:
As is well known to persons skilled in the art, in “identifier-based” cryptographic methods a public, cryptographically unconstrained, string is used in conjunction with public data of a trusted authority to carry out tasks such as data encryption or signing. The complementary tasks, such as decryption and signature verification, require the involvement of the trusted authority to carry out computation based on the public string and its own private data. In message-signing applications and frequently also in message encryption applications, the string serves to “identify” a party (the sender in signing applications, the intended recipient in encryption applications); this has given rise to the use of the label “identifier-based” or “identity-based” generally for these cryptographic methods. However, at least in certain encryption applications, the string may serve a different purpose to that of identifying the intended recipient and, indeed, may be an arbitrary string having no other purpose than to form the basis of the cryptographic processes. Accordingly, the use of the term “identifier-based” herein in relation to cryptographic methods and systems is to be understood simply as implying that the methods and systems are based on the use of a cryptographically unconstrained string whether or not the string serves to identify the intended recipient. Furthermore, as used herein the term “string” is simply intended to imply an ordered series of bits whether derived from a character string, a serialized image bit map, a digitized sound signal, or any other data source.
Identifier-Based Encryption (IBE) is an emerging cryptographic schema. A number of IBE cryptographic methods are known, including:
Generally, in IB encryption/decryption methods, a trusted party carries out one or more actions (such as identity checking) in accordance with information in the sender-chosen string, before enabling a recipient to recover a message encrypted by a message sender. Usually, the trusted party will generate an IB decryption key and provide it to the recipient for the latter to use in decrypting the encrypted message. However, it is also possible to provide IB encryption/decryption methods in which the trusted party carries out the decryption. This is the case for the RSA-based IB method described in U.S. Pat. No. 6,275,936 where the decryption exponent is dynamically computed from the encryption exponent, the latter being a hash of the sender-chosen string. A potential disadvantage of the trusted party carrying out message decryption is that it risks compromising the recipient's privacy. In the afore-mentioned US patent, this potential disadvantage is overcome by the recipient blinding the encrypted message before passing it to the trusted party (a decryption box) and then un-blinding the returned decrypted, but still blinded, message.
In many applications, it is not just the identity of the recipient that is required to be authenticated but also that of the message sender. Of course, there are a number of known ways of achieving sender authentication the most notable of which involves the message sender using a private key to sign the message; in this case, a recipient uses the corresponding public key to check the signature. However, this approach relies on the existence of a public key infrastructure usable by the recipient to assuredly relate the public key to a particular party.
Identifier-based signature methods are known such as those disclosed in ISO/IEC 14888-2, published 1999.
It is an object of the present invention to provide identifier-based cryptographic methods and apparatus with sender authentication.
According to a first aspect of the present invention, there is provided a cryptographic method comprising:
This enables the second trusted entity both to verify the first party's identity and to verify the compliance with the conditions in the second identifier string, before the second trusted party decrypts, or enables decryption of, the encrypted message. More particularly, extended to include the second trusted entity, the above method of the invention further comprises the second trusted entity:
According to another aspect of the present invention, there is provided apparatus for use in a cryptographic method in which a first trusted entity, with a first public/private key pair, provides a first party with a secret key, generated using the first private key and a first identifier string, after verifying that the first identifier string is associated with the first party; the apparatus being arranged to encrypt a message on behalf of the first party and comprising:
According to a further aspect of the present invention, there is provided Apparatus for use in a cryptographic method in which:
Embodiments of the invention will now be described, by way of non-limiting example, with reference to the accompanying diagrammatic drawings, in which:
The cryptographic methods and apparatus described below with respect to
The embodiment of the invention illustrated in
In addition to the identity of the receiver B being verified by T2, the identity of the sender A, as indicated by identifier string IDA, is verified by T1 and used to produce a private key kA for A. The sender A uses the key kA to create signature components that can be used by T2 to confirm that they originated from A as identified by the T1-verified identity IDA.
A more detailed description of the
Initial Set Up Phase
Message Transfer Phase
Steps 17 and 18 can be effected in any order or in parallel. Steps 19 to 23 are only carried out if the verification tests of steps 17 and 18 are successful alternatively, steps 18 to 22 can be carried out independently of steps 17 and 18 with steps 22 and 23 only being effected if the verification steps are successful. A further possibility is to have T2 securely pass the decryption key d to B rather than the decrypted message, it then being up to B to decrypt the message. Yet another possibility is for T2 to pass B the decrypted message or decryption key even if the identity of the sender cannot be verified (that is, even if the test in step 17 fails); in this situation, T2 would warn B that the source of the message is suspect. In all cases it can be seen that T2 controls the availability of a decrypted form of the encrypted message in dependence on the outcomes of the verifying tests.
It is also possible to arrange for the sender-identity verification test of step 17 to be carried out by the receiver B rather than by T2.
Integrity
The transmissions between the parties should be integrity protected in some manner, by which is meant that it should be possible for the receiving party to detect whether any of the data elements transmitted has been altered. In particular, the sender-authentication data elements should preferably be bound to the ciphertext c so that any substitution of the ciphertext can be detected.
Integrity protection can be effected in a number of ways. For example, a padding scheme can be used that enables integrity checking of the package of elements being transmitted; one suitable padding scheme is OAEP (M. Bellare and P. Rogaway. Optimal Asymmetric Encryption—How to Encrypt with RSA. In Advances in Cryptology-Eurocrypt '94, pp. 92-111, Springer-Verlag, 1994. Alternatively, the package of data elements can be wrapped by any suitable mechanism allowing integrity checking (such as a signature over the package). A further possibility is for A to form a hash of the message m and use it as all or part of the public data u that it signs with the secret key kA to generate the signature components s and t. The public data u is made available to B and therefore B can use it to check the integrity of the decrypted message m (or else T2 can do this). If the message is changed then either this integrity check will fail (because the message hash has been left unchanged) or the check carried out by T2 in step 17 will fail (because the message hash has been changed from that used in creating s).
Blinding
A potential drawback of the
T2 carries out its processing steps 17 to 22 as before but using c′ rather than c; the result of step 21 is now the recovery of m.v—that is, the blinded but decrypted message—rather than the message m. In order for B to un-blind the message, step 23 now becomes:
It will be appreciated that the blinding/un-blinding operations can differ from those described above. For example, blinding can be effected by computing a modulo-nT2 multiplication of c by v−e, in which case un-blinding would be effected by a modulo-nT2 multiplication by v of the decrypted, but still blinded, message returned by T2.
Another way of preventing T2 from reading the message m would be to use the above-referenced identity based mediated RSA method described by D. Boneh, X. Ding and G. Tsudik for effecting encryption/decryption of the message m; in this case, the division of the decryption key between B and T2 means that T2 is not able to fully decrypt the message.
Hiding the Sender's Identity
If the sender A does not want anyone else except for either T2 or B or both to be able to see A's identity and signature, then A has a number of options, including:
In all of these options, t can be transferred in a clear text and concatenation can be replaced by another reversible combination function.
Further Generalisations of Sender Authentication Process
Whilst the public data element u signed by sender A using the secret key kA can be any data available to A and T2, certain advantages can be obtained by suitable choice of the contents of u as has already been indicated above in relation to using the hash of the message m for u to enable integrity checking to be carried out. Generally, the public data element u provides a convenient way of linking the sender authentication data elements to the encryption/decryption process; the public data element u therefore preferably either comprises, or is related to, an element involved in the encryption/decryption process. Thus, for example, by using IDB for u as in the embodiment illustrated in
The data element hA signed by T1 using the secret key dA need not be a hash of IDA and can be any data known to both T1 and T2 so that T2 can carry out the step 17 check. The reason for this is that the key dA has been formed from IDA which thereby locks the identity of the sender into the key kA so that it is not essential that the data signed using dA is IDA.
Alternatively, where the data signed using dA does comprise IDA, then the key dA can be formed as the inverse of an element that is not IDA but some other data element such as a fixed small prime (provided it is known to, or made available to, T2).
It will be appreciated that IDA and kA form a public/private key pair for the sender A and that hA and dA effectively form a further public/private key pair for the trusted authority T2 (albeit of a transient nature in that it will generally only exist, so far as T1 is concerned, during creation of kA in respect of IDA).
The IB encryption/decryption process represented by blocks 75 and 76 can be any suitable IB process though preferably the computation operations involved are of the same type as used for the sender authentication process. As already discussed, the transmission of the encrypted message and of the signature components s and t is integrity protected. Other linkages may exist between the sender authentication process and the IB encryption/decryption process, such as the use of IDB both for the encryption key string in the IB encryption of message m and for the public data u.
It should also be noted that the sender identifier string IDA need not uniquely identify A and in general terms can be any set of one or more attributes that the sender A allegedly possesses, it being the responsibility of the trusted authority T1 to check whether or not this is so.
RSA Cryptographic Considerations
As is well known, in RSA methods the encryption exponent e must have no common factors with φT2. However, in the above-described embodiment the encryption exponent e is based on a string created by the sender rather than being generated by the trusted authority T2 to meet the requirement that e has no common factors with φT2. In order to meet this requirement, the following constraints, already noted above in relation to the
These constraints together serve to ensure, with a very high probability, that the encryption exponent e and φT2 will have no common factors. Other constraints for achieving the same objectives are also possible.
Furthermore, with RSA methods it is accepted that one should avoid encrypting the same message multiple times with different exponents that are coprime, since an attacker could then use the Extended Euclidean Algorithm to recover the original message. Various solutions are available:
More generally, successive values of e can be:
e=α(2(#(IDB))+1)
where α is an odd integer ≧3, this value being fixed (that is, for each new message to be encrypted, the same value of α is used in the calculation of the encryption exponent e). The hash function is chosen such that the value of e is large (generally>>1024) and preferably lies within the range 1 to (φT2−1).
Other Encryption/Decryption Methods
As an alternative to using an RSA-based IB encryption/decryption method for securely passing the message m to the party identified by the string IDB, other IB encryption/decryption methods can be used. For example, the above-mentioned IB method based on ElGamal encryption/decryption can be used. Below is given an example implementation of this method but only in respect of the encryption/decryption of the message m, it being understood that the authentication of the sender is carried out in the same way as described above with respect to
Initial Set Up Phase
Again, the transmissions are preferably integrity protected in any suitable manner.
It will be appreciated by persons skilled in the art that g should be chosen randomly but such that:
gq=1 mod p
where q is a large prime (typically at least 160 bits) that divides (p−1).
It should be noted that the multiplication effected in step 11 can be replaced by any modulo-p invertible operation for combining yr.z and m (the operation being inverted in step 16). Thus, for example, J can be computed as:
m⊕H(yr.z mod p)
where ⊕ is the Exclusive-OR function and H is a hash function. The message is subsequently recovered by T2 computing:
J⊕H(hx.z mod p).
It is possible to interpret the
The Identifier String IDB
As regards the contents of the recipient identifier string IDB chosen by the sender, as already indicated this string may be any string though in many cases restrictions will be placed on the string—for example, the string IDB may be required to comply with a particular XML schema.
The string IDB will frequently comprise a condition identifying a specific intended message recipient; in this case, the trusted authority T2 carries out (step 14 of
Rather than identifying an intended recipient as a particular individual, the string IDB may comprise one or more conditions specifying one or more non-identity attributes that the recipient must possess; for example, a condition may specify that a recipient must have a certain credit rating. Again, it is the responsibility of the trusted authority T2 to check out this condition(s) before producing the decrypted message for a party presenting the encrypted message for decryption.
The string IDB may additionally or alternatively comprise one or more conditions unrelated to an attribute of the intended recipient; for example, a condition may be included that the message concerned is not to be decrypted before a particular date or time. Indeed, the string IDB can be used to convey to the trusted authority T2 information concerning any actions to be taken by the trusted authority when it receives the encrypted message for decryption. The information in the string DB may thus relate to actions to be taken by the trusted authority that do not affect message decryption—for example, the trusted authority T2 may be required to send a message to the message sender A at the time the T2 decrypts the message concerned. However, as already indicated, the information in the string IDB will generally specify one or more conditions to be checked by the trusted authority as being satisfied before the trusted authority decrypts the related encrypted message (or before returning the corresponding decrypted message to the recipient B concerned).
Whatever the conditions relate to, the string IDB may directly set out the or each condition or may comprises one or more condition identifiers specifying corresponding predetermined condition known to the trusted authority (in the latter case, the trusted authority uses the or each condition identifier to look up the corresponding condition to be checked).
Multiple Decryption TAs
Many variants are possible to the above-described embodiments of the invention. Thus, in certain situations it may be required that a message should only be decryptable with the cooperation of multiple trusted authorities each of which would typically have a different associated public and private data. One such situation where this may be desirable is where the sender wishes to impose multiple conditions but no single trusted authority is competent to check all conditions—in this case, different trusted authorities can be used to check different conditions. Another situation in which multiple trusted authorities may be required is where there is a concern that a trust authority may have access to the encrypted, but not blinded, messages passing from A to B and it is important to prevent the trust authority reading the messages—in this case, multiple trusted authorities can be used together in a manner such that no one authority can read the messages passing from A to B.
Various arrangements are possible for involving multiple trusted authorities in message decryption, including:
Where multiple trusted authorities are involved in message decryption, sender authentication can be carried out by all such trusted authorities or only by a subset (including one) of these authorities.
It is also possible to arrange for the initial verification of sender identity to be carried out by more than one trusted authority, for example by arranging for each such trusted authority to generate a respective kA, each kA then being separately used by the sender to sign a public data element.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0414062.0 | Jun 2004 | GB | national |
| Number | Name | Date | Kind |
|---|---|---|---|
| 4351982 | Miller et al. | Sep 1982 | A |
| 4590470 | Koenig | May 1986 | A |
| 4748668 | Shamir et al. | May 1988 | A |
| 5150411 | Maurer | Sep 1992 | A |
| 5436972 | Fischer | Jul 1995 | A |
| 5910989 | Naccache | Jun 1999 | A |
| 6275936 | Kyojima et al. | Aug 2001 | B1 |
| 6332193 | Glass et al. | Dec 2001 | B1 |
| 20020103999 | Camnisch et al. | Aug 2002 | A1 |
| 20030955661 | Harrison | May 2003 | |
| 20040151310 | Fu et al. | Aug 2004 | A1 |
| 20040252830 | Chen et al. | Dec 2004 | A1 |
| 20050002528 | Chen et al. | Jan 2005 | A1 |
| 20050262353 | Gentry et al. | Nov 2005 | A1 |
| Number | Date | Country |
|---|---|---|
| 2 384 406 | Jul 2003 | GB |
| 2 395 872 | Jun 2004 | GB |
| 03017559 | Feb 2003 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20060013389 A1 | Jan 2006 | US |
