www.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,2001 Guus Sliepen <guus@sliepen.warande.net>,
   4              2000,2001 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.4 2001/01/07 17:08:03 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    send_metakey(R)
  31                         send_metakey(R)
  32    send_ack(u)
  33                         send_ack(u)
  34    ---------------------------------------
  35    Other requests(E)...
  36
  37    (u) Unencrypted,
  38    (R) RSA,
  39    (H) SHA1,
  40    (E) Encrypted with symmetric cipher.
  41
  42 See section 4 for a detailed example version of the authentication.
  43
  44 Authentication in tinc will be done in a way that is very similar to the way
  45 the SSH (Secure SHell) authentication protocol works. It is based on public
  46 key cryptography.
  47
  48 Every tinc host has its own public/private key pair. Suppose there are two
  49 tinc hosts, A and B. If A and B trust each other, they store a copy of
  50 eachothers public key (in the same way passphrases were stored in versions
  51 of tinc <= 1.0pre2). They know these public keys beforehand, and the origin
  52 of the public keys has to be known for sure.
  53
  54 To make sure that when a connection is made from A to B that B knows A is
  55 really who he claims to be, B encrypts a totally random string of bytes with
  56 A's public key. B also calculates the hash value from the unencrypted random
  57 string. B then sends the encrypted string to A. A then has to decrypt the
  58 string, calculate the hash value from that string and send it back to B. Since
  59 only he who possesses A's private key can decrypt this string, only he can send
  60 back the correct hash value. So, if B receives the same hash value he
  61 calculated himself, he knows for sure A is A.
  62
  63 Both SSH and tinc use RSA for the public key cryptography. SSH uses MD5 as a
  64 secure hash algorithm, tinc uses SHA1. The reason for our choice of SHA1 is
  65 the fact that SHA1 is 160 bits instead of 128 (MD5), which makes brute force
  66 attacks harder. Also, the OpenSSL documentation recommends SHA1.
  67
  68 2.  Key exchange
  69 ----------------
  70
  71 The rest of the meta connection in tinc will be encrypted with a symmetric
  72 block cipher, since RSA is not really suited for this. When a connection is
  73 made, both sides have to agree on a key for this block cipher. To make sure
  74 that this key exchange is also done securely, and no man-in-the-middle attack
  75 is possible, RSA would be the best choice for exchanging keys.
  76
  77 3.  Symmetric cipher
  78 --------------------
  79
  80 Since the generalized encryption functions of OpenSSL are used, any symmetric
  81 cipher that is available in OpenSSL could possibly be used. The default however
  82 will be Blowfish. Blowfish is widely in use and still has not been cracked
  83 today (as far as we know). It also is one of the faster ciphers available.
  84
  85 4.  Detailed "example" of communication
  86 ---------------------------------------
  87
  88 Tinc uses a peer-to-peer protocol, but during the authentication phase we will
  89 make a distinction between a server (a tinc daemon listening for incoming
  90 connections) and a client (a tinc daemon that is trying to connect to the tinc
  91 daemon playing server).
  92
  93 The message strings here are kept short for clarity. The real length of the
  94 exchanged messages is indicated. The capital words ID, CHALLENGE, CHAL_REPLY,
  95 META_KEY and ACK are in reality replaced by the numbers 0, 1, 2, 3 and 4
  96 respectively.
  97
  98 daemon  message
  99 --------------------------------------------------------------------------
 100 server  <listening for connection>
 101 client  <tries to connect>
 102 server  <accepts connection>
 103 client  ID client 8 0
 104               |   | +-> options
 105               |   +---> version
 106               +-------> name of tinc daemon
 107 server  CHALLENGE 57fb4b2ccd70d6bb35a64c142f47e61d
 108                   \______________________________/
 109                                  +-> KEYLENGTH bits totally random string, encrypted
 110                                      with client's public RSA key
 111 client  CHAL_REPLY 191e23
 112                       +-> 160 bits SHA1 value of the complete decrypted
 113                           CHALLENGE sent by the server
 114 server  ID server 8 0
 115               |   | +-> options
 116               |   +---> version
 117               +-------> name of tinc daemon
 118 client  CHALLENGE da02add1817c1920989ba6ae2a49cecb
 119                   \______________________________/
 120                                  +-> KEYLENGTH bits totally random string, encrypted
 121                                      with server's public RSA key
 122 server  CHAL_REPLY 2bdeed
 123                       +-> 160 bits SHA1 value of the complete decrypted
 124                           CHALLENGE sent by the client
 125 client  META_KEY 5f0823a93e35b69e7086ec7866ce582b
 126                   \______________________________/
 127                                  +-> KEYLENGTH bits totally random string, encrypted
 128                                      with server's public RSA key
 129 server  META_KEY 6ab9c1640388f8f045d1a07f8a672630
 130                   \______________________________/
 131                                  +-> KEYLENGTH bits totally random string, encrypted
 132                                      with client's public RSA key
 133 client  ACK
 134 server  ACK
 135 --------------------------------------------------------------------------
 136
 137 When the server receives the ACK from the client, it should prepare itself
 138 for the fact that any subsequent data will be encrypted with the key the server
 139 sent itself in the META_KEY. Ofcourse, this key is taken from the decrypted
 140 version of that META_KEY, so that we will know for sure only the real client
 141 can send us messages. The same goes for the client when it receives an ACK.
 142
 143 5.  Encryption of VPN packets
 144 -----------------------------
 145
 146 The VPN packets are also encrypted, but with a different key than the one used
 147 for the meta connection. The reason is that VPN packets can also come from
 148 other clients which do not have a meta connection with server. Each tinc daemon
 149 propagates (on request) a separate key for packets that it receives. This key
 150 is a random string, generated on the fly. Since it is exchanged using the meta
 151 connection, this key itself will be encrypted.