GB2401007A

GB2401007A - Cryptographic method and apparatus

Info

Publication number: GB2401007A
Application number: GB0309162A
Authority: GB
Inventors: Liqun Chen; Martin Sadler; Keith Alexander Harrison
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 2003-04-23
Filing date: 2003-04-23
Publication date: 2004-10-27
Also published as: GB0311723D0; GB0309162D0

Abstract

First data to be sent by a first party (20) to a second party (30) is encrypted using an encryption key that comprises a hash value of the first data, this hash value being either in clear or in an encrypted form enabling its recovery in clear by a trusted party (40). The encrypted first data and the encryption key is made available to the second party (20) which forwards the encryption key to the trusted party (40) with a request for the corresponding decryption key. The trusted party (40) carries out at least one check on the basis of data contained in the encryption key and, if this at least one check is satisfactory, provides a decryption key to the second party. Where the encryption key comprises the hash value of the first data in encrypted form, the trusted party (40) will typically decrypt the hash value and pass it to the second party (30) to enable the latter to check the integrity of the first data after decryption with the decryption key.

Description

240 007 Cryptographic Method and Apparatus

Field of the Invention

The present invention relates to cryptographic methods and apparatuses and, in particular, but not exclusively, to such methods and apparatuses that use Identifier-Based Encryption.

Background of the Invention

Identifier-Based Encryption (IBE) is an emerging cryptographic schema. In this schema (see Figure 1 ofthe accompanying drawings), a data provider 10 encrypts payload data 13 using an encryption key string 14 and public data 15 provided by a trusted authority! 2; the data provider 10 then provides the encrypted payload data <13> to a recipient 11 who decrypts it using a decryption key 16 provided by the trusted authority together with the latter's public data. The trusted authority's public data is derived by the authority using private data 17 and a one-way function 18. Important features of the IBE schema are that any kind of string (including a name, a role, etc.) can be used as an encryption key string 14, and that the generation of the decryption key 16 is effected by the trusted authority (process 19) using the encryption key string 14 and its private data 17, enabling the generation of the decryption key 16 to be postponed until needed for decryption.

A number of IBE algorithms are known, one of which is the "Quadratic Residuosity" (QR) method described in the paper: C. Cocks, "An identity based encryption scheme based on quadratic residues", Proceedings ofthe 8'h IMA International Conference on Cryptography and Coding, LNCS 2260, pp 360-363, Springer-Verlag, 2001. A brief description of this form of IBE is given below.

In the QR method, the trusted authority's public data 15 comprises a value N that is a product of two random prime numbers p and q, where the values of p and q are the private data 17 of the trusted authority 12. The values of p and q should ideally be in the range of 25i and 2s'2 and should both satisfy the equation: p, q - 3 mod 4. However, p and q must not have the same value. Also provided is a hash function # which when applied to a string returns a value in the range O to N- 1.

Each bit m of the user's payload data 13 is then encrypted as follows: The data provider 10 generates random numbers t+ (where t+ is an integer in the range [0, 2N]) until a value of t+ is found that satisfies the equationjacobi(t+,N)=m, where m has a value of -1 or 1 depending on whether the corresponding bit of the user's data is O or 1 respectively. (As is well known, the jacobi function is such that where x2 _#modN the Jacobi (#, N) = -1 if x does not exist, and = 1 if x does exist). The data provider 10 then computes the value: s± (t++#(encryption_keystring) /t+)modN where s+ corresponds to the encrypted value of the bit m concerned.

- Since #(encryption_keystring) may be non-square, the data provider additionally generates additional random numbers t (integers in the range [0, 2N)) until one is found that satisfies the equation jacobi(t,NiFm. The data provider 10 then computes the value: s _ (t #(encryption_keystring)/t)modN as the encrypted value of the bit m concerned.

The encrypted values s+ and s for each bit m of the user's data are then made available to the intended recipient 11, for example via e-mail or by being placed in a electronic public area; the identity ofthe trusted authority 12 and the encryption key string 14 will generally also be made available in the same way.

The encryption key string 14 is passed to the trusted authority 12 by any suitable means; for example, the recipient 1 1 may pass it to the trusted authority or some other route is used - indeed, the trusted authority may have initially provided the decryption key string. The trusted authority 12 determines the associated private key B by solving the equation: B2 _ #(encryption_keystring)modN ("positive" solution) If a value of B does not exist, then there is a value of B that is satisfied by the equation: B2 _ - #(encryption_keystring)modN ("negative" solution) As N is a product of two prime numbers p, q it would be extremely difficult for any one to calculate the decryption key B with only knowledge of the encryption key string and N. However, as the trusted authority 12 has knowledge of p and q (i.e. two prime numbers) it is relatively straightforward for the trusted authority 12 to calculate B. s Any change to the encryption key string 14 will result in a decryption key 16 that will not decrypt the payload data 13 correctly. Therefore, the intended recipient 11 cannot alter the encryption key string before supplying it to the trusted authority 12.

The trusted authority 12 sends the decryption key to the data recipient l l along with an indication of whether this is the 'positive" or "negative" solution for B. If the 'positive" solution for the decryption key has been provided, the recipient 11 can now recover each bit m of the payload data 13 using: m = Jacobi(s++2B,N) If the "negative" solution for the decryption key B has been provided, the recipient 11 recovers each bit m using: m= jacobi(s +2B,N) Other IBE algorithms are known such as the use of Well or Tate pairings - see, for example: D. Boneh, M. Franklin"Identity-based Encryption from the Well Pairing" in Advances ir' Cryptology - CRYPTO 2001, LNCS 2139, pp. 213-229, Springer-Verlag, 2001.

One application of IBE encryption is to enable the data provider 10 to provide encrypted payload data over an unprotected communications path for receipt and decryption by a recipient 11 that meets certain conditions, namely condition 1 and condition 2. These conditions serve to identify the intended recipient and can therefore be considered as the recipient's identifiers. To ensure that only recipients that match the identifiers can read the payload data 13, the conditions are placed in the IBE encryption key string 14 and sent along with the encrypted payload data. Upon receipt, the data receiver 11 passes the encryption key string to the trusted authority 12 with a request for the corresponding IBE decryption key 16. The trusted authority 12 only provides the decryption key (over a secure channel) if satisfied that the conditions l and 2 included in the encryption key are met by the requesting data receiver 11.

The foregoing example exhibits a number of potential drawbacks. More particularly, the conditions (the identifiers of the intended data receiver) are transmitted in clear which may be undesirable. Furthermore, there is no sender authentication check enabling the recipient to reliable know who sent the message, nor any integrity check for the payload data; of course, these latter drawback could be overcome by the use of digital signatures and public key certificates based on RSA asymmetric key cryptography but this involves substantial additional cryptographic processing by the data receiver and a public key infrastructure (PKI) for supporting the use of public key certificates.

It is an object of the present invention to obviate one or more of the following drawbacks with no or minimal additional cryptographic processing by the data receiver.

Summary of the Invention

According to one aspect of the present invention, there is provided a data encryption method comprising encrypting first data using both: - an encryption key comprising, in clear or in encrypted form, a first- data hash value generated by hashing the first data; and - public data provided by a trusted party and derived thereby using private data.

According to a further aspect of the present invention, there is provided a data transfer method comprising: - encrypting first data at a first party using an encryption method according to the preceding paragraph and sending the encrypted first data and the encryption key to a second party; - providing the encryption key from the second party to the trusted party; - at the trusted party, carrying out at least one check on the basis of data contained in the encryption key and, if said at least one check is satisfactory, providing a decryption key to the second party, this decryption key being generated by the trusted party using the encryption key and its private data.

By forming the encryption key using the hash of the first data, the encryption key is intimately linked to the first data. Where the encryption key comprises the hash value of the first data in encrypted form, the trusted party will typically decrypt the hash value and pass it to the second party to enable the latter to check the integrity of the first data after decryption with the decryption key.

The present invention also envisages apparatus for carrying out the encryption method of the invention, and apparatus for carrying out the actions of the trusted party according to the data transfer method of the invention. The present invention further envisages a computer program product for conditioning programmable apparatus for carrying out the encryption method of the invention, and a computer program product for conditioning programmable apparatus for carrying out the actions of the trusted party according to the data transfer method of the invention.

Brief Description of the Drawings

Embodiments of the invention will now be described, by way of nonlimiting example, with reference to the accompanying diagrammatic drawings, in which: Figure 1 is a diagram illustrating the operation of a prior art encryption schema known as Identifier-Based Encryption; Figure 2 is a diagram of a system embodying the present invention; and Figure 3 is a flow chart of a process carried out by a trusted authority of the Figure 2 system.

Best Mode of Carrying Out the Invention Figure 2 illustrates a system embodying the present invention, the system comprising a first computing entity 20 associated with a data provider party; a second computing entity 30 associated with a data receiver party; and a third computing entity 40 associated with a trusted authority. The computing entities 20, 30 and 40 are typically based around general- purpose processors executing stored programs but may include dedicated cryptographic hardware modules. The computing entities 2O,30 and 40 inter- communicate as needed (see arrows 50-53) via, for example, the internet or other network, though it is also possible that at least some of the entities actually reside on the same computing platform.

In the following, references to the data provider, data receiver and the trusted authority are generally used interchangeablywith references to their respective computing entities 20,30 and 40.

In functional terms, the data-provider entity 20 comprises a communications module 24 for communicating with the entities 30 and 40, a control module 21 for controlling the general operation of the entity 20, and a cryptographic module 22 for executing certain cryptographic functions comprising a hash function and an IBE encryption function.

The data-receiver entity 30 comprises a communications module 34 for communicating with the entities 20 and 40, a control module 31 for controlling the general operation of the entity 30, and a cryptographic module 32 for executing certain cryptographic functions comprising a hash function (the same as that used by the entity 20) and an IBE decryption function.

The trusted authority entity 40 comprises a communications module 48 for communicating with the entities 20 and 30, a control module 41 for controlling the general operation of the entity 40, a cryptographic module 42 for executing certain cryptographic functions, a condition checking module 43, and a user registration module 44. The cryptographic module 42 is arranged to implement both a hash function (the same as that used by the entity 20) and an IBE decryption function; in addition, the module 42 includes a unit 45 for generating an IBE decryption key using both a supplied encryption key and private data securely held in local store 46.

The system employs Identifier-Based Encryption with the computing entities 20,30 and 40 having, in respect of IBE encryption/decryption, the roles of the data provider 10, data recipient 11 and trusted authority 12 of the Figure 1 IBE arrangement. The IBE algorithm used is, for example, the QR algorithm described above with respect to Figure 1 with the private data held in store 46 being random prime numbersp,q and the corresponding public data being number N. Consider the situation where the data provider 20 wishes to encrypt message data ("msg") for sending over an unprotected communications path for receipt and decryption by a recipient that meets certain conditions, namely Condition 1 and Condition 2. These Conditions 1 and 2 are unknown to the data receiver 30 and the data provider 20 wishes to keep Condition 2 confidential from the data receiver 30.

It is assumed that the data provider 20 has previously registered with the trusted authority and obtained (see arrow 50) a public / private key pair K20pUb,c / K20pnVae where K20pUb,c is simply a public identifier of provider 20 (such as a name) and K20pr,Vae is the IBE decryption key formed by the trusted authority using the K20pUb',c as an IBE encryption key and its private data p,q. The user registration module 44 is responsible at the time of registration for ensuring that the public key K20pUb,c is a correct identifier of the data provider 20; the module 44 is also arranged to keep a record of currently valid registered users.

To encrypt the message data msg. the data provider 20 first forms an IBE encryption key KENC comprising: K20PUblIC :: Condition 1 :: H(K20pr,Vae:: H(msg) :: nonce:: Condition 1:: Condition 2) :: E(K20pUb,c, N.; (H(msg) :: nonce:: Condition 2)) where: - :: means concatenation, - H(x) means the hash of data x using any suitable hash function such as SHA1, - E(k,n;y) means the IBE encryption of data y using encryption key k and the public data n of a trusted authority, and - a nonce is a one-time use random number selected by the data provider 20 and provided for freshness.

The process of forming the encryption key KENC is carried out by the cryptographic module 22 under the direction of the control module 21.

As can be seen, whilst Condition 1 is visible in the encryption KENC, the Condition 2 only appears in encrypted form. Furthermore, the encryption key KENC includes a hash of the message data msg. and a hashed quantity that includes both the data-provider's private key K20pr,Va,e and the message data hash; as will be seen hereinafter, this enables the trusted authority 40 to check the origin of the encryption key KENC and the integrity of the message hash.

After the key KENC has been generated, the control module 21 causes the cryptographic module 22 to use the key and the trusted authority's public data N to encrypt the message data msg. The encrypted data and the encryption key KENC are then made available by the communications module 24 to the data receiver 30 (see arrow 51).

On receiving the encrypted message data and the encryption key KENC, the control module 31 of the data receiver 30 may, if it understands the structure of the encryption key, examine the identity K20pUb,c of the data provider 20 and the unencrypted Condition 1. If the data receiver determines that it wants to read the message data and that it meets Condition 1, or if the data receiver decides to proceed without checking Condition 1 (for example, because it does not know the structure ofthe encryption key), the control module 31 causes the encryption key KENC to be sent (arrow 52) to the trusted authority 40 with a request for the corresponding decryption key KDEC.

On receipt ofthe request from the data receiver 30 for the decryption key KDEC, the control module 41 of the trusted authority 40 oversees the processing represented by the flow chart of Figure 3. More particularly, the control module 41 first parses (step 61) the encryption key KENC provided with the request into its four constituent components (the four concatenated components listed above) - this typically being done on the basis of predetermined separators inserted between the concatenated components.

Next, the control module 41 passes the component formed by the data provider's public key K20pUb,c to the module 44 in order to determine whether the data provider 20 is still a valid registered user ofthe services ofthe trusted authority40 (step 62). If this check fails, a negative response is returned to the requesting data receiver 30 (step 72) and processing terminates; otherwise processing proceeds. In fact, the trusted authority 40 may decide to skip this check and simply proceed directly to the following processing steps.

The next processing step (step 63) involves the control module 41 passing the Condition 1 component extracted from the encryption key KENC to the condition checking module 43 for it to determine whether the data receiver 30 satisfies this condition. Condition checking may involve the consultation of internal and/or external databases and/or the interrogation of the data receiver 30 (for which purpose the latter may be implemented on a trusted computing platform). If this check fails, a negative response is returned to the requesting data receiver 30 (step 72) and processing terminates; otherwise processing proceeds.

The following step (step 64) involves the control module 41 obtaining the data provider's private key K20pr,vae Whilst this key could have been stored in the user registration module 44 and retrieved against the data provider's public key K20pUb',c (as extracted from the encryption key KENC), it is simpler to have the key generation unit 45 regenerate the K20pr,Vac using the data provider's public key K20pUb,c and the private data p,q held in storage 46.

Once the private key K20pr'Vae has been obtained, it is used (step 65) to decrypt the encrypted component of the encryption key KENC in order to reveal: H(msg) :: nonce:: Condition 2 this expression thereafter being separated into its three constituent elements.

Next, the control module 41 passes the now-decrypted Condition 2 to the condition checking module 43 for it to determine whether the data receiver 30 satisfies this condition (step 66). If this check fails, a negative response is returned to the requesting data receiver (step 72) and processing terminates; otherwise processing proceeds.

Following the successful check of Condition 2, the control module 41 causes the hash: H(K20pr'Vae:: H(msg) :: nonce:: Condition 1:: Condition 2) to be recomputed (step 67) using the key K20pnVae obtained in step 64, the values of H(msg), the nonce and Condition 2 obtained by the decryption in step 65 of the encrypted data contained in KENC, and the Condition 1 obtained in step 61 from parsing KENC This re-computed hash value is then compared (step 68) with the corresponding component contained in the encryption KENC If these hash values are different then clearly something is wrong and a negative response is returned to the requesting data receiver 30 (step 72) and processing terminates.

However, if the hash values match, the trusted authority 40 accepts that the data provider is the entity associated with the private key K20pr, varc and thus with the public key K20PUbI,C; the trusted authority also accepts that the message hash H(msg) is reliable. The control module 41 now causes the key generation unit 45 to compute (step 69) the decryption key KDEC using the encryption key KENC and the private data p,q. Finally, the trusted authority returns (step 70) the decryption key KDEC together with H(msg) to the data receiver 30 (see arrow 53, Figure 2).

It will be appreciated that the ordering of the checking steps 62, 63, 66 and 68 relative to each other and to the other steps of the Figure 3 is not critical (subject to the items concerned having become available) save that the steps 62, 63, 66 and 68 need to be carried out before the decryption key KDEC is sent to the data receiver in step 70.

On receiving the decryption key KDEC the data receiver 30 uses it to decrypt the encrypted message data after which it computes the hash of the message and compares it with that received from the trusted authority 40 as a final check on the message integrity. The data receiver 30 now has the integrity-checked decrypted message and can be sure that the trusted authority 40 is happy that the data provider 20 is as identified by the public key K20PUb1,C included in clear in the encryption key KENC.

In the foregoing process, the only additional burden placed on the data receiver 30 is the message integrity check involving forming a hash ofthe message and comparing it with the message hash supplied by the trusted authority 40; otherwise, the functioning of the data receiver 30 is exactly as for any basic IBE system with the data receiver 30 passing the encryption key KENC to the trusted authority 40 and receiving back the decryption key KDEC. If the data receiver is prepared to pass the encrypted message to the trusted authority, then even the message integrity check can be carried out by the trusted authority.

The process described above with respect to Figures 2 and 3 not only provides the advantages of data-provider authentication carried out by the trusted authority 4O, and a check on the integrity ofthe message hash, but also enables the data provider 20 to include a hidden condition (Condition 2 in the example) in the encryption key KENC only visible to the trusted authority 40 and not to the data receiver 30. Whilst the data provider 20 must, of course, know how to form the multi-component encryption key KENC, the data receiver 30 need know nothing of the structure of this key, it being relieved of this burden by the trusted authority 40. Placing all the provider authentication and message integrity components into the encryption key KENC intimately ties these components to the encrypted message data.

Many variants are possible to the above-described embodiment. For example, instead of the QR IBE method being used for the encrypting and decrypting the message data msg.

other, analogous, cryptographic methods can be used such as IBE methods based on Well or Tate pairings.

In the above-described embodiment, the dataprovider's public key K2opub'c is used in clear in the encryption key KENC to identify the data provider and to encrypt the encrypted component of the encryption key KF.NC, whilst the corresponding private key K20pr,Vae is used as an authenticator of the identity of the data provider by its inclusion in the hashed component of the encryption key KENC. Although in the above embodiment this public / private key pair K20pUb',c / K20pr,Vae is an IBE encryption/decryption key pair, this need not be the case and the public/private key pair could, for example, be an RSA public/private key pair. In this case, the private key used to authenticate the data provider 20 cannot be computed in step 64 and must be accessed by look up in a database kept by the user registration module 44 relating private key to the data-provider identifier, such as the public key, included in clear in the encryption key KENC. A potential drawback of using an RSA public/private key pair is that if the public key is used as the in-clear data-provider identifier included in the encryption key KENC, the real- world identity of the data provider may not be apparent to the data receiver and will generally need translation. In fact, the in- clear data-provider identifier included in the encryption key KENC need not be the public key of the public/private key pair (whether IBE or RSA based) but can be any valid identity for the data provider that is known and accepted by the trusted authority as corresponding to the private key it holds for the data provider 20.

It is also possible to use a symmetric key known only to the data provider and the trusted authority to form the encrypted component ofthe encryption key KENc and for inclusion in the hashed component in place of K20pr,Vae. In this case, the in-clear identifier of the data provider that is included in the encryption key KENC would not, of course, be this key but would be an identifier known by the trusted authority as associated with the data provider and thus with the symmetric key concerned.

It maybe noted that the key used for encrypting the encrypted component ofthe encryption key KENC need not be cryptographically related to the key used in the hashed component of KENC - all that is required is that the key used for encrypting the encrypted component of the encryption key KENC is confidential to the data provider 20 and the trusted authority 40 and is known by the latter to belong to the same party as the key used in the hashed component of the key KENC.

It may also be noted that where there are only a few users registered with the trusted authority, it would be possible to omit the first component K20pUb,c (or other in-clear identifier of the data provider 20) and simply arrange for the trusted authority 40 to try out the keys / key pairs of all registered users to see if the message came from a registered user.

If a key / key pair was found that both sensibly decrypted the encrypted component of KENC and gave rise to a computed hash matching the hashed component of KENC, the identity of the data provider can be considered as established and can be passed to the data receiver if the latter needed to know this identity.

As already indicated, the form of encryption key KENC described above with reference to Figures 2 and 3 serves at least three purposes besides encryption of the message data msg; more particularly, it provides for passing a condition in confidence to the trusted authority, for authentication of the data provider to the trusted authority, and for the transmission and checking of message integrity data (the message hash). However, where only one or two of these functions is required, the form of the encryption key KENC can be simplified.

Considering first the authentication of the data provider, this is achieved by including in the encryption key KENC a hash of a shared secret known to the data provider 20 and the trusted authority 40; in the illustrated embodiment this shared secret is the private key K20prVate but, as discussed, could be an RSA private key of the data provider or a symmetric key, or indeed any shared secret. The presence in the encryption key of the Conditions 1 and 2 is not relevant to this data- provider authentication function so that the example encryption key KENC given above can be reduced to: 1 5 K20publc :: H(K20pr'Vate:: H(msg) :: nonce) :: E(K2OpUbl,c, N; (H(msg) :: nonce)) As already noted, where there are only a few users registered with the trusted authority, the first component K20pUb,c can be omitted. Furthermore, the nonce could be omitted from both the encrypted and hashed components of KENC provided freshness was not required.

However, retention of the message hash H(msg) in both the hashed component and the encrypted (or, alternatively, in the in-clear) component of KENC iS necessary where it is desired to retain a link between the originator identity established for the encryption key KENC and a message encrypted with this key-removal ofthe message hash H(msg) would enable the encryption key KENC to be used by a third party for encrypting a message which might then appear to come from the data provider 20 in view of the latter's identity being embedded in the encryption key KENC. In fact, it is possible to envisage circumstances where the original ofthe encryption key KENC iS of a significance independent ofthe origin of a message encrypted with that key. For example, where the encryption key KENC includes one or more conditions in clear and/or in the encrypted component, then these may represent standard terms and conditions of a party which wishes to establish this fact independently of any message encrypted with the encryption key; in this case, the conditions (or a hash of the conditions) would need to be included in the hashed component of the encryption key to enable a check on their integrity. Where only non confidential conditions were involved, such as Condition 1, then the encryption key KENC K2opublc :: Condition 1 :: H(K20pr,Vae:: nonce:: Condition 1) :: E(K20pUb,c, N; nonce) If the nonce is not required, thenthe encrypted component can be omitted. The condition or conditions included in such an encryption key can be replaced, or supplemented, by other data not intended to be an identifier of the data receiver 30 such as data about the data provider 20. This other data can, like the conditions, be included in clear andlor in the encrypted component and should also be included, directly or after hashing, in the hashed component if it is to be linked to the originator identity established for the encryption key 1 5 KENC.

Rather than using an un-keyed hash function such as SHA1, it is possible to use a keyed hash such as HMAC with the private key K20pr,Vae (or other shared secret) being the hash key used for hashing the other element or concatenated elements ofthe hashed component.

In this case, the trusted authority would use the same keyed hash function in seeking to compute a hash value matching that in the encryption key KENC.

If the identity of the data provider is not an issue, then the encryption key KENC of the illustrated embodiment reduces to: K20publc :: Condition 1 :: H(H(msg) :: nonce:: Condition I:: Condition 2) :: E(K20pUb,c, N.; (H(msg) :: nonce:: Condition 2)) leaving only the elements forming the identifiers of the data receiver (Conditions I and 2) and those concerned with the message integrity (the in-clear component K20pUb,c is retained to facilitate the trusted authority obtaining the key K20prvae for decrypting the encrypted component, though as already discussed, in appropriate circumstances the component K20pUb,c can be omitted). If only message integrityis of interest (for example, if there are no conditions), then the hashed component of this reduced form ofthe encryption key KENC can be removed leaving: K20publc :: E(K2OpUbl,c, N; (H(msg) :: nonce)) In fact, since K20pUb,c is public, encrypting the message hash does not serve much purpose as anyone wishing to provide a substitute message for that originally sent can also change the message hash and encrypt it accordingly. However, if the message hash, with or without the addition of a nonce, is encrypted using a private key (whether of a public/private key pair or a secret symmetric key) the message hash is protected from change and serves its purpose of providing a message integrity check for the original message. Rather than using the private key to encrypt the message hash, it can be used to form a keyed hash, such as HMAC, ofthe message. The trusted authority can be arranged to determine the correct private key to use for checking either by trial and error through a limited set of such keys, or by the inclusion in the encryption key KENC of a suitable indicator in clear.

Whether the message hash is included in a protected form or another form (such as in clear or encrypted with a public key) in the encryption key KENC, its inclusion permits detection of non malicious changes in the encrypted message such as may result from problems in the communications path. At its simplest, inclusion of the message hash, in clear or in a derived form, into the encryption key KENC provides a link between the encryption key and the message giving rise to the included hash value. Whilst this does have utilitywithout the addition of further data into the encryption key, it is primarily of interest for associating such further data included in the key KENC with the message, this further data being, for example, identity information of the data provider and/or data receiver as has already described.

As regards the inclusion in the encryption key KENC of conditions serving to identify the data receiver, it will be appreciated that the number of in-clear and encrypted conditions can be varied from that described above for the illustrated embodiment. Thus, there maybe 16 i none, one or more in-clear conditions and none, one or more encrypted conditions, in any I combination. Furthermore, where the conditions are already known to the data receiver 30, the conditions need not be included as such in the encryption key KENC but they should still included in the hashed component to enable the trusted authority to confirm that the conditions passed to it by the data receiver correspond to those intended by the data provider and included in the hashed component. In this case, for the illustrated embodiment, the encryption key KENC reduces to: K20publc :: H(K20pr'Vae:: H(msg) :: nonce:: Condition 1) 10:: E(K20pUb,c, In; (H(msg) :: nonce)) there being no Condition 2 as this example only involves conditions known to the data receiver. If the data-provider identity information and message hash data are not required and the nonce is omitted, the encryption key KENC further reduces to: H(Condition 1) This is of value because it ensures that the data receiver can only read the encrypted message data supplied by the data provider if it presents, and satisfies, the correct condition 1 to the trusted authority. The data receiver cannot alter the hash value to match a different condition as this would result in a decryption key KDEC that would not serve to decrypt the received encrypted message data.

It may be noted that it is possible to achieve a similar result to that of the foregoing paragraph without using an IBE schema for the encryption and decryption keys KENC, KDEC. Consider a situation where the trusted authority has a secret key KT which it uses to generate a secret key Kp for the data provider 20 (the subscript "p" here standing for the data Provider): Kp = HMAC(KT, identifier of data provider) This enables the data provider 20 to generate a symmetric key KPR: KPR = HMAC(Kp, identifier of data receiver) where the identifier of the data receiver is the Condition 1. The key KPR is then used with a symmetric encryption algorithm to encrypt the message data which the data provider then sends, along with its identifier, to the data receiver. In order for the data receiver to obtain the key KPR for decrypting the message data, it must provide its identifier (Condition 1) and that of the data provider to the trusted authority who can now compute the key KPR as it already knows KP or can re-compute it; assuming that the data receiver meets the Condition 1, the trusted authority then returns the key KPR to the data receiver to enable the latter to decrypt the encrypted message data. If the data receiver supplies a modified Condition 1, the resultant key will not decrypt the encrypted message data. By also sending a hash ofthe key KPR, the data provider can provide assurance to the trusted authority that KPR has been created by the data provider.

With regard to the above-described reduced forms of the encryption key KENC, it will be understood by persons skilled in the art that the Figure 3 process carried out by the trusted authority is appropriately modified to omit any unnecessary computation or checks and to effect any changes needed to take account ofthe changed form ofthe encryption keyKENc.

It will also be understood by persons skilled in the art that where elements are concatenated before being operated upon by a hashing or encryption function, the order of concatenation can be varied from that described above provided that the ordering is used consistently (for example, the trusted authority 40,when computing the hash value in step 67 of Figure 3, must use the same ordering of the concatenated elements as used by the data provider 20 when generating the encryption key KENC)

Claims

1. A data encryption method comprising encrypting first data using both: an encryption key comprising, in clear or in encrypted form, a first- data hash value generated by hashing the first data; and - public data provided by a trusted party and derived thereby using private data.

2. A method according to claim 1, wherein said first-data hash value is generated using a keyed hash function with the key used by this function being a secret shared with the trusted party.

3. A method according to claim 1, wherein the encryption key comprises said first-data hash value encrypted using a secret key shared with the trusted party.

4. A method according to claim 1, wherein the encryption key comprises a first component formed by the said first-data hash value, and a second component comprising a further hash value generated by hashing third data comprising a concatenation of the first-data hash value and second data.

5. A method according to claim 1, wherein the encryption key comprises: a first component formed by encrypting a concatenation of said first- data hash value and second data using the public key of a public/private key pair the private key of which is available to the trusted party; and - a second component comprising a further hash value generated by hashing third data comprising a concatenation of the first-data hash value and the second data.

6. A method according to claim 4 or claim 5, wherein the second data comprises at least one condition serving as an identifier of an intended recipient of the first data.

7. A method according to claim 4, wherein the second data comprises at least one condition serving as an identifier of an intended recipient of the first data, the third data further comprising at least one further condition also serving as an identifier of an intended recipient of the first data, this at least one further condition being included in clear in the encryption key

8. A method according to claim 5, wherein the second data comprises a nonce.

9. A method according to any one of the preceding claims, wherein the encryption process effected using said encryption key and the public data of the trusted party is an identifier- based cryptographic process utilising quadratic residuosity.

10. A method according to any one of claims 1 to 8, wherein the encryption process effected using said encryption key and the public data of the trusted party is an identifier- based cryptographic process utilising Well or Tate pairings.

11. Apparatus for carrying out the encryption method of any one of claims 1 to 10.

12. A computer program product for conditioning programmable apparatus for carrying out the encryption method of any one of claims 1 to 10.

13. A data transfer method comprising: - encrypting first data at a first party using an encryption method according to any one of claims 1 to 10 and sending the encrypted first data and the encryption key to a second party; - providing the encryption key from the second party to the trusted party; - at the trusted party, carrying out at least one check on the basis of data contained in the encryption key and, if said at least one check is satisfactory, providing a decryption key to the second party, this decryption key being generated by the trusted party using the encryption key and its private data.

14. A method according to claim 13 when dependent on anyone of claims 4 to 7, wherein said at least one check comprises a check on the second component of the encryption key, this check comprising: - extracting the first-data hash value and the second data from the encryption key, including by effecting any required decryption, and re- forming the third data; - hashing the re-formed third data to compute a hash value; comparing the hash value computed by the trusted party with the further hash value constituted by the second component of the encryption key; the check being satisfactory if the compared values match.

15. A method according to claim 13 or 14, wherein the encryption key includes at least one said condition, the trusted party extracting said at least one condition from the encryption key including by effecting any required decryption; said at least one check comprising a check that the or each said at least one condition is met by the second party.

16. A method according to claim 14 when dependent on claim 6 or claim 7, wherein the encryption key includes at least one said condition which also forms an element of the second data, the trusted party extracting said at least one condition from the encryption key including by effecting any required decryption; the trusted party, as well as carrying out the check on the second component of the encryption key, also carrying out a said check to check that the or each said at least one condition is met by the second party.

17. A method according to claim 21 when dependent on claim 6, wherein the second data comprises at least one said condition that is not included as such in the encryption key, the second party passing the or each such condition to the trusted party; the trusted party carrying out the check on the second component of the encryption key with the or each said condition supplied by the second party being used in re-forming the third data, and the trusted party carrying out a further said check to check that the or each said at least one condition is met by the second party.

18. A method according to any one of claims 13 to 17, wherein said encryption key includes the hash of the first data in encrypted form, and wherein in the event said at least one check is satisfactory, the trusted party passes the decrypted hash of the first data to the second party along with the decryption key; the second party, after decrypting the first data, checking its integrity by calculating its hash and comparing this calculated value with that provided by the trusted party.

19. Trusted party apparatus for carrying out the trusted party actions ofthe method of any one of claims 13 to 18.

20. A computer program product for conditioning programmable apparatus for carrying out the trusted party actions of the method of any one of claims 13 to 18.