when compared to standard signature and key-agreement techniques, while further reducing communication overhead.

Transcription

1 CERTIFICATION OF DL/EC KEYS Benjamin Arazi LPK ABSTRACT It is shown that the explicit certification of public keys in customary DL/EC (Discrete-Log/ Elliptic-Curve) applications, ranging from digital signatures of the DSA type to keyagreements of the DH type, can be abolished. This facilitates highly efficient implementations in terms of the total number of exponentiations needed to be executed, the ability of having parallel processing, and communication overhead. At the fundamental level it is shown how to integrate the processing of the public key of the trusted third party (needed, by definition, in establishing the validity of static public values submitted by a user) and the dynamic processing associated with the actual cryptographic process. This reduces, by a factor of at least 2, the processing time when compared to standard signature and key-agreement techniques, while further reducing communication overhead. It is then shown how the performance of the introduced key-agreement techniques is further enhanced, by utilizing a principle termed "you are OK if I am OK". Here, the processing of the public key of Alice s trusted third party is not performed by Bob after he receives the values submitted by Alice, as customarily done. Instead, Bob refers to the said public key prior to his communication with Alice (utilizing the realistic observation under which Bob is supposed to know in any case the public key of Alice s trusted third party regardless of his communication with Alice). Here, if Bob is assured that his secret and public values are valid then he is subsequently assured that the public values submitted by Alice are valid as well. 1

2 Notations and terminology DL/EC (Discrete-Log/Elliptic-Curve) cryptographic applications relate to operations over a finite group of points in which the discrete log problem applies. A group-point is denoted in bold. s*p is a group-point obtained by multiplying the group-point P by the scalar s. This scalar is considered an exponent. When operating over a group of integers modulo an agreed q, the notation s*p means P s mod q, and s*p + t*q means P s *Q t mod q. G - the generating group-point, joint to all users that use the services of a system controlled by a certain trusted third party. Exponents are calculated modulo the order of G. LogP - the scalar k such that P = k * G. d - the secret key of the trusted third party. (For simpler explanations, it is assumed that Alice and Bob use the services of the same trusted third party. Extensions to the general case, where these parties use the services of different trusted third parties, naturally follow.) R = d*g - the public key of the trusted third party. xa, xb - the secret key of Alice, Bob. YA = xa*g, YB = xb*g - the public key of Alice, Bob. PUA, PUB - the public value of Alice, Bob. (In the implementations presented in this document, the users submit the said public value, and not the public key YA, YB.) ITA, ITB a representative of the identification details or the attributes of Alice, Bob. H(v,W) a transformation, known to all, that converts a scalar v and a group-point W into a scalar. (H is not necessarily a hash. Features of H are discussed later.) 2

3 1. Background 1.1. DL/EC signature techniques As a representative of DL/EC signature techniques, where Alice signs the message m, we describe the DSA [1]. Let xa denote Alice s secret key. Let G be a generating group-point known to all users. Let YA denote Alice s public key, where YA = xa * G. Signature: Alice selects a one-time key pair k and V = k * G, represents V by an integer p and calculates q = k -1 * (m + xa * p) (where integer calculations are performed modulo the order of G). The signature on m is the pair {p,q}. Alice then submits m, p, q, YA. Signature verification: The verifier, Bob, calculates t = q -1, v = m * t and w = p * t. He then calculates P = v * G + w * Yi, represents P by an integer r (in the same way that p represents V). The signature is determined to be valid if r = p. The certification principle Let ITA denote Alice s identification details or claimed attributes. When Alice submits to Bob her public key YA, Bob must be given an assurance that YA is associated with ITA. Here, Alice also submits to Bob a certificate CRA, which is the signature of a trusted third party on the association between YA and ITA. A complete DSA process therefore involves two signature verifications conducted by Bob. The first involves certificate verification. Here, the signed message is a value which combines ITA and YA. The signature is CRA, generated by the trusted third party, whose private key is d. The public key used in the certificate verification is the value R = d * G, published by the trusted third party. The second signature verification involves the actual process of verifying the authenticity of the dynamic message m. 3

4 Signature generation involves one exponentiation operation of the form b* A. Signature verification involves an operation of the form b*a + d*c, performed twice (including certificate verification). The latter operation can amount to less than two individual exponentiations when using some speedup methods [2] DL/EC key-agreement techniques DL/EC key-agreements are based on the DH (Diffie-Hellman) method [3] or its variants. Here, Alice and Bob exchange some public values, and by using values received from their counterpart and their own secret keys they end up with a value, common to the two of them, and which only they are supposed to know. This common value then acts as their generated session key. A basic DH key-agreement takes the following steps: Alice sends to Bob the values YA, ITA and CRA, defined before. Symmetrically, Bob sends to Alice: YB, ITB and CRB. Alice and Bob establish the validity of YB, YA, based on the certificate CRB and CRA they respectively received and by referring to the public key of the trusted third party. Alice and Bob respectively generate the session key KAB = xa * YB and KBA = xb * YA. The mathematical operations performed by each user amount to one operation of the form b * A + d * C (for certificate verification) and one more exponentiation (for session key generation). The above technique concerns a fixed-key-agreement, wherein Alice and Bob always end up with the same session key whenever they wish to generate such a key. An ephemeral DH key-agreement, wherein Alice and Bob generate a different session key whenever they communicate, based on a different random value each of them generates in each communication session, takes the following possible steps: 4

5 Alice generates a random pva, calculates the ephemeral value EVA = pva*g and uses xa in order to generate a signature SA on EVA. She then sends to Bob: YA, ITA, CRA, EVA and SA. Symmetrically, Bob sends to Alice: YB, ITB, CRB, EVB and SB. Alice and Bob establish the validity of YB, YA, based, respectively, on the certificate CRB and CRA and by referring to the public key of the trusted third party. Alice and Bob establish the validity of the received ephemeral values EVB and EVA, based on the signatures SB and SA and by referring to the public keys YB and YA (whose validity was established in the preceding step). Alice and Bob respectively generate KAB = pva * EVB and KBA = pvb * EVA. The mathematical operations performed by each user, when implementing the above procedure, amount to two operations of the form b * A + d * C (one for certificate verification and one for signature verification) and three more exponentiations (for ephemeral value generation, for signature generation and for key generation). A further ephemeral key-agreement method, is the MQV [4]. variation of this method: The following is one Alice generates a random pva, calculates EVA = pva * G and sends to Bob: YA, ITA, CRA and EVA. Symmetrically, Bob sends to Alice: YB, ITB, CRB and EVB. Alice and Bob establish the validity of YB, YA. Alice and Bob respectively generate KAB = (pva+t(eva) * xa) * (EVB + T(EVB) * YB) and KBA = (pvb+t(evb) * xb) * (EVA + T(EVA) * YA), where T is a transformation that converts the group-point EVA and EVB into a scalar. The mathematical operations performed by each user, when implementing the above, amount to one operation of the form b * A + d * C and three more exponentiations. 5

6 2. Description of the cryptographic technique The various aspects of the presented techniques, described next, do not include security considerations. These are treated in detail in Part 4 of this document. For simpler explanations, we treat the case where Alice and Bob use the services of the same trusted third party. Extensions to the general case simply follow. Here, whenever a user makes a reference to the public key of a trusted third party, this reference is being made to the key of the trusted third party of his counterpart Generating user s secret and public values The group-points G and R, and the scalar d, have already been defined as the generating group-point, the public key of the trusted third party, and the secret key of that party, where R = d * G. We further use a transformation H(v,W), known to all, that converts a scalar v and a group-point W into a scalar. While Alice s public key, in the presented technique, is still YA = xa * G, for a secret key xa, the public reference value submitted by Alice is a group-point PUA. The secret key xa and the public value PUA of Alice are generated as follows: Alice generates a random ha and submits VA = ha * G and ITA to the trusted third party; The trusted third party generates a random ka, he then calculates ka * G, PUA = VA + ka*g and pa = H(ITA,PUA)*kA + d; The trusted third party issues the values pa and PUA to Alice; Alice generates her secret key xa = pa + H(ITA,PUA) * ha. That is: xa = H(ITA,PUA) * (ka+ha) + d. It is noted that YA = xa * G = H(ITA,PUA) * PUA + R. It is further noted that the trusted third party does not know the value of Alice s secret key xa, while no party knows logpua. (logpua = ha + ka, where Alice and the trusted third party each knows only one addend.) 6

7 Alice can establish the validity of the values pa and PUA issued to her by checking whether pa*g = H(ITA,PUA)*(PUA - VA) + R DSA procedure without a separate submission of a public key and a certificate In the presented technique, Alice signs a message m in the standard lines of the DSA. That is: Alice generates a one-time key pair k and V = k*g, represents V by an integer p and calculates q = k -1 *(m + xa*p). The signature on m is the pair {p,q}. Alice then submits m, p, q, her ITA and the public value PUA. (Unlike a customary DSA, she does not submit her public key YA = xa*g and she does not submit a certificate.) Following the lines of the DSA, the verifier calculates t = q -1, v = m * t and w = p * t, and then u = H(ITA,PUA) * w and P = v * G + u * PUA + w * R. The value P is then represented by r (in the same way the signer represented V by p) and it is checked whether r = p. Note that P = v*g + u*pua + w*r = v*g + w*(h(ita,pua)*pua + R) = v*g + w*ya, which is the expression used in the DSA. It is observed that the single equality r=p establishes the validity of the message m as well as the validity of the public key YA (which was implicitly calculated by Bob). The presented signature verification technique, including the implicit certificate verification, is executed by one operation of the form b*a + d*c + f*e which is equivalent to a single ElGamal signature verification A modified DH fixed-key-agreement A DH fixed-key-agreement concerns the basic implementation in which specific users always generate the same joint session key based on fixed exchanged values. We present the following DH fixed-key-agreement technique. 7

8 After exchanging ITA and ITB, and the public values PUA and PUB, Alice and Bob respectively generate the session key KAB = xa*(h(itb,pub)*pub + R) and KBA = xb*(h(ita,pua)*pua + R). A key-confirmation now follows. That is, the two users verify that they share an identical key by encrypting and decrypting a randomly selected value. (The two keys equal, having the value xa * xb * G. This equality, in itself, does not prove yet that only the valid owners of PUA and PUB arrive at the value xa * xb * G. As shown later, the key-confirmation closes the certification loop.) The presented technique is executed by two exponentiations (or by one operation of the form b * A + d * C, by first calculating xa * H(ITB,PUB) modulo the order of G) A modified DH ephemeral-key-agreement A DH ephemeral-key-agreement, as treated in Section 1.2, concerns an implementation in which two specific users generate a different session key whenever they communicate, based on an ephemeral value generated by each party. We present the following DH ephemeral-key-agreement technique. Alice generates a random pva, calculates the ephemeral value EVA = pva * G and submits ITA, PUA and EVA to Bob. Bob performs the symmetric operations. Alice and Bob respectively generate the ephemeral session key KAB = pva *(H(ITB,PUB) * PUB + R) + (xa+pva) * EVB KBA = pvb *(H(ITA,PUA) * PUA + R) + (xb+pvb) * EVA A key-confirmation now follows. 8

9 (The two keys equal the value pva*xb*g + xa*pvb*g + pva*pvb*g. It is noted that the keys still equal if (xa+pva)* EVB and (xb+pvb) * EVA are respectively replaced by xa * EVB and xb*eva. The reasoning behind the presented choice follows in Part 4.) KAB can be expressed as pva*r + [pva*h(itb,pub)]*pub + (xa+pva)*evb. That is, KAB is calculated as an operation of the form b*a + d*c + f*e. Furthermore, the grouppoint PA = pva*r can be calculated by Alice off-line, together with EVA. (i.e., the random pva and then EVA and PA can be generated prior to the communication with Bob.) When Alice receives the values PUB and EVB, she can calculate [pva*h(itb,pub)]*pub + (xa+pva) * EVB and add PA to the result. This way, the complete process is executed by two off-line exponentiations (the generation of EVA and PA) and one on-line operation of the form b * A + d * C, instead of the operation b * A + d * C + f * E A modified MQV key-agreement The static public keys used in an MQV key-agreement are submitted with a certificate. Since the certificate is a fixed value, it cannot provide in an implied way or any other way the dynamic certification needed for verifying the authenticity of the ephemeral value submitted by a user. This dynamic certification is essentially achieved by a keyconfirmation. We show next how the MQV version of Section 1.2 can be modified such that the key-confirmation implicitly provides for certification of the static public keys YA and YB, on top of the implied certification of the ephemeral values EVA and EVB. Alice calculates the scalar values pa = pva + T(EVA) * xa, qa = pa * T(EVB) and ra = qa*h(itb,pub). Bob calculates, symmetrically, the values pb, qb and rb. The session key is then KAB = pa*evb + ra*pub + qa*r and KBA = pb*evb + rb*pub + qb*r. The calculation of the session key is followed by a key-confirmation. A complete MQV key-agreement process is therefore performed here by one operation of 9

10 the form b*a + d*c + f*e. To realize why KAB = KBA note that KAB = (pva + T(EVA)*xA)*(EVB + T(EVB)*H(ITB,PUB)*PUB + T(EVB)*R) = = (pva + T(EVA) * xa) * (EVB + T(EVB) * (H(ITB,PUB) * PUB + R)) = (pva +T(EVA)*xA) * (EVB + T(EVB)*YB) = KBA 2.6. A further modification: the you are OK if I am OK principle Further modifying the DH fixed-key-agreement of Section 2.3. The fixed session key generated by Alice and Bob according to the technique presented in Section 2.3 is, respectively, KAB = xa *(H(ITB,PUB) * PUB + R) and KBA = xb *(H(ITA,PUA) * PUA + R). These can be re-written as KAB = [xa * H(ITB,PUB)] * PUB + xa * R and KBA = [xb * H(ITA,PUA)] * PUA + xb * R. Note that xa*r is a fixed group-point which can be pre-calculated and stored by Alice. After receiving ITB and PUB Alice can calculate [xa*h(itb,pub)]*pub and add the precalculated xa * R to the result. Similar operations apply to Bob. The presented technique then facilitates the execution of a fixed-key agreement, including a mutual authentication of the participants, by a single exponentiation. Further modifying the DH ephemeral-key-agreement of Section 2.4. The ephemeral session key generated by Alice and Bob according to the technique presented in Section 2.4 is, respectively, KAB = pva *(H(ITB,PUB) * PUB + R) + (xa+pva) * EVB KBA = pvb *(H(ITA,PUA) * PUA + R) + (xb+pvb) * EVA 10 and

11 These values can be re-written as: KAB = [pva * H(ITB,PUB)] * PUB + (xa+pva) * (EVB + R) - xa * R KBA = [pvb*h(ita,pua)]*pua + (xb+pvb)* (EVA + R) - xb *R and As indicated before, the fixed group-point xa*r can be pre-calculated and stored by Alice. When Alice receives ITB and PUB she can calculate [pva*h(itb,pub)]*pub + (xa+pva)* (EVB + R) and subtract the pre-calculated xa *R from the result. Similar operations are performed by Bob. The presented technique can then be executed by one operation of the form b*a + d*c, which is preceded by the calculation of EVA = pva*g. To further clarify the observations made next, let us assume that the value EVB + R, which appears in the expression of KAB, was calculated by Bob and not by Alice. That is, Bob transmits the value VB = EVB + R to Alice, instead of transmitting EVB. Alice then calculates KAB = [pva*h(itb,pub)]*pub + (xa+pva)*vb - xa*r. Noting this expression, it is observed that the reference to the public key R of the trusted third party was effected prior to the communication of Alice with Bob. The same applies to the expression KAB = [xa * H(ITB,PUB)] * PUB + xa * R specified above for the fixed-key-agreement. After a successful key-confirmation, Alice, who knows that her own personal keys xa and PUA are valid (i.e., they were provided to her by a recognized trusted third party), is assured that Bob has also used valid personal keys. This introduces a principle termed as you are OK if I am OK, where Alice can effect a key-agreement process with another party just by knowing that her own personal keys are valid, and without referring during the key-agreement process to the public key of a trusted third party. The details discussed above concern the case where both parties use the services of the same trusted third party, and therefore refer to the same public key R. If Alice and Bob use the services of different trusted third parties, the saving in computational complexity based on the you are OK if I am OK principle is still achieved if a participant knows in advance the public key of the trusted third party of his counterpart. Realistically, this is the case in most practical circumstances, as Bob must know the public key of Alice s trusted 11

12 third party regardless of his communication with Alice, and vice versa. 3. Claimed attributes and advantages of the technique 3.1. Savings in computational efforts The savings in the computational efforts introduced by the presented techniques, when compared to customary DL/EC techniques, are summarized next in detail. These concern an overall saving in exponentiation operations, as well as parallelism which further expedites the process, where the traditional serial two operations associated with verifying a certificate and verifying the validity of a submitted dynamic value are combined into a single operation. The indicated figures were substantiated in the preceding sections. The very significant advantages of the presented techniques, over customary techniques, are clear for the case where b * A + d * C or b * A + d * C + f * E are executed by individual exponentiations as well as the case where speedup methods are used. Verifying a signature of the DSA type Customary implementation: Two operations of the form b * A + d * C, one for certificate verification and one for actual signature verification. Presented technique: One operation of the form b * A + d * C + f * E. DH fixed-key-agreement Customary implementation: One operation of the form b * A + d * C for certificate verification, and one exponentiation for session-key generation. Presented technique: A single exponentiation (or two exponentiations when not using the You are OK if I am OK principle). 12

13 DH ephemeral-key-agreement Customary implementation: Three exponentiations (generating an ephemeral value, signing this value, and generating the session-key); two operations of the form b*a + d*c (verifying the certificate and the signature). Presented technique: One exponentiation (generating the ephemeral value) and one operation of the form b*a + d*c (or one operation of the form b*a + d*c + f*e when not using the You are OK if I am OK principle). MQV key-agreement Customary implementation: One exponentiation (generating the ephemeral value); two operations of the form b * A + d * C (for certificate verification and session-key generation). Presented technique: One exponentiation and one operation of the form b * A + d * C + f * E Cutting down communication overhead The presented techniques facilitate the replacement of separately submitted public key (which is a group-point), and a certificate (which is a DSA signature, consisting of a pair of scalars), by a single submitted value (a group-point), whose size is that of the public key. This significantly cuts down communication overhead Enhancing implementation efficiency and cutting down management overhead Abolishing an explicit certification in key-agreement schemes saves a need to include a signature verification procedure in the execution package, enhancing implementation efficiency. Furthermore, abolishing the need for generating, storing and submitting an explicit certificate significantly cuts down management overhead. 13

14 4. Security assessment and considerations 4.1. On the possibility of forging the user s keys defined in Section Extracting the secret key of the trusted third party: The secret key of the trusted third party is d, while R = d*g is known. Users know multiple values of the form H(ITA,(hA+kA)*G)*kA + d, for known ITA, ha and (ha+ka)*g. The trusted third party prevents the extraction of d by associating each user with a different, randomly generated, ka. It is further noted that the system secret d is revealed if H(ITA,(hA+kA)*G)*kA equals any fixed or known value (modulo the order of the generating group-point G). The trusted third party, who has control over H(ITA,(hA+kA) * G) * ka by choosing the random ka, should take care of this threat. 2. Preventing a first party attack : A first party attack concerns the case where a user repudiates the validity of a cryptographic scenario in which he participated, claiming that he had weak secret keys which were mathematically discovered. The presented key issuing process inherently prevents such an attack, as the the trusted third party has control over the randomness of the user's secret key (while the trusted third party still does not know this key). 3. Generating values ITA, xa and PUA having a valid interdependence: The validity of the presented technique depends on the inability of any party to generate values xa, ITA and PUA such that the interdependence xa*g = H(ITA,PUA)*PUA + R holds. That is, no party beside Alice (as defined in Section 2.1) should be able to submit values that stand for ITA and PUA such that he knows log[h(ita,pua)*pua + R]. It is first observed that a forger cannot know logpua while he manufactured himself PUA, xa and ITA, where xa * G = H(ITA,PUA) * PUA + R, since he would then be able to recover logr, thereby being able to perform a general log operation. 14

15 There are three possible approaches in trying to falsify xa, ITA and PUA, while not knowing logpua, such that xa*g = H(ITA,PUA)*PUA + R: 1. Select a PUA (whose log is not known) and a scalar xa, and then recover a scalar v such that R = xa*g - v*pua. This attempt would fail as it would involve a log operation, regardless of the fact that v should also equal H(ITA,PUA). 2. Select a PUA, calculate H(ITA,PUA) and then recover a scalar xa such that xa*g = H(ITA,PUA)* PUA + R. This, again, would fail as it involves a log operation. 3. Select values v and xa and then determine the value PUA = v -1 *(xa*g - R). Even if it is possible to recover a PUA such that v acts as H(ITA,PUA), PUA has to simultaneously satisfy two independent constraints, which appears to be impossible to achieve. Trying to force (ITA,PUA)*PUA = 0 (regardless of of whether this is possible or not), will also not help, since the forger then has to produce an xa such that xa*g = R. That is, he has to perform a log operation. It is therefore claimed that a user who illegally tries to present himself as Alice cannot generate values xa, ITA and PUA such that xa * G = H(ITA,PUA) * PUA + R. A trial to generate valid values ITf, xf and PUf out of given valid values ITA, xa and PUA is not different from the above failed trials for generating ITA, xa and PUA from scratch. It should further be demanded that the sum of two valid keys will not yield a valid key. This demand is satisfied if the transformation H is non-linear. 4. Falsifying the role of the trusted third party: As described in Section 2.1, Alice verifies the validity of the values pa and PUA, issued to her, by checking whether pa * G = h(ita,pua) * (PUA-hA * G) + R, where R is the public key of the trusted third party. Falsifying the role of the trusted third party involves here an ability to produce values pa and PUA such that pa = log[h(ita,pua) * (PUA-hA * G) + R]. 15

16 This cannot be done in view of the above considerations Summarizing the required features of H The transformation H(ITA,PUA) can be a simple exor operation between ITA and any oneto-one scalar representative of PUA. (When operating over an elliptic curve, this representative can be the x coordinate of PUA.) It should be noted that a user can here make changes in both ITA and PUA, while keeping H(ITA,PUA) unchanged. That is, it is not demanded that H should be collision-free. This is based on the observation that the change enforced into PUA (in order that H(ITA,PUA) remains unchanged for invalid ITA) would necessitate a corresponding change in the secret key xa = H(ITA,PUA) * logpua + d. The forger, who changed ITA, is then unable to come up with a correct new xa due to the new logpua. It is possible to use, in any case, the hash transformation which serves in general certification applications (where the certificate is the signature of the trusted party on a value H(ITA,PUA) which strongly combines the user s identification details or attributes and his public key) while utilizing the significant advantages of the techniques presented in Part On the security of the modified DSA technique of Section 2.2 The difference between the certificate-less DSA technique of Section 2.2 and a standard DSA lies in the fact that the public key YA of the signer is implicitly generated by the verifier, rather than being received with a certificate. The operation P = v*g + w*ya, performed in the standard DSA procedure, is replaced with P = v*g + w*(h(ita,pua)*pua + R), which is technically executed by the parallel operation P = v*g + [w*h(ita,pua)]*pua + w*r. A forger does not know log[h(ita,pua) * PUA + R] in view of preceding considerations. Also, he cannot submit ITA (pretending to be Alice) and his own forged public value PUf 16

17 such that he knows log[h(ita,puf)*puf + R]. Therefore, the existence of the single equality r = p, which assures the verifier that the signer knows xa = logya in the lines of the DSA, provides for two purposes. It establishes the validity of the signed message, based on the fundamental principle of the DSA, and it further establishes the signer s valid ownership of the public key YA. The main observation made above is summarized as follows: Alice s ability to sign a message is based on her knowledge of the log of the public key she submits to Bob. In the presented technique, Alice s public key is calculated by Bob, whereas Alice can know the log of that public key only if she is the valid owner of that key. That is, her knowledge of the log of the said public key is not only a necessary condition for Alice s ability to sign the message, but it further guarantees her valid ownership of the key itself, whereas Alice s knowledge of the said log is established by Bob by a single check On the security of the presented key-agreement techniques The session key generated by the fixed-key technique of Section 2.3 is KAB = xa * (H(ITB,PUB) * PUB + R) ; KBA = xb * (H(ITA,PUA) * PUA + R) The session key generated by the ephemeral-key generation technique of Section 2.4 is KAB = pva*(h(itb,pub)*pub + R) + (xa+pva)*evb; KBA = pvb * (H(ITA,PUA) * PUA + R) + (xb+pvb) * EVA The security of the technique depends again on the inability of a forger to know log[h(ita,pua) * PUA + R] or log[h(itb,pub) * PUB + R] or to falsify values in a way that enables him to know any of the said logs. Only the valid Alice and Bob, who use their secret keys xa and xb, would then end up with the same session key, a fact which is established by the key-confirmation. 17

18 Similar considerations apply to the modified MQV technique of Section 2.5. The key-confirmation concerns a single check made by each participant, enabling him to implicitly verify that his counterpart knows the log of the public key YA or YB, whereas the calculation of the public key is implied in the process. Like the case with the DSA, treated in the preceding Section, Alice s knowledge of the log of the said public key, established by Bob by a single check, is not only a necessary condition for a successful DH key-agreement, but it further guarantees Alice s valid ownership of her claimed public key. Forward secrecy (concerning the ephemeral-key generation technique of Section 2.4) Forward secrecy concerns the prevention of the possibility that the disclosure of any static secret value reveals session keys previously generated by two communicating parties. The said static value can either be the secret key of the trusted third party or users secret key or a secret value common to two or more specific communicating users. It was shown that the generated ephemeral session key is KAB = KBA = pva * xb * G + xa * pvb * G + pva * pvb * G, where xa * G, xb * G, pva * G and pvb * G are publicly known. A disclosure at any stage of xa and xb would not reveal the value of a previously generated KAB or KBA due to the addend pva*pvb*g. This explains why it is preferred to use the expression KAB = pva * (H(ITB,PUB) * PUB+R) + (xa+pva) * EVB rather than the expression KAB = pva * (H(ITB,PUB) * PUB+R) + xa * EVB which can also yield a valid key generation. There are no static values common to two specific communicating users, whose disclosure reveals the value of previously generated session keys, as all the addends in the expression pva * (H(ITB,PUB) * PUB + R) + (xa+pva) * EVB = pva * H(ITB,PUj) * PUB + pva * R + xa*pvb*g + pva*pvb*g are ephemeral. That is, a key does not consist of a static part, which is fixed to two specific communicating users, where this static part encrypts an ephemeral value, and where the later leakage of this static part would reveal the value of generated session keys. 18

19 5. Known limitations and disadvantages In the proposed technique, the keys of the trusted third party and users keys are of the same size. This can be considered a disadvantage when compared to implementations in which explicit independent certification of users static keys is performed, and where the keys of the trusted third party can be made larger than users keys. However, the described apparent disadvantage of the proposed technique is common to all systems offering implied key certification, including identity-based systems. 6. Intellectual property issues A patent application on the proposed technique has been filed. A letter of assurance of reasonable and non-discriminatory patent licensing will be provided if this technique is accepted as part of p1363a. References [1] Approval of Federal Information Processing Standards Publication 186, Digital Signature Standard (DSS), "Federal Register, v. 58, n. 96, 19 May 1994, pp [2] A. J. Menezes, P. C. van Oorschot and S. A. Vanstone, Handbook of Applied Cryptography, Chapter 14, pp , CRC Press, [3] W. Diffie and M. Hellman, New directions in cryptography, IEEE Trans. on Information Theory, IT-22, 1976, pp [4] Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, "An efficient protocol for authenticated key agreement, Technical report CORR 98-05, Dept. of C&O, University of Waterloo, Canada, March