rfc1824.txt

<VC++网络游戏建摸与实现>源代码

4.7.3.  Non-Escrowed DSA subgroup User Setup

   -  User A generates a random number h of 160 bit length.

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

   -  The SKIA generates the user key with the secret key s'[A].

   -  User A calculates s[A]:= s'[a] * (h^-1) mod q

4.7.4.  DSA subgroup Authentication

   The protocols for authentication are the same as described above,
   except that wherever the modulus (p-1) was used the smaller modulus q
   is used instead, and DSA is used for message signing.

   The abbreviation Y[A] still stands for r[A] ^ s[A], which is now (the
   sign of r[A] was changed for speedup)

      ( g ^ H(Id[A])) * ( y ^ r[A] ) mod p

   and can be calculated in a faster way as

      u1 * u2 mod p

   where

      u1 := g ^ ( H(Id[A])  mod q )  mod p
      u2 := y ^ ( r[A] mod q ) mod p.

5.  Multiple SKIAs

   In the preceding sections it was assumed that everybody learned the
   (p,g,y) triple of a SKIA reliably.

   By default, a User reliably learns only the (p,g,y) of the SKIA which
   generated his own key, because he gets the triple with his key and
   can verify the triple with the signature verification equation.

   If the User wants to communicate with someone whose key was generated
   by a different SKIA, a method for authenticating the (p,g,y) of the
   other SKIA is needed.

5.1.  Unstructured SKIAs

   This will be subject of a separate RFC.





Danisch                      Informational                     [Page 15]

RFC 1824                          TESS                       August 1995


5.2.  Hierarchical SKIAs

   If there is a hierarchy between the SKIAs, their keys can be
   generated hierarchically:

   -  Every SKIA and every User has a level  (expressed  as  a  cardinal
      number).  The root SKIA has level 0. All Users and all other SKIAs
      have levels greater than 0.

   -  Each SKIA except the root SKIA is also a User, and each  User  can
      be a SKIA.

      A SKIA of level n generates keys for Users of level n+1.

      A User of level n is also a SKIA of level n.

   -  Since  every SKIA (except the root SKIA) is also a User, each SKIA
      has an Identity Descriptor describing its Identity and perhaps its
      level  and  its  parent  SKIA. There is a function parent(A) which
      finds the parent SKIA for every user  A.  This  function  may  use
      informations stored in the Identity Descriptor.

      Thus,  the  parent()  function allows to find the path to the root
      SKIA for every node of the tree forming the hierarchy.

      The root SKIA may also have an Identity Descriptor.

   -  The root SKIA creates itself as in the base protocol.

   -  The key for a User A of level n (n>0) is generated by  the  parent
      SKIA  of  level  n-1.  The public part is (Id[A],r[A]), the secret
      part is (s[A]).

      User A is automatically SKIA A:

      p[A] := p[parent(A)]  = p of the root SKIA
      g[A] := r[A]
      x[A] := s[A]
      y[A] := g[A] ^ x[A] = r[A] ^ s[A] = Y[A] =
             ( g[parent(A)] ^ H(Id[A]) ) * ( y[parent(A)] ^ -r[A]) mod p

      Therefore, the public data (p,g[A],y[A]) of  the  SKIA  A  can  be
      calculated  by everyone from the public data of the User A and the
      public data of its parent SKIA. The SKIA  A  itself  may  use  the
      faster  method  to  get  y[A]  by  calculating  r[A] ^ s[A], while
      everybody else has to use the slower but public method as  in  the
      lower  equation.  The  secret  of the "SKIA A" is identical to the
      secret of the "User A".



Danisch                      Informational                     [Page 16]

RFC 1824                          TESS                       August 1995


      Since a User A uses the very same data to act as either a user  or
      as a SKIA, and since message signing (subsection 3.4.) is the very
      same procedure as generating a User key (in fact it  is  the  same
      thing),   a  user  should  not  sign  a  message  which  could  be
      misunderstood  as  an  Identity  Descriptor.  An  attacker   could
      intercept  the  message  and  its signature and abuse it as a User
      key. This can be avoided by the use of tags  which  preceed  every
      set  of  data  being signed and show whether it is a message or an
      Identity Descriptor.

   This scheme allows any two users (even users of distinct hierarchies)
   to communicate reliably. They need to know the public data (p,g,y) of
   each other's root SKIA only. There is no need for online key servers.

   The communication is the same as in the base protocols but with an
   extension to the method of finding Y[A] (again with Alice and Bob):

   -  Bob reliably learned the (p,g,y) of Alice's root SKIA S(0).

   -  Where Alice presented (Id[A],r[A]) only in the first step, she now
      presents (Id[S],r[S]) for each SKIA/User node S in her path to her
      root SKIA S(0).  Since  this  information  does  not  need  to  be
      reliable  or  signed,  it  can  be  provided  by any simple server
      mechanism.

   -  Bob iteratively calculates the public data (p,g,y) of each SKIA in
      the  path,  starting  with  Alice's  root  SKIA, until he gets the
      (p,g,y) of Alice where y is Y[Alice].

   Note that Bob did not have to verify anything within the iteration.
   After the iteration he has a set of public SKIA data (p,g,y) to be
   used with Alice public key, but he still does not know whether he was
   spoofed with wrong data of Alice or her parent SKIAs.

   Since the iteration Bob calculated is a chain of nested signatures,
   the correctness of the (p,g,y) he gets depends on every single step.
   If there is at least one step with a bad Id[S] or r[S], Bob will get
   a wrong Y[S] in this step and all following steps, and the chain
   doesn't work.

   If the chain calculated by Bob was not completely correct for any
   reason, Alice cannot make use of her key: her signatures do not
   verify, she cannot decrypt encrypted messages and she cannot answer
   to the challenge response step in case of mutual authentication.







Danisch                      Informational                     [Page 17]

RFC 1824                          TESS                       August 1995


5.3.  Example: A DNS-based public key structure

   Here is a simple example of the usage of the hierarchical SKIA scheme
   within the DNS name space:

   Let every domain also be a SKIA, and let the root domain be a root
   SKIA. Let the Identity Descriptor of any object within the name space
   be its name: the domain name for domains, the host name for machines,
   the mail address for humans and services.

   Consequently, a user with the mail address "[e-mail]" got
   his key from the SKIA of the domain "ira.uka.de". This SKIA was
   authorized by the SKIA of "uka.de", which was authorized by the SKIA
   of "de", which is the root SKIA of Germany. It is assumed that
   everybody reliably learned the public key of the german root domain
   "de".

   The public key of [e-mail] would look like:

      (  "[e-mail]", r[[e-mail]] ,
         "ira.uka.de"        , r[ira.uka.de]         ,
         "uka.de"            , r[uka.de]
      )

   For the reasons described in the previous subsection, this key is
   self-certified and does not need any further signature.

   The key can be presented by [e-mail] within online
   communications, be appended to signed messages, or simply be
   retrieved by the domain name server of ira.uka.de.

   Someone who reliably learned the (p,g,y) of the root domain .de
   (Germany) can now build the chain:

      "de"                        (p,g,y)[de]
      "uka.de"                    (p,g,y)[uka.de]
      "ira.uka.de"                (p,g,y)[ira.uka.de]
      "[e-mail]"        (p,g,y)[[e-mail]]

   Thus it is possible to reliably obtain the Y[[e-mail]].

   To communicate with the whole world, knowledge of the public keys of
   all root domain SKIAs only is needed. These keys can be stored within
   some tens of KBytes.  No third party is needed for doing an
   authenticated key exchange.

   The whole world could also be based on a single root SKIA; in this
   case a single (p,g,y) is needed only.



Danisch                      Informational                     [Page 18]

RFC 1824                          TESS                       August 1995


   In a more realistic example the Id[[e-mail]] could contain:

      creator=      ira.uka.de
      created=      1-Jun-1995
      expiry=       31-Dec-1999
      protection=   non-escrowed, smartcard
      type=         human
      name=         Hadmut Danisch
      email=        [e-mail]
      phone=        [phone]
      fax=          [phone]
      photo=        <digitized compressed portrait>

Security Considerations

   -  The strength of TESS depends  on  the  strength  of  the  discrete
      logarith  problem,  the strength of the ElGamal signature, and the
      confidentiality of the SKIAs.

   -  Attention should be paid to the  security  considerations  of  the
      underlying mechanisms (ElGamal, DSA, Diffie-Hellman, etc.).

   -  Since  the  SKIA  creates  itself  under  normal circumstances, an
      attacker could create his own SKIA and use it to create a User Key
      with  an  arbitrary  Identity  Descriptor.  This  shows  that  the
      Identity Descriptor is as reliable as the  origin  of  the  triple
      (p,g,y) of the SKIA it came from. The User Key creation process is
      a signature process  for  the  Identity  Descriptor  and  strongly
      depends on the trustworthyness of the signing SKIA.

   -  It  is  the  SKIA's  duty  to  give  the s[A] only to the user the
      Identity Descriptor belongs to.

   -  Since the very same procedure is used  for  signing  messages  and
      generating  user  keys,  it  is  important  to distinguish between
      messages and keys.

   -  The authentication protocols work  without  an  online  authority.
      Therefore,  there  is  no  simple  way for revoking keys. For this
      reason keys should  have  an  expiration  date  mentioned  in  the
      Identity  Descriptor.  In  case  of  the hierarchical scheme a key
      expires if any key in the path to the root SKIA expires.









Danisch                      Informational                     [Page 19]

RFC 1824                          TESS                       August 1995


References

1.    Th. Beth, F. Bauspiess, H.-J. Knobloch,  S.  Stempel,  "TESS  -  A
      Security  System  based  on Discrete Exponentation," Computer
      Communcations Journal, Vol. 17, Special Issue, No.  7, pp.
      466-475 (1994).

2.    T.  ElGamal,  "A  Public  Key  Cryptosystem and a Signature Scheme
      Based on  Discrete  Logarithm,"  IEEE-Trans.  Information  Theory,
      IT-31, pp. 469-472 (July 1985).

3.    B.  Klein, H.-J. Knobloch, "ElGamal-Signatur" in
      Sicherheitsmechanismen, ed. Fries, Fritsch, Kessler, Klein, pp.
      171-176, Oldenburg, Muenchen (1993).

4.    C.  G.  Guenther, "An Identity-Based Key-Exchange Protocol" in
      Advances in Cryptology, Proceedings of Eurocrypt '89,  pp.  29-37,
      Springer (1990).

5.    B.  Klein,  H.-J. Knobloch, "KATHY" in Sicherheitsmechanismen, ed.
      Fries, Fritsch, Kessler, Klein, pp. 252-259,  Oldenburg,  Muenchen
      (1993).

6.    F. Bauspiess, H.-J. Knobloch, "How to keep authenticity alive in a
      computer network" in Advances in Cryptology, Proceedings of
      Eurocrypt '89, pp. 38-46, Springer (1990).

7.    F.  Bauspiess,  "SELANE  -  An  Approach  to  Secure  Networks" in
      Abstracts of SECURICOM '90, pp. 159-164, Paris (1990).

8.    Th. Beth,  "Efficient  zero-knowledge  identification  scheme  for
      smart  cards"  in Advances in Cryptology, Proceedings of Eurocrypt
      '88, pp. 77-84, Springer (1988).

9.    D. Chaum, J. H. Evertse, J. van de Graaf,  "An  improved  protocol
      for demonstrating possesion of discrete logarithms and some
      generalizations" in Advances in Cryptology, Proceedings of
      Eurocrypt '87, pp. 127-141, Springer (1988).

10.   W.  Diffie,  M.  Hellman,  "New directions in cryptography," IEEE-
      Trans. Information Theory, 22, pp. 644-654 (1976).

11.   Th. Beth, H.-J. Knobloch, "Open network authentication without  an
      online  server"  in  Proc.  Symposium on Comput. Security '90, pp.
      160-165, Rome, Italy (1990).






Danisch                      Informational                     [Page 20]

RFC 1824                          TESS                       August 1995


12.   G. B. Agnew, R. C. Mullin, S. A. Vanstone, "Improved digital
      signature scheme based on discrete exponentation," Electron.
      Lett., 26, pp. 1024-1025 (1990).

13.   "The Digital Signature Standard," Communications of the ACM,  Vol.
      35, pp. 36-40 (July 1992).

14.   Bruce Schneier, Applied Cryptography, John Wiley & Sons (1994).

Author's Address

   Dipl.-Inform. Hadmut Danisch
   European Institute for System Security (E.I.S.S.)
   Institut fuer Algorithmen und Kognitive Systeme (IAKS)

   University of Karlsruhe
   D-76128 Karlsruhe
   Germany

   Phone: ++49 721 96400-18
   Fax:   ++49 721 696893
   EMail: [e-mail]
   WWW:   http://avalon.ira.uka.de/personal/danisch.html




























Danisch                      Informational                     [Page 21]