Re: OpenVPN

On Mon, Oct 07, 2002 at 08:32:30PM +0200, Luca Berra wrote:
> On Sat, Oct 05, 2002 at 04:53:59PM +0200, antirez wrote:
> >Le chiavi le sposti con GPG/PGP. Il bello e' questo. La crittografia
> >asimmetrica entra ancora in gioco, ma in un contesto in cui la sua
> >complessita' implementativa non e' un grosso problema.
> cioe' aspetta,
> facendo il sommario di tutto stai semplicemente dicendo
> 
> togliamo la porzione di crittografia asimmetrica dai protocolli di
> comunicazione e utilizziamo un meccanismo 'manuale' basato su
> crittografia asimmetrica per scambiarci il secret che poi riutilizzeremo
> come chiave di sessione per le comunicazioni

Questo lo hai detto tu ;)
La parte 'manuale' entra in gioco solo la prima volta.

Con la seguente descrizione cerchero' di far capire cio' che
mi sono sforzato di dire fino ad ora.
Se non ci capiamo ancora significa semplicemente che non sono
in grado di spiegarmi (e la cosa non mi meraviglia :)

COSA

Prendo come esempio ssh, ma tutto questo vale allo stesso modo
per VPN ed altre cose che oggi utilizzano la crittografia
asimmetrica.

IN CHE CONTESTO

Esempio classico, un sysadmin deve gestire una macchina che sta
a 1000 km da casa sua. Gli serve una shell remota per accedervi,
e attualmente utilizza ssh. Lui non ha sempre lo stesso IP, o
ha necessita' di accedere da posti diversi, dunque non puo'
aprire SSH solo ad un indirizzo IP, e comunque non si fida
di questa protezione.

Legge bugtraq, ha notato come negli ultimi tempi OpenSSH sia
stato vittima di una serie di vulnerabilita'. Ha paura che qualcuno
entri sul suo server illecitamente utilizzando una qualche
vulnerabilita' di OpenSSH, magari non conosciuta dalla comunita'.
Matura ogni giorno di piu' l'idea che nel suo contesto di
persona, o di poche persone, che necessitano di accedere da
remoto ad un server (il 90% dell'utilizzo di ssh, non siete
d'accordo?) e' troppo insicuro utilizzare un protocollo complesso
per l'autenticazione. Vuole qualcosa che garantisca l'accesso solo
alle persone che sono dotate di una chiave, ma vuole essere
certo di minimizzare il numero di righe di codice a cui e' possibile
avere accesso dall'esterno senza una chiave valida.

LA SOLUZIONE

Invece di inventarsi una soluzione nuova, semplicemente utilizza
la sana crittografia simmetrica senza inventare nulla di nuovo
(infatti non capisco una email di questo thread in cui mi
hanno scritto "non e' nulla di nuovo". Io uso cose vecchie).

Scrive un nuovo demone per shell cifrate dal funzionamento molto
semplice.

Il server e il client condividono una chiave simmetrica, che 
chiamiamo MASTER. Questa chiave deve essere scambiata la prima
volta _soltanto_, con GPG / PGP / SCP, o copiata a mano al momento
della installazione del server, cifrata con una passphrase, e
messa nel dischetto da portarsi a casa, a 1000 km di distanza.

Il client si connette al server, il server gli spara una lunga
stringa pseudo-random. Una parte di questa si utilizza per
generare tramite HMAC la chiave di sessione per cifrare lo
stream in un verso, l'altra parte per creare la chiave di sessione
per cifrare nell'altro verso.

Inoltre viene generata una chiave per fare l'HMAC dei dati.

A questo punto, l'unica cosa che e' accaduta a livello del protocollo
e' che il client ha ricevuto una serie di bytes casuali. Il
server e il client hanno utilizzato la loro segretissima master-key
per creare le chiavi di sessione e la secret per l'HMAC.

Ora il client deve dimostrare di essere in possesso della chiave
valida. Ci sono mille modi per farlo, ma al nostro sysadmin ne
interessa uno semplice. Banalmente il server ha spedito 128bit*4
bit di numero pseudo-casuale. I primi tre 128bit sono stati utilizzati
per creare le chiavi, il quarto e' una sfida. Il client deve
calcolare l'HMAC di questi ultimi 128 bit e spedirli al client.
La risposta sara' corretta solo se il client e' in possesso
della master key.

Sono trascorse 10 righe di codice, e il server e' gia' pronto a
decifrare con la chiave ottenuta tutto cio' che arriva dal
client. Questo significa in parole povere che anche se a questo
punto ci fosse una vulnerabilita' nel codice di autenticazione,
se il client non possiede la master key valida puo' iniettare
solo spazzatura casuale, con poche possibilita' di riuscita.

CHIAVI DI SESSIONE E REKEY

Il nostro sysadmin e' assolutamente convinto che cifrare un sacco
di dati con un buon algoritmo simmetrico senza eseguire il rekey
e' 1000 volte piu' sicuro di avere un protocollo complesso, perche'
negli ultimi due anni non sono state trovate nuove vulnerabilita'
fondamentali di block cipher blasonati mentre sono state trovate
alcune vulnerabilita' di openssh, di openssl e cosi' via. Tuttavia
sa che ovunque c'e' qualcuno pronto a dire che senza il rekey
la sua soluzione non vale nulla, dunque lo implementa in maniera
semplice.

Banalmente, ogni tot di byte trasmessi, il server spedisce 128*3
bit di nuovi dati pseudo-casuali, che vengono riutilizzati assieme
alla chiave di sessione per generare tre nuove chiavi di
Input/Output/Hmac. Si va avanti cosi' all'infinito.

SULLA MANCANZA DI QUALCHE TIPO DI SICUREZZA DI QUESTO PROTOCOLLO
RISPETTO AD RSA

Secondo me questa e' una bufala. Mi sono sentito dire:

"ma se la master key viene compromessa sei fritto! il tuo sistema
crittografico non recupera mai da un tale evento".

Piu' che vero. Questo sistema recupera solo se e' compromessa
la chiave di sessione. Ma non e' affatto vero che le cose
sono diverse per RSA, semplicemente con RSA tutto si rompe quando
viene compromessa la chiave privata del client.

Se rubano il segreto per eccellenza e utilizzano degli attacchi
passivi come sniffare e decifrare le sessioni, qual'e' il protocollo
crittografico che recupera o che puo' fare il detect dell'attacco?

CONCLUSIONE

Non penso che questa soluzione sia valida in tutti i contesti,
ne che sia certamente giusta. Magari mi sfuggono particolari
importanti, o semplicemente non conosco abbastanza al crittografia
per dire cose sensata su questo argomento. Ma, per quello che
posso capire, questo sistema e' *nella realta'* piu' sicuro
di OpenSSH, perche' e' estremamente meno vulnerabile ai problemi
che derivano da un baco nel software del demone.

Un client senza una chiave valida e' capace di aprire una connessione
e 'toccare' pochissime righe di codice selezionate che fanno
operazioni banali, come leggere da /dev/urandom, fare un HMAC. Tutte
cose con buffer a lunghezza fissa, e cosi' via.

A me non importa niente di fare il tifo per una soluzione tecnologica
o per l'altra. Se il punto e' stare sicuri evidentemente c'e' qualcosa
da rivedere nei software e negli schemi utilizzati piu' o meno da
tutti attualmente (io il primo). Siccome non ho alcuna idea brillante
mi affido alle idee vecchie e provate, ovvero che semplificare il
codice rendere il mio sistema piu' robusto.

giusto per chiudere il thread,
ciao,
Salvatore

-- 
Salvatore Sanfilippo <antirez at invece dot org> s/at/@/ s/dot/\./
          finger antirez@tella.alicom.org for PGP key
      "Don't worry about what anybody else is going to do.
 The best way to predict the future is to invent it." (Alan Kay)

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List