X-Git-Url: https://www.tinc-vpn.org/git/browse?p=tinc;a=blobdiff_plain;f=doc%2FSECURITY;h=670135c73bbe7e0a2e67dcc9d2f88e34f5bb20b4;hp=a885b46d810c13ab76df694f6e7305e3efa8447c;hb=e12d41f39d8dd1cd30058d08effd2e5b66cdd4fd;hpb=2863134a4113b7805a662f45a21a1be0ae9606cb diff --git a/doc/SECURITY b/doc/SECURITY index a885b46d..670135c7 100644 --- a/doc/SECURITY +++ b/doc/SECURITY @@ -1,7 +1,7 @@ This is the security documentation for tinc, a Virtual Private Network daemon. - Copyright 2000 Guus Sliepen , - 2000 Ivo Timmmermans + Copyright 2000,2001 Guus Sliepen , + 2000,2001 Ivo Timmmermans Permission is granted to make and distribute verbatim copies of this documentation provided the copyright notice and this @@ -12,17 +12,40 @@ This is the security documentation for tinc, a Virtual Private Network daemon. provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. - $Id: SECURITY,v 1.1.2.1 2000/09/17 19:57:39 guus Exp $ + $Id: SECURITY,v 1.1.2.4 2001/01/07 17:08:03 guus Exp $ 1. Authentication ------------------ +The authentication protocol (see protocol.c for the up-to-date version) is: + + Client Server + send_id(u) + send_challenge(R) + send_chal_reply(H) + send_id(u) + send_challenge(R) + send_chal_reply(H) + send_metakey(R) + send_metakey(R) + send_ack(u) + send_ack(u) + --------------------------------------- + Other requests(E)... + + (u) Unencrypted, + (R) RSA, + (H) SHA1, + (E) Encrypted with symmetric cipher. + +See section 4 for a detailed example version of the authentication. + Authentication in tinc will be done in a way that is very similar to the way the SSH (Secure SHell) authentication protocol works. It is based on public key cryptography. -Every tinc host has it's own public/private key pair. Suppose there are two +Every tinc host has its own public/private key pair. Suppose there are two tinc hosts, A and B. If A and B trust each other, they store a copy of eachothers public key (in the same way passphrases were stored in versions of tinc <= 1.0pre2). They know these public keys beforehand, and the origin @@ -51,42 +74,78 @@ made, both sides have to agree on a key for this block cipher. To make sure that this key exchange is also done securely, and no man-in-the-middle attack is possible, RSA would be the best choice for exchanging keys. -Instead of doing RSA encryption again, tinc will use a part of the random -string that was exchanged during the authentication phase as the key for the -symmetric cipher. Some symmetric ciphers require a random initialisation vector -for improved security. This vector can be taken from the random string as well. - -Is this secure? I (Guus Sliepen) think at this moment that it is: - -- Since the random string cannot be decrypted by anyone eavesdropping or - playing man-in-the-middle, the symmetric key cannot be known by sniffing. -- The unencrypted returned hash value is supposed to be cryptographically - secure. Furthermore, it can only at most give a way 160 bits of information - from the complete random string which is longer than the key for the - symmetric cipher, so very few bits will actualy contain information about - the symmetric cipher key alone, if any. -- If the RSA encryption is cracked, the rest of the communications can be - decrypted anyway. -- If the symmetric cipher encryption is cracked without using the information - from the encrypted random strings or the hash values, this still won't give - the full plaintext for the random string, so it won't facilitate a known- - plaintext attack on the RSA encryption. -- RSA and symmetric ciphers are fundamentally different. It is very unlikely - that the overlap of both will create any interference that will facilitate - an easier-than-brute-force attack. - -Other options for key exchange could be: - -* A second exchange of RSA encrypted random strings. - This is equal to the former scheme just without knowing the hash value of - the unecrypted random string. - -* Diffie-Hellman with RSA signing. - This should be very secure, but there are a lot of pitholes with using both - encryption with public keys and private keys together with the same keypair. - -* Diffie-Hellman with passphrases. - This is what tinc <= 1.0pre2 used to do. Passphrases are secret, exchanging - them must be done with great care, nobody may eavesdrop. Exchanging public - keys on the other hand is much safer, everybody may eavesdrop, just as long - as you are sure that the public key itself belongs to the right owner. +3. Symmetric cipher +-------------------- + +Since the generalized encryption functions of OpenSSL are used, any symmetric +cipher that is available in OpenSSL could possibly be used. The default however +will be Blowfish. Blowfish is widely in use and still has not been cracked +today (as far as we know). It also is one of the faster ciphers available. + +4. Detailed "example" of communication +--------------------------------------- + +Tinc uses a peer-to-peer protocol, but during the authentication phase we will +make a distinction between a server (a tinc daemon listening for incoming +connections) and a client (a tinc daemon that is trying to connect to the tinc +daemon playing server). + +The message strings here are kept short for clarity. The real length of the +exchanged messages is indicated. The capital words ID, CHALLENGE, CHAL_REPLY, +META_KEY and ACK are in reality replaced by the numbers 0, 1, 2, 3 and 4 +respectively. + +daemon message +-------------------------------------------------------------------------- +server +client +server +client ID client 8 0 + | | +-> options + | +---> version + +-------> name of tinc daemon +server CHALLENGE 57fb4b2ccd70d6bb35a64c142f47e61d + \______________________________/ + +-> KEYLENGTH bits totally random string, encrypted + with client's public RSA key +client CHAL_REPLY 191e23 + +-> 160 bits SHA1 value of the complete decrypted + CHALLENGE sent by the server +server ID server 8 0 + | | +-> options + | +---> version + +-------> name of tinc daemon +client CHALLENGE da02add1817c1920989ba6ae2a49cecb + \______________________________/ + +-> KEYLENGTH bits totally random string, encrypted + with server's public RSA key +server CHAL_REPLY 2bdeed + +-> 160 bits SHA1 value of the complete decrypted + CHALLENGE sent by the client +client META_KEY 5f0823a93e35b69e7086ec7866ce582b + \______________________________/ + +-> KEYLENGTH bits totally random string, encrypted + with server's public RSA key +server META_KEY 6ab9c1640388f8f045d1a07f8a672630 + \______________________________/ + +-> KEYLENGTH bits totally random string, encrypted + with client's public RSA key +client ACK +server ACK +-------------------------------------------------------------------------- + +When the server receives the ACK from the client, it should prepare itself +for the fact that any subsequent data will be encrypted with the key the server +sent itself in the META_KEY. Ofcourse, this key is taken from the decrypted +version of that META_KEY, so that we will know for sure only the real client +can send us messages. The same goes for the client when it receives an ACK. + +5. Encryption of VPN packets +----------------------------- + +The VPN packets are also encrypted, but with a different key than the one used +for the meta connection. The reason is that VPN packets can also come from +other clients which do not have a meta connection with server. Each tinc daemon +propagates (on request) a separate key for packets that it receives. This key +is a random string, generated on the fly. Since it is exchanged using the meta +connection, this key itself will be encrypted.