rfc1824.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 1824                          TESS                       August 1995


3.2.  Unilateral Authentication

   The "Unilateral Authentication" (or "Half Authentication") can be
   used in those cases:

   - Alice wants to authenticate herself to Bob without Bob
     authenticating himself to Alice.

   - Bob wants to send an encrypted message to Alice readable by her
     only (offline encryption).

   A shared key is generated by the following protocol. This key can be
   known by Alice and Bob only.

   Assuming that Bob already reliably learned the (p,g,y) of the SKIA
   Alice got her key from, the steps are:

   1. Alice sends her public key (Id[A],r[A]) to Bob if he does not
      already know it.

   2. Bob chooses a random number 1 < z[A] < p-1 and calculates
      v[A] := r[A] ^ z[A] mod p

   3. Bob sends v[A] to Alice.

   4. Alice and Bob calculate the session key:

      Alice: key[A] := v[A] ^ s[A] mod p
      Bob:   key[A] := Y[A] ^ z[A] mod p

   Apply the equations of the User Key Setup section to Bob's equation
   to see that Alice and Bob get the very same key in step 4:

      key[A] = r[A] ^ ( s[A] * z[A] ) mod p

   A third party cannot calculate key[A], because it has neither s[A]
   nor z[A]. Therefore, Bob can trust in the fact that only Alice is
   able to know the key[A] (as long as nobody else knows her secret
   s[A]).

   This protocol is based on the Diffie-Hellman scheme [10], but avoids
   the weakness of the missing authenticity of the public keys.

   In this protocol Bob did not verify whether Alice really knew her
   s[A] and was able to calculate key[A]. Therefore, a final challenge-
   response step should be performed in case of online communication
   (see the subsection below).




Danisch                      Informational                      [Page 8]

RFC 1824                          TESS                       August 1995


   In case of sending encrypted messages, Bob can execute step 4 before
   step 3, use the key[A] to encrypt the message, and send the encrypted
   message together with v[A] in step 3.

3.3.  Mutual Authentication

   The "Mutual Authentication" is used for online connections where both
   Alice and Bob want to authenticate to each other.

   Within this protocol description it is assumed that Alice and Bob
   have keys of the same SKIA and use the same triple (p,g,y). Otherwise
   in each step the triple has to be used which belongs to the user key
   it is applied to.

   The steps are as follows (where the first four steps are exactly
   twice the "Unilateral Authentication" and steps 5-9 form a mutual
   challenge-response step to find out whether the other side really got
   the key):

   1. Alice sends her (Id[A],r[A]) to Bob.
      Bob sends his (Id[B],r[B]) to Alice.

   2. Bob chooses a random number z[A] < p-1
      and calculates v[A] := r[A] ^ z[A] mod p

      Alice chooses a random number z[B] < p-1
      and calculates v[B] := r[B] ^ z[B] mod p

   3. Bob sends v[A] to Alice.
      Alice sends v[B] to Bob.

   4. Alice and Bob calculate the session keys:

      Alice: key[A] := v[A] ^ s[A] mod p
             key[B] := Y[B] ^ z[B] mod p

      Bob:   key[B] := v[B] ^ s[B] mod p
             key[A] := Y[A] ^ z[A] mod p

   5. Alice chooses a random number R[B]
      Bob   chooses a random number R[A]

   6. Alice sends Encrypt(key[B],R[B]) to Bob.
      Bob   sends Encrypt(key[A],R[A]) to Alice.

   7. Alice and Bob decrypt the received messages to R'[A] and R'[B].





Danisch                      Informational                      [Page 9]

RFC 1824                          TESS                       August 1995


   8. Alice sends Encrypt(key[A],T(R'[A])) to Bob.
      Bob   sends Encrypt(key[B],T(R'[B])) to Alice.

   9. Alice and Bob decrypt the received messages to R''[A] and R''[B]

  10. Alice verifies whether T(R[B]) = R''[B].
      Bob   verifies whether T(R[A]) = R''[A].


   T()  is a simple bijective transformation function, e.g. increment().

   After step 4 Alice can trust in the fact that only Bob and herself
   can know key[B], but she still does not know whether she is really
   talking to Bob. Therefore, she forces Bob to make use of his key
   within steps 5-9. Alice now has checked whether she really talks to
   Bob. Since the scheme is symmetrical, Bob also knows that he talks to
   Alice.

3.4.  Message Signing

   To sign a message m (where H(m) is a cryptographic hash value of the
   message), the message author A generates an ElGamal signature by
   using his r[A] as the generator and the s[A] as his secret:

   -  A generates a random number K with gcd(K,p-1) = 1.

   -  R := r[A] ^ K mod p

   -  S := ( H(m) - s[A] * R ) * (K ^ -1)   mod (p-1)

   The calculated set of numbers fulfills the equation:

      ( s[A] * R + K * S ) = H(m) mod(p-1)

   The signed message consists of (m,Id[A],r[A],R,S).

   The receiver of the message checks the authenticity of the message by
   calculating the hash value H(m) and verifying the equation:

      r[A] ^ H(m) = ( Y[A] ^ R )  * ( R ^ S )  mod p

4.  Enhancements

   This section describes several enhancements and modifications of the
   base protocol as well as other comments.






Danisch                      Informational                     [Page 10]

RFC 1824                          TESS                       August 1995


4.1.  Non-Escrowed Key Generation

   Within the normal User Setup procedure for a User A, the SKIA gains
   knowledge about the secret key s[A]. The SKIA could use this key to
   fake signatures or decrypt messages, or to allow others to do so.

   To avoid this situation, a slight modification of the User Setup
   procedure may be applied. The SKIA Setup is the same as in the base
   protocol.

   Within the User Setup the SKIA does not use its primitive element g,
   but a generator created by the User instead.

   The modified scheme looks like this:

   -  User A generates a random number a with gcd(a,p-1)=1

   -  User A calculates g' := g^a mod p and forwards g' to the SKIA.

   -  The SKIA generates Id[A] and k[A] as in the base protocol

   -  The SKIA sets r[A] := ( g' ^ k[A] ) mod p and
      s'[A] := ( H(Id[A])  - x * r[A] ) *  (k[A] ^ -1)    mod (p-1)

   -  The SKIA forwards (Id[A],r[A],s'[A]) to the user A

   -  The user A calculates his s[A] := s'[A] * (a^-1) mod (p-1)

   The SKIA is not able to find out the secret key s[A] of A.  This
   protocol is based on the idea of the 'testimonial' [11].

   The SKIA is still able to create a second key with the same Identity
   Descriptor (identical or at least having same contents), but with
   different r[A] and s[A]. If such a second key was successfully used
   for authentication or message signing, the real key owner can use his
   own key to proof the existence of two different keys with identical
   (equivalent) Descriptors. The existence of such two keys shows that
   the SKIA cannot be trusted any longer.

   If the key is generated by this method, it should be mentioned in the
   Identity Descriptor. This allows any communication partners to look
   up in the public part of a key whether the secret part is known to
   the SKIA.

4.2.  Hardware Protected Key

   The protocol of the previous subsection guaranteed that the SKIA does
   not know the user's secret key.



Danisch                      Informational                     [Page 11]

RFC 1824                          TESS                       August 1995


   On the other hand, the SKIA may wish that the user himself does not
   know his own secret key. This may be necessary because the user could
   otherwise reveal his secret key accidently or intentionally.
   Especially if untrusted hard- or software or an environment without
   trusted process protection is used, the secret key can be spied out.
   For high-level security applications this might not be acceptable.
   The key owner must be able to use his key without being able to read
   this key. This contradiction can be solved by hiding the secret part
   of the User Key within a protected hardware device.

   Within the SELANE project, the protocols described in this RFC were
   implemented for SmartCards. The User Key is created using the non-
   escrowed key generation procedure described in the previous section,
   modified such that the random number is generated inside the card.
   The secret s[A] exists only inside the card and does not get outside.
   The SmartCard is able to execute all parts of the algorithms which
   need access to the secret key.  To make use of the SmartCard an
   additional password is required.

   If the key is hidden in such a hardware device, it should be
   mentioned in the Identity Descriptor. This allows any communication
   partners to look up in the public part of a key whether the key is
   hardware protected.

4.3.  Key Regeneration

   If both methods of the previous subsections are used to protect the
   key, neither the SKIA nor the User himself knows the secret key. This
   could be harmful for the User if the hardware device is lost or
   damaged, because the User could become unable to decrypt messages
   encrypted with the public key.

   To prevent such a denial of service, there are two methods:

   - If the protection factor 'a' was choosen by the User, the User
     can deposit the factor 'a' in a secure way, e.g. give it as a
     shared secret to his friends. The SKIA can do the same and
     deposit s'[A] somewhere else.  If the SKIA and the User
     cooperate, they are able to create a second hardware device
     equivalent to the first.

   - If the protection factor a was generated inside of the hardware
     device, the device itself may give out the s[A] or the a in a
     secure way (e.g. as a shared secret).

   Since the recreation of a User key defeats the property of such a key
   to exist only once, the SKIA should restrict this to special cases
   only.  Furthermore it should be done only after the end of the



Danisch                      Informational                     [Page 12]

RFC 1824                          TESS                       August 1995


   lifetime of the key, if its lifetime was limited.

4.4.  r ^ r

   A slight modification of the base protocol allows some speedup in the
   key exchange:

   -  The SKIA is created as in the base protocol

   -  For the User Setup the SKIA solves the equation
      x * s[A] + r[A] * k[A] = H(Id[A]) mod (p-1)
      which differs from the base protocol in that r and s were swapped.

   -  The public key allows to calculate
      y ^ s[A] = ( g ^ H(Id[A]) ) * ( r[A] ^ -r[A] )  mod p
      without knowing s[A]. Here the term  (  r[A]  ^  -r[A]  )  can  be
      precalculated for speedup.

   -  Bob calculates key[A] := ( g ^ H(Id[A]) * r[A] ^ -r[A] ) ^ z[A]
               and     v[A] := y ^ z[A] mod p
      Alice gets     key[A] := v[A] ^ s[A] mod p
      where key[A] = y ^ (s[A] * z[A])

   This protocol is similar to the AMV modification by Agnew et al.
   [12].

4.5.  Implicit Key Exchange

   If the r ^ r protocol of the previous section is used, an implicit
   shared key can be calculated for Alice and Bob by using the Diffie-
   Hellman scheme:

   -  Alice: key[A,B] = ( g ^ H(Id[B]) * r[B] ^ -r[B] ) ^ s[A] mod p

   -  Bob:   key[B,A] = ( g ^ H(Id[A]) * r[A] ^ -r[A] ) ^ s[B] mod p

   where key[A,B] = key[B,A] = y ^ (s[A] * s[B]).

   This can not be used with Non-escrowed keys.

4.6.  Law Enforcement

   This will be subject of a separate RFC.








Danisch                      Informational                     [Page 13]

RFC 1824                          TESS                       August 1995


4.7.  Usage of other Algebraic Groups

   Within this RFC calculations were based on a specific algebraic
   group, the multiplicative group of integers modulo a prime number p
   (which is the multiplicative group of a finite field GF(p)). However,
   any cyclic finite group with a strong discrete logarithm problem can
   be used, e.g., a subgroup of the multiplicative group or elliptic
   curves.

   As an example the subgroup used by the DSA (Digital Signature
   Algorithm) of length N can be used instead of the full multiplicative
   group of GF(p) for speedup (in this case the Secure Hash Algorithm
   SHA is recommended as the hash algorithm).  See [13, 14] for a
   description of DSA and SHA.

4.7.1.  DSA subgroup SKIA Setup

   -  Generate  large  primes  p  and  q such that p is at least 512 bit
      long, q is 160 bit long, and q is a factor of (p-1).

   -  choose a primitive root h in GF(p)

   -  g:= h^((p-1)/q)
      Note that g generates a subgroup G with |G|=q

   -  x: a random number of about 160 bit.

   -  y:= ( g ^ x ) mod p

   The public key of the SKIA is (p,g,y,q). (q is required for speedup
   only.)

   The secret key of the SKIA is x.

4.7.2.  Escrowed DSA subgroup User Setup

   -  k[A]: a random number of 160 bit length with gcd(k[A],q)=1

   -  r[A]:= ( g ^ k[A] ) mod p

   -  s[A]:= (H(Id[A]) + x * r[A]) * (k[A] ^ -1)  mod q

   Again, (Id[A],r[A]) is the public key and s[A] is the secret key.
   Note that r[A] has the length of p and s[A] has the length of q (160
   bit).






Danisch                      Informational                     [Page 14]

RFC 1824                          TESS                       August 1995