tinc-vpn.org Git - tinc/blob - doc/SECURITY

   1 This is the security documentation for tinc, a Virtual Private Network daemon.
   2
   3    Copyright 2000 Guus Sliepen <guus@sliepen.warande.net>,
   4              2000 Ivo Timmmermans <itimmermans@bigfoot.com>
   5
   6    Permission is granted to make and distribute verbatim copies of
   7    this documentation provided the copyright notice and this
   8    permission notice are preserved on all copies.
   9
  10    Permission is granted to copy and distribute modified versions of
  11    this documentation under the conditions for verbatim copying,
  12    provided that the entire resulting derived work is distributed
  13    under the terms of a permission notice identical to this one.
  14
  15    $Id: SECURITY,v 1.1.2.3 2000/09/25 20:08:50 guus Exp $
  16
  17
  18 1.  Authentication
  19 ------------------
  20
  21 The authentication protocol (see protocol.c for the up-to-date version) is:
  22
  23    Client               Server
  24    send_id(u)
  25                         send_challenge(R)
  26    send_chal_reply(H)
  27                         send_id(u)
  28    send_challenge(R)
  29                         send_chal_reply(H)
  30    ---------------------------------------
  31    Any negotations about the meta protocol
  32    encryption go here(u).
  33    ---------------------------------------
  34    send_ack(u)
  35                         send_ack(u)
  36    ---------------------------------------
  37    Other requests(E)...
  38
  39    (u) Unencrypted,
  40    (R) RSA,
  41    (H) SHA1,
  42    (E) Encrypted with symmetric cipher.
  43
  44 See section 4 for a detailed example version of the authentication.
  45
  46 Authentication in tinc will be done in a way that is very similar to the way
  47 the SSH (Secure SHell) authentication protocol works. It is based on public
  48 key cryptography.
  49
  50 Every tinc host has its own public/private key pair. Suppose there are two
  51 tinc hosts, A and B. If A and B trust each other, they store a copy of
  52 eachothers public key (in the same way passphrases were stored in versions
  53 of tinc <= 1.0pre2). They know these public keys beforehand, and the origin
  54 of the public keys has to be known for sure.
  55
  56 To make sure that when a connection is made from A to B that B knows A is
  57 really who he claims to be, B encrypts a totally random string of bytes with
  58 A's public key. B also calculates the hash value from the unencrypted random
  59 string. B then sends the encrypted string to A. A then has to decrypt the
  60 string, calculate the hash value from that string and send it back to B. Since
  61 only he who possesses A's private key can decrypt this string, only he can send
  62 back the correct hash value. So, if B receives the same hash value he
  63 calculated himself, he knows for sure A is A.
  64
  65 Both SSH and tinc use RSA for the public key cryptography. SSH uses MD5 as a
  66 secure hash algorithm, tinc uses SHA1. The reason for our choice of SHA1 is
  67 the fact that SHA1 is 160 bits instead of 128 (MD5), which makes brute force
  68 attacks harder. Also, the OpenSSL documentation recommends SHA1.
  69
  70 2.  Key exchange
  71 ----------------
  72
  73 The rest of the meta connection in tinc will be encrypted with a symmetric
  74 block cipher, since RSA is not really suited for this. When a connection is
  75 made, both sides have to agree on a key for this block cipher. To make sure
  76 that this key exchange is also done securely, and no man-in-the-middle attack
  77 is possible, RSA would be the best choice for exchanging keys.
  78
  79 Instead of doing RSA encryption again, tinc will use a part of the random
  80 string that was exchanged during the authentication phase as the key for the
  81 symmetric cipher. Some symmetric ciphers require a random initialisation vector
  82 for improved security. This vector can be taken from the random string as well.
  83
  84 Is this secure? I (Guus Sliepen) think at this moment that it is:
  85
  86 - Since the random string cannot be decrypted by anyone eavesdropping or
  87   playing man-in-the-middle, the symmetric key cannot be known by sniffing.
  88 - The unencrypted returned hash value is supposed to be cryptographically
  89   secure. Furthermore, it can only at most give a way 160 bits of information
  90   from the complete random string which is longer than the key for the
  91   symmetric cipher, so very few bits will actualy contain information about
  92   the symmetric cipher key alone, if any.
  93 - If the RSA encryption is cracked, the rest of the communications can be
  94   decrypted anyway.
  95 - If the symmetric cipher encryption is cracked without using the information
  96   from the encrypted random strings or the hash values, this still won't give
  97   the full plaintext for the random string, so it won't facilitate a known-
  98   plaintext attack on the RSA encryption.
  99 - RSA and symmetric ciphers are fundamentally different. It is very unlikely
 100   that the overlap of both will create any interference that will facilitate
 101   an easier-than-brute-force attack.
 102
 103 Other options for key exchange could be:
 104
 105 * A second exchange of RSA encrypted random strings.
 106   This is equal to the former scheme just without knowing the hash value of
 107   the unecrypted random string. Information theory tells that two seperate
 108   RSA messages are as secure as one if the total amount of bits sent is the
 109   same, so enlarging the challenge will make one exchange just as secure as
 110   two seperate exchanges.
 111
 112 * Diffie-Hellman with RSA signing.
 113   This should be very secure, but there are a lot of pitfalls with using both
 114   encryption with public keys and private keys together with the same keypair.
 115
 116 * Diffie-Hellman with passphrases.
 117   This is what tinc <= 1.0pre2 used to do. Passphrases are secret, exchanging
 118   them must be done with great care, nobody may eavesdrop. Exchanging public
 119   keys on the other hand is much safer, everybody may eavesdrop, just as long
 120   as you are sure that the public key itself belongs to the right owner.
 121
 122 3.  Symmetric cipher
 123 --------------------
 124
 125 Since the generalized encryption functions of OpenSSL are used, any symmetric
 126 cipher that is available in OpenSSL could possibly be used. The default however
 127 will be Blowfish. Blowfish is widely in use and still has not been cracked
 128 today (as far as we know). It also is one of the faster ciphers available.
 129
 130 4.  Detailed "example" of communication
 131 ---------------------------------------
 132
 133 Tinc uses a peer-to-peer protocol, but during the authentication phase we will
 134 make a distinction between a server (a tinc daemon listening for incoming
 135 connections) and a client (a tinc daemon that is trying to connect to the tinc
 136 daemon playing server).
 137
 138 The message strings here are kept short for clarity. The real length of the
 139 exchanged messages is indicated. The capital words ID, CHALLENGE, CHAL_REPLY
 140 and ACK are in reality replaced by the numbers 1, 2, 3 and 4 respectively.
 141
 142 daemon  message
 143 --------------------------------------------------------------------------
 144 server  <listening for connection>
 145 client  <tries to connect>
 146 server  <accepts connection>
 147 client  ID client 8 0
 148               |   | +-> options
 149               |   +---> version
 150               +-------> name of tinc daemon
 151 server  CHALLENGE 57fb4b2ccd70d6bb35a64c142f47e61d
 152                   \________/\__/
 153                        |      +----> 64 bits initial vector and
 154                        +-----------> 448 bits symmetric cipher key for meta
 155                                      data sent to the server
 156                   \______________________________/
 157                                  +-> 2048 bits totally random string, encrypted
 158                                      with client's public RSA key
 159 client  CHAL_REPLY 191e23
 160                       +-> 160 bits SHA1 value of the complete decrypted
 161                           CHALLENGE sent by the server
 162 server  ID server 8 0
 163               |   | +-> options
 164               |   +---> version
 165               +-------> name of tinc daemon
 166 client  CHALLENGE da02add1817c1920989ba6ae2a49cecb
 167                   \________/\__/
 168                        |      +----> 64 bits initial vector and
 169                        +-----------> 448 bits symmetric cipher key for meta
 170                                      data sent to the client
 171                   \______________________________/
 172                                  +-> 2048 bits totally random string, encrypted
 173                                      with server's public RSA key
 174 server  CHAL_REPLY 2bdeed
 175                       +-> 160 bits SHA1 value of the complete decrypted
 176                           CHALLENGE sent by the client
 177 client  ACK
 178 server  ACK
 179 --------------------------------------------------------------------------
 180
 181 When the server receives the ACK from the client, it should prepare itself
 182 for the fact that any subsequent data will be encrypted with the key the server
 183 sent itself in the CHALLENGE. Ofcourse, this key is taken from the decrypted
 184 version of that CHALLENGE, so that we will know for sure only the real client
 185 can send us messages. The same goes for the client when it receives an ACK.