La crescente richiesta di connessioni crittografate che garantiscano per i dati trasmessi in rete la confidenzialità (nessuno oltre il legittimo destinatario può conoscerne il contenuto), la veridicità (firma elettronica) e l’integrità (non è possibile alterarne il contenuto ponendosi nel mezzo dei due end-point della comunicazione) ha portato alla diffusione di algoritmi crittografici asimmetrici meglio noti come “algoritmi a chiave pubblica”. Contrariamente alla crittografia a chiave simmetrica, in quella a chiave pubblica viene utilizzata una coppia di chiavi duali: ciò che è criptato con una può essere decriptato solo e soltanto con l’altra e viceversa. Una delle due chiavi prende il nome di chiave privata e l’altra di chiave pubblica. Così come i nomi stessi suggeriscono, la chiave privata è segreta e pertanto va custodita gelosamente dal proprietario, quella pubblica invece va distribuita agli interlocutori.
Se un utente A vuole mandare dei dati segreti a un utente B, allora A dovrà criptare i dati con la chiave pubblica di B che essendo l’unico possessore della chiave privata corrispondente potrà decriptarli. È così risolto il problema della confidenzialità.
Supponiamo ora che l’utente A voglia essere sicuro che i dati ricevuti siano inequivocabilmente provenienti da B e che non siano stati manomessi durante il tragitto: B deve calcolare un hash dei dati da spedire e criptarlo con la sua chiave privata. Quando A riceve i dati e l’hash criptato, decripta quest’ultimo con la chiave pubblica di B e lo confronta con l’hash che calcola lui stesso sui dati giunti. Se i due hash sono uguali allora A può essere sicuro dell’identità di B e dell’integrità dei dati. In particolare, se i dati spediti da B ad A sono un documento elettronico il suddetto procedimento prende il nome di “firma digitale”.
La crittografia asimmetrica è tanto più forte quanto maggiore è la certezza che la chiave pubblica che si possiede appartenga realmente all’interlocutore a cui i messaggi sono destinati o di cui si vuole accertare la provenienza. La cosa migliore da fare sarebbe scambiarsi personalmente le chiavi pubbliche, ma in una grande organizzazione non sempre ciò è possibile. Nasce pertanto l’esigenza di dotare tali strutture di una PKI (Public Key Infrastructure). Le PKI si basano sull’uso dei certificati, cioè di attestati firmati digitalmente che contengono i dati di identificazione dell’utente (o del server), la sua chiave pubblica e l’identificazione dell’autorità di certificazione che firma il certificato. Naturalmente la Certification Authority (più in breve CA) che firma i certificati deve essere fidata e la sua chiave pubblica distribuita in maniera sicura.
Zeroshell implementa una CA per l’emissione e la gestione di certificati digitali X.509 v3. In particolare permette di:
- generare coppie di chiavi RSA da 512, 1024 e 2048 bit;
- generare certificati X509.v3 relativi a utenti e server;
- rinnovare un certificato;
- esportare un certificato (con o senza la relativa chiave privata) nei formati PEM, DER, e PKCS#12;
- revocare un certificato prima della scadenza;
- gestire la CRL (Certificate Revocation List) ovvero l’elenco dei certificati revocati firmato dalla CA;
- generare la chiave privata e il certificato della Certification Authority se si tratta di una Root CA o importarli se si tratta di una CA intermedia;
Con l’uso dei certificati X509 v3 e del protocollo SSL (Secure Socket Layer), sviluppato inizialmente da Netscape ma che nella versione 3.0 è stato standardizzato dalla IETF e ha preso il nome di TLS 1.0 (Transport Layer Security), è possibile creare dei tunnel end-to-end poggiati sul livello di trasporto TCP ed ottenere un livello di sessione sicuro. Esempi di protocolli di sessione incapsulati in tunnel SSL sono: https (secure http), imaps (secure IMAP), telnets (secure telnet), smtps (secure SMTP), ldaps (secure LDAP), pop3s (secure pop3) e nntps (secure USENET transport protocol). Il protocollo TLS non si limita a criptare i dati che passano nel tunnel, ma, quando richiesto, garantisce anche l’autenticità del client e del server (mutua autenticazione). Si noti poi, che gli algoritmi asimmetrici hanno una complessità computazionale molto maggiore di quelli simmetrici. Per questo motivo nel protocollo SSL, grazie a un primo scambio di dati crittografati asimmetricamente, client e server si accordano su un algoritmo simmetrico e sulla relativa chiave di sessione con cui criptare simmetricamente il resto della conversazione.
Zeroshell utilizza SSL/TLS per i seguenti scopi:
- creare con https delle sessioni sicure tra l’host Zeroshell e l’host su cui gira il web browser da cui si accede all’interfaccia amministrativa;
- nel protocollo 802.1x tramite RADIUS per l’autenticazione di connessioni Wireless con EAP-TLS e PEAP;
- per incapsulare trame Ethernet in tunnel crittografati creando così delle VPN lan-to-lan;
- per autenticare connessioni IPsec in cui incapsulare tunnel L2TP creando VPN L2TP/IPsec di tipo Road Warrior.