home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / src / Tools / pidentd / pidentd-2.6.1 / doc / why-encrypt.txt < prev    next >
Encoding:
Text File  |  1995-07-31  |  6.9 KB  |  171 lines
  1. ``Why encrypt ident/TAP replies ?''
  2. Damien Doligez
  3. 1994.02.22
  4.  
  5.  
  6. This text is a companion to ``Why TAP?'' by Daniel J. Bernstein.
  7. I will explain the reasons why your ident server should encrypt its
  8. replies before sending them.
  9.  
  10. This is written from the point of view of a system administrator
  11. who wants to install an ident server.  The local machine is the machine
  12. running the ident server, and the remote machine any machine on the
  13. Internet that keeps a log of ident replies from the local machine.
  14.  
  15. This starts as a structured document and ends in random comments
  16. and implementation remarks.
  17.  
  18.  
  19. Problems with ident.
  20.  
  21. The ident protocol, as implemented by pidentd return a cleartext
  22. identification of the user.  This approach has the following problems:
  23.  
  24. 1. The remote administrator is tempted to interpret the ident logs
  25.    without asking the local administrator.  Everybody is supposed
  26.    to know that ident replies are only meaningful to the local
  27.    administrator, but in the real world, the remote administrator
  28.    will forget that, especially if the ident data is mixed with
  29.    data from his own machines (which is almost always the case).
  30.  
  31. 2. Any user on the remote system can call the local ident server
  32.    and collect login names for guessing passwords, and usage
  33.    patterns.
  34.  
  35. 3. The remote administrator might be malevolent and lie to you about
  36.    the contents of his ident logs.
  37.  
  38. 4. Some network attacks on the ident protocol have been described
  39.    on Usenet (comp.security.*).  They involve intercepting ident
  40.    requests and replying with bogus information, from another host
  41.    on the network, with forged IP packets.
  42.  
  43.  
  44. The crypto solution.
  45.  
  46. Dan Bernstein writes:
  47. >An easy solution to [problems 2 and 3] is to encrypt your usernames
  48. >(along with a timestamp, perhaps, though this defeats the selective
  49. >blocking application outlined in the next section) in a secret key.
  50.  
  51. This also solves problem 1, but it is not a complete solution to
  52. problems 3 and 4.  If you only encrypt the date and user ID, you
  53. give to the remote administrator a piece of data that proves
  54. that the user had some active connection at that date.  The remote
  55. administrator could still lie about what machines were involved
  56. and what ports the connection used (was it finger or telnet ?)
  57.  
  58. And a network hacker could easily acquire such a piece of data
  59. (e.g. via network sniffing) and use it to spoof your ident server.
  60.  
  61. And if you only encrypt the user ID (or user name), the situation
  62. is even worse.  It is quite easy in this case to guess (by simple
  63. traffic analysis) which user is associated with a given encrypted
  64. user ID, and then encryption becomes useless.
  65.  
  66.  
  67. My solution is to encrypt a packet of data that contains:
  68. - The date
  69. - The user ID
  70. - Both machine addresses
  71. - Both port numbers.
  72.  
  73. Then the piece of data becomes a proof that that user had an active
  74. connection at that date, between these machines and with these port
  75. numbers.
  76.  
  77. Problem 1 is solved by forcing the remote administrator to ask you
  78. to decrypt the data.
  79.  
  80. Problem 2 is solved by making the data unuseable except by yourself.
  81.  
  82. Problem 3 and 4 are solved by making the piece of data self-contained
  83. and unforgeable.
  84.  
  85. The biggest problem with this encryption is that the selective blocking
  86. described by Dan Bernstein becomes impossible.  An other aspect of
  87. this problem is that simple measures to counter SMTP forgery (echoing
  88. his user ID back to the SMTP cracker) is also impossible.  But
  89. identification of the hacker is still possible, with the help of the
  90. local administrator.
  91.  
  92.  
  93. Implementation.
  94.  
  95. The packet of data is a 24-byte record with the following layout:
  96.  
  97. block  bytes  contents
  98.   1      4    checksum
  99.          2    random
  100.          2    user ID
  101.   2      4    date
  102.          4    local IP address
  103.   3      4    remote IP address
  104.          2    local port number
  105.          2    remote port number
  106.  
  107. The plaintext is divided in three 8-byte blocks p0, p1, p2 and encrypted
  108. into three 8-byte blocks of cyphertext c0, c1, c2 as follows:
  109.  
  110.   c0 = E (p0)
  111.   c1 = E (p1 ^ c0)
  112.   c2 = E (p2 ^ c1)
  113.  
  114. Where E is DES with a secret key.  The secret key is stored in a file
  115. only readable by root on the local machine.
  116.  
  117. This is essentially CBC mode, without an initialization vector.
  118. The block chaining is used to prevent replacement of one block from
  119. another packet.  Replacing c0 will garble the decrypted p1;
  120. replacing c1 will garble the decrypted p1 and p2; replacing c2 will
  121. garble the decrypted p2; replacing c0 and c1 will garble p2;
  122. replacing c1 and c2 will garble p1; and replacing c0 and c2 will garble
  123. p1 and p2.  The checksum is here to ensure that the right key was used
  124. for decrypting and that the packet was not tampered with.
  125.  
  126. The decryption program is a filter that will read stdin and copy
  127. it to stdout, replacing any encrypted block with the corresponding
  128. decrypted information.  The decryption program uses the same key file
  129. as the encryption.  The file may contain several keys.  The encryption
  130. will use only the first one, but the decryption program will try each
  131. key in turn.  This way, you just have to add a new key at the beginning
  132. of the file whenever you want to change the key (you should change your key
  133. often enough, depending on the level of confidentiality that you want).
  134.  
  135. Be aware that a brute-force plaintext attack is very easy to set up
  136. against this system, and that finding the key for one packet will
  137. unlock all other packets encrypted with the same key.  Changing
  138. the key often will force the attacker to redo the brute-force attack
  139. again and again.
  140.  
  141. A key is a line of text (maximum 1023 characters) which is hashed into
  142. a 56-bit DES key.  It might be a good idea to include the date in
  143. each line of the key file.  The decryption program will only try
  144. the first 1024 keys from the key file.  Be aware that having many keys
  145. in this file will slow down the decryption considerably.  If this
  146. becomes a real problem, I could implement a simple hashing scheme to
  147. solve it.
  148.  
  149. There are a number of holes in Unix that allow users to read (parts of)
  150. any file readable by group kmem.  (The "ps" command is one such hole.)
  151. My advice is to make the key file only readable by root, and make pidentd
  152. run as root.  The probability of a hole in pidentd itself is pretty small.
  153.  
  154. WARNING:  I am not a specialist in cryptology.  It may well be the case
  155. that the absence of an IV in the CBC encryption weakens the encryption
  156. considerably.  I do not guarantee any level of confidentiality whatsoever.
  157. Go ask sci.crypt if you want some serious answers.
  158.  
  159. The DES implementation and hash function used are from the libdes
  160. library, written by Eric Young (eay@psych.psy.uq.oz.au) and available
  161. (among other sites) from ftp.funet.fi.
  162.  
  163. The code is not too well integrated with the rest of pidentd, and
  164. somebody should change the man page to document the "-C" option
  165. for encryption and the format of the key file.
  166. The code is endian-independent, but I'm not sure it would work on
  167. a 64-bit machine.
  168.  
  169. Maybe I should add an option to the decryption program for specifying
  170. an alternate key file.
  171.