GB2401763A - Trusted Authority for Identifier-Based Cryptography - Google Patents

Abstract

A trusted authority (70) is provided for identifier-based cryptography using bilinear maps. The trusted authority has a secret (r) and derives first and second elements (QTA2,Y) at least the second of which it publishes. The first element (QTA2) is derived from an identifier ("TA2") associated with the trusted authority; the second element (Y) is a combination of the first element (QTA2) and the secret (r). The trusted authority (70) provides a private-key generation service involving the generation of a private key (rQBob) for a third party (80) in dependence on the secret (r) and an identifier string ("Bob") associated with that third party.

Description

240 1 763 Trusted Authority for Identifier-Based Cryptography

Field of the Invention

The present invention relates to a trusted authority for identifier-based cryptography using bilinear maps.

The present application is a divisional of our co-pending UK Application No. GB 0215590 filed 5 July 2002 which relates to a method and apparatus for enabling the verification, and/or for verifying, an association between first and second parties such as a lower-level trusted authority and a higher-level trusted authority in a hierarchy of trusted authorities.

Backeround of the Invention Embodiments of the present invention to be described hereinafter make use of cryptographic techniques using bilinear mappings. Accordingly, a brief description will

now be given of certain such prior art techniques.

In the present specification, Gil and G2 denote two algebraic groups of prime order q in which the discrete logarithm problem is believed to be hard and for which there exists a computable bilinear map A, for example, a Tate pairing t or Weil pairing e. Thus, for the Weil pairing: e:GIxGl G2 where G2 is a subgroup of a multiplicative group of a finite field. The Tate pairing can be similarly expressed though it is possible for it to be of asymmetric form: t:GxGo G2 where Go is a further algebraic group the elements of which are not restricted to being of order q. Generally, the elements of the groups Go and Gil are points on an elliptic curve though this is not necessarily the case.

As is well known to persons skilled in the art, for cryptographic purposes, a modified form of the Weil pairing is used that ensure p (P,P) =1 where P Gil; however, for convenience, the pairing is referred to below simply by its usual name without labeling it as modified. Further background regarding Well and Tate pairings and their cryptographic uses can be found in the following references: - G. Frey, M. Muller, and H. Ruck. The Tate pairing and the discrete logarithm applied to elliptic curve cryptosystems. IEEE Transactions on Information Theory, 45(5):1717-1719, 1999.

- D. Boneh and M. Franklin. Identity based encryption from the Well pairing. In Advances in Cryptology - CRYPTO 2001, LNCS 2139, pp.213-229, Springer-Verlag, 2001.

For convenience, the examples given below assume the use of a symmetric bilinear map (pa: Gil x Gil G2) with the elements of Gil being points on an elliptic curve; however, these particularities, are not to be taken as limitations on the scope ofthe present invention.

As the mapping between Go and G2 is bilinear exponents/multipliers can be moved around.

For example if a, h, c e Fq and P. Q e Gil then t(aP, hQ)c = t(aP, eQ)b = t(bP, cQ)a = t(bP, aQ)c = t(eP, aQ)b = t(eP, bQ)a = t(abP, Q)c = t(abP, eQ) = t(P, abQ)C = t(eP, abQ) = t(abeP, Q) = t(P, abeQ) = t(P, Q)abC Additionally, the following cryptographic hash functions are defined: Hi: {O,l}*G H2: {0,1}* Fq H3:G2 >{0,1} A normal public/private key pair can be defined for a trusted authority: the private key is s where s e Fq the public key is (P. R) where P e Gil and R e G1, with R=sP Additionally, an identifier based public key / private key pair can be defined for a party with the cooperation ofthe trusted authority. 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. Frequently, the string serves to "identify" the intended message recipient and this has given rise to the use of the label "identifier- based" or "identity-based" generally for these cryptographic methods. However, depending on the application to which such a cryptographic method is put, 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.

In the present case, the identifier-based public / private key pair defined for the party has a public key QID and private key SID where QLD, SID e Gil The trusted authority's normal public/private key pair (P,R / s) is linked with the identifier-based public/private key by SrD = SAD and QLD = HI (ID) where ID is the identifier string for the party.

Some typical uses for the above described key pairs will now be given with reference to Figure 1 ofthe accompanying drawings that depicts a trusted authority 10 with apublic key (P. sP) and a private key s. A party A serves as a general third party whilst for the identifier-based cryptographic tasks (IBC) described, a party B has an IBC public key QrD and an IBC private key SrD.

Standard Signatures (see dashed box ?): The holder of the private key s (that is, the trusted authority I or anyone to whom the latter has disclosed s) can use s to sign a bit string; more particularly, where m denotes a message to be signed, the holder of s computes: V = sH(m).

Verification by party A involves this party checking that the following equation is satisfied: t(P, V) =t(R, Ht(m)) This is based upon the mapping between Go and G2 being bilinear exponents/multipliers, as described above. That is to say, t(P, V) = t(P,sH(m)) =t(P, H(m)) = t(sP, H(m)) = t(R, H(m)) Identifier-Based Encryption (see dashed box 3):- Identifier based encryption allows the holder of the private key Sale of an identifier based key pair (in this case, party B) to decrypt a message sent to them encrypted (by party A) using B's public key QLD.

More particularly, party A, in order to encrypt a message m, first computes: U = rP where ris a random element of Fq. Next, party A computes: V = m 63 H3(t(R,rQiD)) Party A now has the ciphertext elements U and V which it sends to party B. Decryption of the message by party B is performed by computing: VET H3(t(U, SID)) = V H3(t(rP,sp'D)) = v Ed H3(t(P, QID) ) = V 03 113(t(sP,rQiD)) = V 63 H3(t(K,rQD)) = m Identifier-Based Signatures (see dashed box 4): - Identifier based signatures using Tate pairing can be implemented. For example: Party B first computes: r = t(slD, p)k where k is a random element of Fq.

Party B then apply the hash function H2 to m || r (concatenation of m and r) to obtain: h = H2(m || r).

Thereafter party B computes U= (k-h)SD thus generating the output U and h as the signature on the message m.

Verification of the signature by party A can be established by computing: r' = t(U, P). t(QiD, R)h where the signature can only be accepted if h = H2 (m || r).

Summary of the Invention

According to a first aspect of the present invention, there is provided an identifier-based cryptographic method using bilinear maps, comprising a trusted party, with a secret and an associated identifier string, carrying out operations of: deriving a first element from said identifier string by use of a one-way mapping function; deriving a second element using the secret and the first element; making at least the second element publicly available; and providing a private-key generation service comprising generating a private key for another party in dependence on said secret and on an identifier string associated with that other party.

According to a second aspect of the present invention, there is provided apparatus for use as a trusted party in respect of identifier-based cryptographic methods using bilinear maps, the apparatus comprising: a store for holding a secret; ; a first derivation arrangement for deriving a first element from an identifier string ofthe trusted authority using a one-way mapping function; a second derivation arrangement for deriving a second element using the secret and the first element; a distribution arrangement for making at least the second element publicly available; and a private-key generation arrangement for generating a private key for another party in dependence on said secret and on an identifier string associated with that other party.

Brief Description of the Drawines

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 showing prior art cryptographic processes based on elliptic curve cryptography using Tate pairings; Figure 2 is a diagram illustrating for generalized first and second parties, how a third party can verify an association between first and second parties; Figure 3 is a diagram of a hierarchy of a first-level trusted authority and a second level trusted authority.

Best Mode of CarrYine Out the Invention Considering first the situation where there is an association between a first party and a second party which the second party would like to be able to prove to a third party; the nature of the association concerned is a trust relationship (e.g. the second party is trusted to act on behalf of the first party in respect of certain matters).

In order to enable the second party to prove this association, the first party provides the second party with a secret, herein referred to as a "shared secret", though there is no requirement on the first party to keep a copy of this shared secret after giving it to the second party. The nature of the shared secret is such that it enables the second party to prove its association with the first party without giving away the shared secret.

The above-described arrangement is here enabled by the use of bilinear mappings as will; now be explained with reference to embodiments based on modified Tate pairings (though, of course, other pairings such as modified Well pairings can alternatively be used). The notations and definitions given in the introductory portion ofthe present specification also apply to what follows.

The first party has its own secret sit and an associated point P on an elliptic curve. The first party makes P and the combination sP(=R) publicly available in any suitable manner. The second party also has its own secret 52 and an associated point Q on the same elliptic curve as P. The second party makes Q and the combination s2Q publicly available in any suitable manner. It will be appreciated that reference to an element being made publicly available simply means making it available to third parties who have an interest and right to know the element and does not necessarily imply unrestricted distribution.

The second party is provided with sQ by the first party as the shared secret that is to be used in establishing to the third party the association between the second party and the first party. In order to keep the shared secret so Q secret whilst providing the third party with the information it needs to verify the association between the first and second parties, the second party combines sQ with 52 and makes the resulting combination S'52Q public.

Recapping so far, the elements associated with the first and second parties are: ; First party: Secret data: sit Public data: P. R(=sP) Second party: Secret Data: 52, Sit Q Public data: Q. sash, sag It is assumed that the third party reliably knows P and R(=sP), the public data of the first party. The third party has also received, in respect of the second party: the point Q; an element, herein celled X, that is purportedlyss2Q; and an element, herein called Y. that is purportedly s2Q. In order to check whether Xtruly does contain s', the third party checks the following: t(P, X) = t(R, Y) Test 1 Because R=sP, the above will only be valid if Xis equal to sit Y. This would prove that the second party must have a shared secret containing sit which only it and the first party know (thus proving the association between the parties) were it not for the possibility that, since sip is public, the second party could have constructed Q as mP, where m Fq, and then used m, 52 and sop to construct Xas ss2mP and Y as s2mP. In other words, if the second party can construct its Q from P then, it can pass Test 1 without needing to ask for a shared secret from the first party.

It is therefore necessary for the third party to be satisfied that Q has not been formed by multiplying P by m (it being appreciated that because the discrete logarithm problem is hard, the third party cannot discover if Q of the form mP - though, of course, if m=1, this will be apparent). To this end, the point Q is required to be derived from an identifier string ID using the map-to-point hash function Hi because in this case even if Q happened to be equal to mP (which is highly unlikely), the second party would neither be aware ofthis nor able to separate out m and use it to generate an Xof the form ss2mP. It is not, of course, possible for the second party to work backwards from a value of m to produce the string ID that would give rise to m using the map-to-point function.

To emphasise the fact that Q originates from an identifier, it is suffixed with "lD" in the following discussion; thus: AID = H(ID) where the identifier string ID can be any string and typically, though not necessarily, serves to identify the second party in plain language.

So now if the second party makes public the string ID rather than (or in addition to) QLD, the third party can use the string ID to form the point QLD thereby re-assuring itself that the second party has not used a value m to form Q as mP. However, the third party also needs to be able to link this legitimate Q[) to the elements used in Test I - in particular, the third party needs to be sure that the clement Y contains the legitimate Q'r' derived from ID. To this end, the third party must carry out a second test for which purpose the second party must provide a further quantity, herein called 7, that is purportedly equal to s2P. The second test is of the following form: t(Z, QLD)= t(P, Y) Test 2 If this is true, then the second party knows that Y must contain QID.

The above test (Test 1) is now therefore adequate to prove that the second party does indeed have a shared secret of the form sit QID which must have been provided by the first party, thereby proving there is an association between the first and second parties.

Recapping, and as shown in Figure 2, the elements associated with the first and second parties 5, 6 are: First party 5: Secret data: s' Public data: P. R=s'P Second party 6: Secret data: 52, Public data: ID, X=sis20ID' Y=s2QID, Z= s2P and the third party 7 carries out the following: QrD = map-to-point H(ID); Test 2; Test 1.

The requirements for the third party to be able to verify the association between the first and second parties (respectively higher-level and lowerlevel parties in the association hierarchy) can thus be expressed as follows: - the first party must have a public key (P. R) / private key so key pair where R=s'P; it may be noted that P could be based on an identity string for the first party by using the map-to-point hash H'.

- the second party must have an IBC public key ID / private keys'QrD keypair where QID =Ht(ID) - using a secret s2 the second party must form three public verification parameters (X Y. Z) by multiplying by 52: - the point P that is part of the public key of the first party, - the point QLD of the second party, - the private part so QID of the second party's IBC key pair.

In applying the two Tests 1 and 2, the point P is the point that is part of the public key of the first (higher-level) party, the other part of the key being R. whilst the point QID is the point derived from the identity of the second (lower-level) party using the map-to-point hash function H' and the parameters X, Y and Z are all supplied by the second party.

Other ways of characterising the parameters referred to above as the "verification parameters" are also possible; for example, it may be noted that two of these parameters, namely Y(=s2QD) and Z(= S2P) can each be viewed as part of the public key of a respective standard public/private key pair that involves the point concerned and has a private key of s2.

Figure 3 illustrates the application of the foregoing to an hierarchical arrangement of two trusted authorities 60 and 70 where the latter has issued a user 80 with an IBC private key.

More particularly, Figure 3 shows a first computer entity 10, a second computer entity 20, a third computer entity 30 and a fourth computer entity 40 connected via a network 50, for example the Internet. The first computer entity 10 represents a first trusted authority 60, for example a company, the second computer entity 20 represents a second trusted authority 70, for example a division within the company and the third computer entity 30 represents a user 80, for example a worker within the company. The fourth computer entity 40 represents, for example, a business partner 90 of the company that wishes to interact with the user 80.

The first, second, third and fourth computer entities 10, 20, 30, 40 are conventional program-controlled computing devices though specialised hardware may be provided to effect particular cryptographic processes.

The first computer entity 10 and second computer entity 20 form a trusted authority hierarchy in which the first computer entity 10 acts as a root, or first level, trusted authority and the second computer entity 20 acts as a second level trusted authority 70. The first level trusted authority 60 has a standard public key (P. RTAI) / private keys keypair where RTAI= sip. The second-level trusted authority 20 has an IBC public/private key pair the private key STA2 of which has been generated by the first-level trusted authority 60 using its private key stand QTA2, where QTA2=H(TA2) and "TA2" is an identity string associated with the second-level trusted authority 70. Table I sets out the keys held by the first-level and second-level trusted authorities 60 and 70.

Entity Standard Standard ID Based ID Based I Private Key I Public key | Private Key Pubic key First-level TA so P. RTAI (=SIP) I I Second-level TA I l STA2=s'QTA2 QTA2= H(TA2) |

Table I

Once in the possession of the IBC private key STA2 (the "master private key") the second- level trusted authority 70 is able to produce a set of verification parameters X, Y and Z enabling a third party to verify, without further interaction with the first-level trusted authority and without the need for digital certificates, that the private key of the IBC public/private key pair of the second-level trusted authority 70 could only have been generated by the first-level trusted authority 60. More particularly, the second-level trusted authority 70 selects a random number r where r e F4; the random number r is a 'pseudo- master private key". Once the pseudo-master key has been selected the second-level trusted authority 70 generates the following public verification parameters: rsQTA2, rQTA2 and rP that respectively correspond to the parameters X, Y and Z of the above-described Tests 1 and2.

It should be noted that even though in the above example the second-level trusted authority has created a single pseudo-master private key, the second-level trusted authority 70 could generate any number of pseudomaster private keys.

It may also be noted that the second-level trusted authority 70iS likely also to have one or more standard public/private key pairs. For example, the pseudo-master private key r could be used as the private key and combined either with P or QLD or another point in Gil not computed from an existing point, to form a corresponding public key. Alternatively, a completely separate private key 52 could be generated where s2 Fq and used with P or QID or another point in GO not computed from an existing point, to form a corresponding public key.

The user 80 registers with the second trusted authority 70 to obtain an associated IBC private key for the user's public key, where the user's public key could be any form of identifier, for example the user's name 'Bob', and the map-to-point hash HI (Bob) of this identifier maps to a point QBOb in Gil. The IBC private key provided to the user 80 is a combination of the user's public key and the second-level trusted authority's pseudo private key i.e. the user's private key is rQBOb.

To send an encrypted message to the user 80, the third-party business partner 90 can now use the IBC public key of the user 80 and the public key of the second-level trusted authority 70 used by user 80; in doing this, the third party 90 can be sure that the user will only be able to decrypt the message if the user is known to the second-level trusted authority 70 since the IBC private key needed for decryption must be provided by that authority.

The third party 90 can also verify that the second-level trusted authority 70 (company division) is associated with the first-level trusted authority (company). To do this, the third party 90 uses the identity "TA2" and public verification parameters rs QTA2, rQTA2 and rP of the second-level trusted authority 70, together with the public key P. RTA (=S]P) of the first-level trusted authority 60, to carry out the Tests I and 2 described above with respect to Figure 2. More particularly: - the third party 90 first forms QTA2 from the identity string "TA2" using the map-to point hash function Hi; - the third party 90 carries out Test 2 by checking t(Z, Q]A2)= t(P, Y) where 7= rP and Y= rQTA2 and QTA2 is the element just formed from the identity "TA2"; this check, if passed, confirms that the element Y contains QTA2 - the third party 90 carries out Test 1 by checking t(P, X) = t(RTAb where RTAI=SIP end X= rsQTA2; this check, if passed, confirms thatXmust contain s' which the second-level trusted authority 70 must have obtained in a non-public element from the first-level trusted authority 60. /

Claims (8)

1. An identifier-based cryptographic method using bilinear maps, comprising a trusted party, with a secret and an associated identifier string, carrying out operations of: deriving a first element from said identifier string by use of a one-way mapping function; deriving a second element using the secret and the first element; making at least the second element publicly available; and providing a private-key generation service comprising generating a private key for another party in dependence on said secret and on an identifier string associated with that other party.

2. A method according to claim 1, wherein the first and second elements, and the private keys generated by the private-key generation service, are points on an elliptic curve.

3. A method according to claim 1 or claim 2, wherein the trusted party is the root trusted authority of a hierarchy of trusted authorities.

4. A method according to claim 1 or claim 2, wherein the trusted party is a non-root trusted authority in a hierarchy of trusted authorities.

5. Apparatus for use as a trusted party in respect of identifier-based cryptographic methods using bilinear maps, the apparatus comprising: a store for holding a secret; a first derivation arrangement for deriving a first element from an identifier string ofthe trusted authority using a one-way mapping function; a second derivation arrangement for deriving a second element using the secret and the first element; a distribution arrangement for making at least the second element publicly available; and a private-key generation arrangement for generating a private key for another party in dependence on said secret and on an identifier string associated with that other party.

6. Apparatus according to claim 5, wherein the first and second derivation arrangements and the private-key generation arrangement are respectively arranged to generate said first and second elements and the third-party private keys, as points on an elliptic curve.

7. A system comprising apparatus according to claim 5 or claim 6, wherein said apparatus is arranged to serve as a root trusted authority of a hierarchy of trusted authorities.

8. A system comprising apparatus according to claim 5 or claim 6, wherein said apparatus is arranged to serve as a non-root trusted authority of a hierarchy of trusted authorities.