Supponiamo che Fred e Barney vogliano scambiarsi messaggi crittografati. Per poterlo fare con la crittografia simmetrica entrambi devono conoscere una chiave segreta. Il problema è che per scambiarsi questa chiave, saranno costretti ad incontrarsi o a trovare un alternativo metodo sicuro per scambiarsela.

Nella crittografia asimmetrica, come già detto, Fred e Barney hanno due chiavi ciascuno. Chiameremo queste chiavi Fprivata e Fpubblica per Fred. Saranno invece Bprivata e Bpubblica quelle di Barney. Fpubblica e Bpubblica sono conosciute in tutto il mondo: sono, appunto, pubbliche. Fprivata e Bprivata sono gelosamente nascoste e conosciute solo dai legittimi proprietari.

Il bello di queste chiavi è che quello che fa una, l'altra lo disfa! Perciò, se Fred vuole scrivere un messaggio a Barney, lo renderà segreto grazie alla chiave pubblica di Barney e Barney lo renderà dinuovo leggibile grazie alla sua chiave privata.

Viceversa, Barney può usare la sua chiave privata per crittografare un messaggio indirizzato a Fred. Tutto il mondo potrà leggere questo messaggio perchè per renderlo chiarò si dovrà utilizzare la chiave pubblica di Fred. A cosa serve allora che Fred crittografi il messggio ? Serve a garantire che chiunque abbia crittografato il messaggio possegga anche la chiave privata di Fred e, in un mondo perfetto, solo Fred ha quella chiave.

Riassumendo:

• Se voglio mandare un messaggio privato al signor Rossi, uso la sua chiave pubblica per crittografarlo
• Se voglio che il Signor Rossi sia certo della mia identità, uso la mia chiave privata per crittografare un messaggio

Primo utilizzo della crittografia asimmetrica

I concetti della crittografia asimmetrica sono molto utilizzati ai giorni nostri. Uno dei più utilizzati è quello dell'identificazione della persona. Tra i programmi che utilizzano le chiavi pubbliche e private per funzionare vi è {it:OpenSSH}. Facciamo quindi un esmepio con questo, lasciatemelo dire, grandioso pezzo di software.

Per prima cosa installiamo quel che ci server. Nel caso non sia già installato, installate il server ssh:

luca@giasone:~$ sudo apt-get install openssh-server openssh-client

Per chi non lo sapesse, un server ssh è un servizio che permette di avere una console a riga di comando su di una macchina remota.

Ci vorrà qualche secondo affinchè il server generi una coppia di chiavi per se (anche lui si dovrà identificare) e alla fine dovreste avere il vostro server in funzione ed una serie di utili comandi a portata di mano.

Potete provare se ssh sia effettivamente in funzione:

luca@giasone:~$ ssh localhost
The authenticity of host 'localhost (::1)' can't be established.
RSA key fingerprint is c2:20:bb:b2:35:68:80:27:a2:07:0f:96:6a:ee:3d:c0.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
luca@localhost's password:
Linux giasone 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686
[...righe ommesse per brevità...]
Last login: Wed Jun 10 12:48:27 2009
luca@giasone:~$ exit
logout
Connection to localhost closed.
luca@giasone:~$

Alla riga 3 vediamo che il server si è presentato. Ci ha fornito "l'impronta" della sua chiave pubblica (vedremo più avanti a cosa serva).
Successivamente ci è stato chiesto di autenticarci (ho immesso la mia password). Una volta autenticati con successo, abbiamo avuto a nostra disposizione una nuova shell. Il fatto che sia nuova lo si può notare a partire dalla riga 10. Ho dato il comando exit e, invece di chiudermisi completamente la shell, sono tornato sulla mia vecchia shell di partenza.

Facciamo fruttare le chiavi pubbliche e private. Per prima cosa creiamoci una coppia di chiavi:

luca@giasone:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/luca/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/luca/.ssh/id_dsa.
Your public key has been saved in /home/luca/.ssh/id_dsa.pub.
The key fingerprint is:
38:ec:53:76:cd:70:4c:e2:a8:5c:9e:04:71:2a:12:53 luca@giasone
The key's randomart image is:
+--[ DSA 1024]----+
|  o.E o.. . .    |
|   o   + o +     |
|  . . . + o o    |
|   . + * . =     |
|      * S . o    |
|     . + .       |
|      o          |
|       .         |
|                 |
+-----------------+
luca@giasone:~$

Con questo comando abbiamo chiesto di creare una coppia di chiavi di tipo dsa (-t dsa) ovvero generate tramite il {it:Digital Signature Algorithm}. La coppia di chiavi sarà salvata, di default, nella cartella $HOME/.ssh in due file id_dsa (la chiave privata) e id_dsa.pub (la chiave pubblica).

Abbiamo la nostra coppia di chiavi. Dobbiamo dire al server ssh di usarle per autenticarci. Non ci sarà bisogno di fare configurazioni del server poichè, di solito, questo è gia configurato per accettare questo tipo di autenticazione. Comunque, per chi fosse interessato, il file di configurazione del server (si trova in /etc/ssh/sshd_config) dovrebbe riportare i seguenti parametri:


PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

La prima ci dice che è attiva l'autenticazione tramite chiave pubblica, la seconda (è commentata poichè è la configurazione di default e non richiede la sua esplicita scrittura) ci dice che il server dovrà cercare la chiave pubblica dell'utente che vuole accedere nel file $HOME/.ssh/authorized_keys.
Andiamo quindi nella cartella $HOME/.ssh/ e vediamo cosa ci troviamo:

luca@giasone:~$ cd $HOME/.ssh
luca@giasone:~/.ssh$ ls
config  id_dsa  id_dsa.keystore  id_dsa.pub  known_hosts
luca@giasone:~/.ssh$ cat id_dsa.pub > authorized_keys
luca@giasone:~/.ssh$ ls
authorized_keys  config  id_dsa  id_dsa.keystore  id_dsa.pub  known_hosts
luca@giasone:~/.ssh$

Notate il file della chiave privata (id_dsa), quello della chiave pubblica (id_dsa.pub). Alla riga 4 ho scritto il contenuto del file della chiave pubblica all'interno del file authorized_keys, quello che (come detto sopra) il server andrà a cercare er autorizzare l'accesso.
Ricapitolando:

1. noi ci connetteremo al server ssh identificandoci (più o meno) con la chiave privata;
2. il server controllerà se in $HOME/.ssh/authorized_keys vi è una chiave pubblica associata alla nostra chiave privata;
3. in caso positivo ci permetterà di accedere immediatamente;
4. in caso negativo ci chiederà la password.

Vediamo che tutto funzioni:

luca@giasone:~$ ssh localhost
Linux giasone 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686

To access official Ubuntu documentation, please visit:
http://help.ubuntu.com/

Last login: Thu Oct 29 20:18:55 2009 from localhost
luca@giasone:~$

Perfetto! Nessuna password ci è stata chiesta.
Abbiamo visto un primo esempio di utilizzo di chiavi private e pubbliche. Nel prossimo articolo vedremo i concetti di Certification Authority, certificati e attendibilità.

Per ora e tutto!