La crittografia e il suo uso quotidiano nell'informatica

http://www.tronweb.it/docs/crittografia
Giovanni Benetti & Diego Giorgini
06/03/2007 - Corso di crittografia

Introduzione alla crittografia

La crittografia è una tecnica attraverso la quale un messaggio originale viene reso illeggibile secondo dei processi (matematici o logici) reversibili, permettendo al destinatario di recuperare i dati attraverso un procedimento noto solo a lui. Assieme alla crittanalisi (che tratta della decifrazione dei testi criptati) forma la scienza della crittologia. Questa tecnica si può facilmente affiancare alla steganografia che, a differenza della crittografia, invece di proteggere i dati attraverso processi matematici li nasconde tra altri elementi.

Storia

La crittografia, come modifica volontaria del testo, esisteva già al tempo degli egiziani nel 1900 a.C. (tomba del faraone Knumotete II) ma sono presenti molti altri modi che sfruttano la steganografia per nascondere i messaggi. Un esempio legato all’antichità è scrivere messaggi segreti non sull’argilla che ricopriva le tavolette, ma sulle stesse tavolette che venivano poi ricoperte d’argilla e sembravano non usate. Delle forme grezze di crittografia si possono trovare tra gli Spartani (2500 anni fa) che utilizzavano una striscia di papiro avvolta a spirale attorno ad un bastone (che costituirà la chiave di decodifica). Una volta scritto il messaggio in verticale sul papiro questo veniva consegnato al destinatario che, solo con un bastone dello stesso diametro poteva leggere il messaggio in chiaro.

Metodo di Cesare

Sicuramente, tra i personaggi più famosi della storia della crittografia, c’è Giulio Cesare a cui fanno capo più metodi di offuscazione del testo. Uno di questi metodi è di trasposizione poiché il messaggio è in chiaro ma a cambiare è l’ordine delle lettere. Un altro modo, questa volta di sostituzione, consiste nel fissare una chiave n che è un numero stabilito e si sostituisce ogni lettera del messaggio con l’ennesima seguente. Come si può facilmente notare questo metodo è molto rudimentale in quanto possiede un numero molto ristretto di chiavi.

Metodo ATBASH

Un altro metodo per sostituzione è rappresentato da quello che usavano gli ebrei, detto ATBASH, nel quale vengono affiancati due alfabeti uno in ordine crescente e uno in ordine decrescente in modo da formare delle coppie di lettere che formeranno la chiave di questo metodo.

il metodo di Polibio

Lo storico greco Polibio inventò una tecnica di codifica legando le lettere a una coppia di numeri che ne indicava la posizione in una tabella. La coppia di numeri era comunicata nella notte attraverso delle torce.

Il metodo di Vigenere

Il metodo comunemente chiamato Vigenère ha una nascita piuttosto vaga. Infatti, secondo alcuni storici, questo sarebbe stato inventato da Giovan Battista Belaso anche se ci sono dei dubbi che un sistema come questo fosse utilizzato dall’imperatore Romano Augusto. Il metodo si può considerare una generalizzazione del cifrario di Cesare; invece di spostare sempre dello stesso numero di posti la lettera da cifrare, questa viene spostata di un numero di posti variabile, determinato in base ad una parola chiave, da concordarsi tra mittente e destinatario. Il testo cifrato si ottiene spostando la lettera chiara di un numero fisso di caratteri, pari al numero ordinale della lettera corrispondente della chiave. Di fatto si esegue una somma aritmetica tra l’ordinale del testo chiaro (A = 0, B = 1, C = 2 ...) e quello della chiave; se si supera l’ultima lettera, la Z, si ricomincia dalla A, secondo la logica delle aritmetiche finite. Il vantaggio rispetto ai cifrari mono alfabetici è evidente: la singola lettera del testo chiaro non è sempre cifrata con la stessa lettera; e questo rende più difficile la crittanalisi statistica del testo cifrato. La criptoanalisi di questo metodo non beneficia della frequenza delle lettere della lingua usata. Questo metodo può essere attaccato con un bruteforce utilizzando un dizionario di parole e analizzando i blocchi di ripetizioni causati dal fatto che la chiave è più corta del messaggio. Ovviamente ci si può difendere non usando come chiave parole di senso compiuto, ma un insieme di lettere generate in maniera casuale.

La macchina Enigma

L’uso della criptografia continua intensificandosi sempre di più e migliorandosi con il tempo fino ad avere importanza tale da cambiare il corso della storia durante le due guerre mondiali quando appaiono le prime macchine elettriche per cifrare i messaggi e, soprattutto, per fare criptoanalisi. I tedeschi usarono per tutta la seconda guerra mondiale una macchia chiamata Enigma che avrebbe dovuto cifrare i messaggi in maniera sicura. Così non successe, perché, inglesi e polacchi, unendo le loro forze furono in grado di decifrare quasi tutti i messaggi intercettati. L’Enigma era una macchina elettromeccanica con contatti, lampadine, rotori e una tastiera. Ogni lettera veniva cifrata con un alfabeto diverso dando luogo ad un numero spropositato di combinazioni che rendevano la decodifica teoricamente impossibile per l’epoca. Ma ciò non fermò gli inglesi che trassero grande beneficio dai messaggi decodificati. Si pensa che la triplice intesa (a cui aveva aderito l’Inghilterra) fu molto aiutata a decifrare i messaggi dell’alleanza grazie al ritrovamento in un sommergibile di alcune delle specifiche della macchina Enigma.

Per anni la regola generale è stata di creare algoritmi semplici e di impiegare chiave molto lunghe per rendere più laborioso il lavoro dello criptoanalista. Oggi l’orientamento è opposto data la potenza di calcolo di cui si può disporre per fare un bruteforce, quindi si creano algoritmi complicatissimi da decifrare in modo che, anche se il nostro avversario avesse parecchio materiale su cui condurre un’analisi, gli sarebbe pressoché inutile. Oggi la crittografia serve per il commercio elettronico, l’autenticazione in siti internet, la riservatezza delle informazioni, e per molti altri scopi finanziari. Uno dei presupposti fondamentali è che si suppone che il criptoanalista di turno conosca in generale il nostro metodo di crittografia, questo perché è davvero un disastro cambiare ogni volta metodo di crittografia ogni qual volta si ha il sospetto che qualcuno sia riuscito a infrangerlo. Da questo presupposto segue che i metodi si basano sull’esistenza di molte e diverse chiavi.

La crittografia a chiave pubblica / privata

Attualmente la crittologia si distingue in due forme fondamentali: la crittografia simmetrica, ovvero a chiave segreta, e quella asimmetrica, nota meglio come crittografia a chiave pubblica.

La crittografia simmetrica

La crittografia simmetrica è quella più semplice da comprendere; si basa su un algoritmo che modifica i dati in base a una chiave (di solito una stringa di qualche tipo) che permette il ripristino dei dati originali soltanto conoscendo la stessa chiave usata per la cifratura. Per utilizzare una cifratura simmetrica, due persone si devono accordare sull’algoritmo da utilizzare e sulla chiave. La forza o la debolezza di questo sistema, si basa sulla difficoltà o meno che ci può essere nell’individuare la chiave, tenendo conto anche della possibilità elaborative di cui può disporre chi intende spiare la comunicazione.

Generalmente gli algoritmi di crittografia simmetrica sono molto più veloci di quelli a Chiave pubblica , per questo vengono usati in tutte le operazioni di cifratura che richiedono performance.

La crittografia asimmetrica

La crittografia a chiave pubblica è un metodo molto più complesso, che però ha il vantaggio di essere più pratico quando riguarda la comunicazione con molte persone. Il principio di funzionamento si basa sul fatto che esistono due chiavi complementari (cioè una chiave è la funzione matematica inversa dell’altra), assieme a un algoritmo in grado di cifrare con una chiave e di decifrare utilizzando l’altra. In pratica, la cifratura avviene a senso unico attraverso la chiave di cui dispone il mittente di un messaggio, mentre questo può essere decifrato esclusivamente con l’altra che possiede solo il destinatario. Le due chiavi vengono chiamate chiave pubblica e chiave privata, attribuendogli implicitamente un ruolo specifico. In pratica, chi vuole mettere in condizione i propri interlocutori di inviare dei messaggi, o altri dati cifrati, che nessun altro possa decifrare, deve costruire una propria coppia di chiavi e quindi distribuire la chiave pubblica e mantenere nascosta la chiave privata. Chi vuole inviare informazioni cifrate, può usare la chiave pubblica diffusa dal destinatario, perché solo chi ha la chiave complementare, ovvero la chiave privata, può decifrarle. In questa situazione, evidentemente, la chiave privata deve rimanere segreta a tutti, tranne che al suo proprietario; se venisse trafugata permetterebbe di decifrare i messaggi che fossero eventualmente intercettati. Anche questo metodo si basa sul fatto che è enormemente difficile (se non impossibile) ricavare la chiave privata partendo dalla conoscenza di quella pubblica. Infatti tutto questo sarebbe matematicamente possibile anche se, anche con le potenze di calcolo attuali, si impiegherebbero migliaia di anni per decifrare una chiave.

La cifratura può anche essere ibrida, utilizzando in pratica entrambe le tecniche. Per attuarla, di solito si utilizza prima la cifratura simmetrica con una chiave determinata in modo casuale ogni volta: la chiave di sessione. Questa chiave di sessione viene allegata al messaggio, o ai dati trasmessi, cifrandola a sua volta (eventualmente assieme agli stessi dati già cifrati) attraverso il sistema della chiave pubblica, ovvero quello che si basa sulla coppia di chiavi complementari. Il destinatario di questi dati deve fare il percorso inverso, decifrando il documento con la sua chiave privata, quindi decifrandolo nuovamente utilizzando la chiave di sessione che ha ottenuto dopo il primo passaggio.

Crittografia e Firma con OpenPGP

Uno dei primi impieghi della crittografia è stato quello più semplice di cifratura e firma dei file. Il principale standard adottato per questo scopo è l’OpenPGP nelle sue implementazioni PGP e GPG (quest’ultimo è di una implementazione free software sponsorizzata dalla Free Software Fondation)

La storia

La prima implementazione della cifratura PGP risale al 1991 ad opera di Phil Zimmermann, egli era da molto tempo un attivista anti-nucleare e creò il programma principalmente per poter comunicare in modo sicuro con i suoi compagni. Ben presto il programma spopolò e grazie alla sua licenza gratuita per scopi non commerciali divenne quasi uno standard in fatto di comunicazioni cifrate private su usenet.

Un aneddoto riguardante il nome Pretty Good Privacy racconta come Phil si sia ispirat a una drogheria di Lake Wobegon, la città natale dello speaker radio Garrison Keillor. La drogheria si chiamava “Ralph’s Pretty Good Grocery” (”la drogheria assai buona di Ralph”) e il suo slogan era “se non lo puoi trovare da Ralph, probabilmente puoi anche farne a meno”.

Nel 1993 a seguito di una grande diffusione dell’uso di PGP su tutto internet Zimmermann fù indagato dal governo degli Stati Uniti per “Esportazione di armi senza apposita licenza”

Secondo quanto stabilito dal Regolamento per l’Esportazione dei prodotti e servizi USA i sistemi di crittografia che utilizzassero una chiave maggiore di 40-bit erano infatti considerati come munizioni e, dato che il PGP ha sempre adottato chiavi maggiori di 128 bit, all’epoca rientrava perfettamente nella casistica. Oltretutto le sanzioni, per chi fosse riconosciuto colpevole, erano e rimangono rilevanti.

Solo dal 2000 la crittografia con PGP non rientra più nella definizione di Arma non esportabile e può essere esportata internazionalmente eccetto fatto per 7 specifici paesi.

Nel frattempo il team di Zimmermann stava lavorando ad una nuova versione di PGP chiamata PGP 3. Questa nuova versione introdusse considerevoli miglioramenti nella sicurezza, compresa una nuova struttura di certificato che non aveva i piccoli problemi di sicurezza dei certificati usati da PGP 2.x oltre che permettere ad un certificato di avere chiavi separate per la firma e per la cifratura. Inoltre le passate negative esperienze con brevetti e problemi di esportazione li portò ad evitare completamente i brevetti. PGP 3 ha introdotto l’uso dell’algoritmo simmetrico CAST-128 (chiamato anche CAST5) e degli algoritmi asimmetrici DSA e Elgamal, nessuno di questi coperto da brevetto.

Dopo l’indagine terminata nel 1996, Zimmermann ed il suo gruppo fondarono una compagnia per produrre nuove versioni di PGP. Si fusero con Viacrypt (alla quale Zimmermann aveva venduto i diritti commerciali di PGP e che aveva acquistato la licenza RSA direttamente dalla RSADSI), che cambiò nome in PGP Incorporated. Il nuovo team Viacrypt/PGP cominciò a lavorare alle nuove versioni di PGP basate su PGP 3. A differenza di PGP 2, che aveva esclusivamente una interfaccia a linea di comando, PGP 3 fu progettato sin dall’inizio per essere una libreria software, permettendo agli utenti di lavorare sia da linea di comando che grazie ad una interfaccia grafica.

Nel giugno 1997 la PGP Inc. ha proposto al IETF la creazione di uno standard chiamato OpenPGP. Hanno dato il permesso al IETF di usare il nome OpenPGP per descrivere questo nuovo standard e qualsiasi programma che lo supportasse (’PGP’, ‘Pretty Good Privacy’ e ‘Pretty Good’ sono tutti marchi registrati della PGP Corporation, al 2002). Lo IETF ha accettato la proposta e ha creato lo OpenPGP Working Group. Ora OpenPGP è diventato uno standard Internet: è definito dalle RFC 2440 e 3156.

A partire da questo la Free Software Foundation ha sviluppato il proprio programma OpenPGP-compatibile chiamato GNU Privacy Guard (GnuPG), così come hanno fatto anche altri produttori. GPG è, naturalmente, disponibile con licenza GNU General Public License (GPL) ed è oggi presente in tutte le distribuzioni Linux nonché il principale mezzo di certificazione e crittografia nel mondo del software libero. Esistono anche molte interfacce grafiche che agevolano l’utilizzo di GPG.

Nel Dicembre del 1997, la PGP Inc. venne acquistata dalla Network Associates, Inc., e Zimmermann ed il gruppo PGP divennero suoi impiegati. Il team PGP aggiunse al programma originale nuove funzionalità, come la criptazione dei dischi, firewall per desktop, rilevamento delle intrusioni, e le VPN di IPsec. Dopo la legalizzazione delle esportazioni del 2000 non fu più necessario pubblicare il codice sorgente, e la NAI smise di farlo, nonostante le obiezioni del gruppo PGP. Gli utenti di PGP sparsi in tutto il globo furono decisamente delusi, ed inevitabilmente, si formarono alcune teorie cospirative contro la NAI.

All’inizio del 2001 Zimmermann lasciò la NAI. Ha lavorato come Crittografo Capo per la Hush Communications, che fornisce un programma per email basato su OpenPGP, Hushmail. Ha anche lavorato con Veridis e altre società.

Nell’estate del 2002, alcuni ex-membri del gruppo PGP hanno acquistato i diritti di PGP dalla NAI (eccetto per la versione a linea di comando), e, nell’Agosto dello stesso anno, hanno formato una nuova compagnia, la PGP Corporation. PGP Corp. sta supportando gli utenti attuali di PGP e onora i precendenti contratti di assistenza. Zimmermann ora lavora come consulente speciale alla PGP Corp., e continua il suo lavoro alla Hush Communications e alla Verdis, e infine gestisce una propria compagnia di consulenza.

NAI continua a supportare la sua versione di PGP il cui ultimo rilascio risale al 2005 con PGP Desktop 9.0, PGP Universal 2.0 e PGP Command Line 9.0.

Teoria

PGP usa sia la crittografia asimmetrica (detta anche a chiave pubblica) sia quella simmetrica. Nella crittografia a chiave asimmetrica, nella quale il destinatario del messaggio ha generato precedentemente una coppia di chiavi collegate fra loro; una chiave pubblica ed una privata. La chiave pubblica del destinatario serve al mittente per cifrare una chiave comune (detta anche chiave segreta o convenzionale) per un algoritmo di crittografia simmetrica; questa chiave viene quindi usata per cifrare il testo in chiaro del messaggio. Molte chiavi pubbliche di utenti PGP sono a disposizione di tutti dai numerosi key server (server delle chiavi) PGP sparsi per il mondo, che operano come mirror reciproci.

Il destinatario di un messaggio protetto da PGP lo decifra usando la chiave di sessione con l’algoritmo simmetrico. La chiave di sessione è inclusa nel messaggio in maniera criptata e viene decifrata usando la chiave privata del destinatario. L’utilizzo di due cifrature è giustificato dalla notevole differenza nella velocità di esecuzione tra una cifratura a chiave asimmetrica ed una a chiave simmetrica (l’ultima è generalmente molto più veloce). Ci sono inoltre delle vulnerabilità crittografiche nell’algoritmo a chiave asimmetrica utilizzato da PGP quando viene usato per cifrare direttamente un messaggio.

Una strategia simile può essere usata per capire se un messaggio è stato alterato, o se è stato mandato effettivamente da chi dice di essere il mittente. Per fare entrambe le cose, il mittente usa PGP per ‘firmare’ il messaggio con l’algoritmo di firma RSA o DSA. Per fare questo, PGP calcola un ‘hash’ (anche chiamato message digest) dal testo in chiaro, e crea poi da questo hash la firma digitale usando la chiave privata del mittente.

Il destinatario del messaggio calcola il message digest dal testo in chiaro decifrato, e poi usa la chiave pubblica del mittente ed il valore del message digest firmato con l’algoritmo di firma. Se la firma corrisponde al message digest del testo in chiaro ricevuto, si presuppone (con un grande margine di sicurezza) che il messaggio ricevuto non sia stato alterato né accidentalmente né volontariamente da quando è stato firmato. Questa presunzione si basa su diverse considerazioni: è poco probabile, visti gli algoritmi ed i protocolli usati in PGP, che un avversario possa creare una firma per un messaggio qualsiasi, e quindi un messaggio ricevuto che superi questo test dev’essere stato mandato da chi dice di essere il mittente. Gli esperti in sicurezza chiamano spesso questa proprietà ‘non-repudation’, non si può ripudiare la paternità del messaggio.

In ogni caso chiunque possegga la parte privata delle chiavi può facilmente creare una firma corretta per ogni cosa. In un mondo di e-mail virus, rootkits,Trojan, ed altri malware, ed agenti dell’FBI con ordinanze della corte, il termine ‘non-repudation’ dev’essere usato con le pinze, dato che le chiavi private possono essere compromesse (e copiate) in maniera illegale. Ma questa è una affermazione valida per ‘tutti’ i sistemi che utilizzano algoritmi a chiave asimmetrica per la firma digitale e quindi inglobino il concetto di non-repudation. PGP non è particolarmente vulnerabile, ma Zimmerman è stato saggio e non solo divertente, nel chiamare il suo sistema “pretty good” (quasi buono).

Sia quando si cifra un messaggio che quando si verifica la firma, è fondamentale che la chiave pubblica utilizzata per mandare il messaggio ad una persona o ente appartenga effettivamente al destinatario. Scaricare una chiave pubblica da qualche parte non è per niente una garanzia di questa corrispondenza; lo spoofing (cioè il furto di identità) intenzionale od accidentale è possibile. PGP include delle precauzioni per la distribuzione delle chiavi pubbliche in ‘certificati d’identità’ i quali sono costruiti crittograficamente, in maniera tale da rendere qualsiasi manomissione o disturbo accidentale facilmente rivelabile. Purtroppo rendere un certificato effettivamente impossibile da modificare senza lasciare tracce non è sufficiente. Questo può prevenire la manomissione solo dopo la creazione del certificato, non prima. Gli utenti devono anche verificare in qualche maniera che la chiave pubblica in un certificato appartenga effettivamente alla persona o ente che ne reclama la paternità. Per questo PGP racchiude un sistema di ‘voto’ dei certificati; è chiamata web of trust (letteralmente, “rete di fiducia”). PGP ha anche sempre incluso una maniera per cancellare i certificati d’identità che possono essere diventati inutilizzabili; questo è, più o meno, l’equivalente dei certificate revocation list (certificati di revoca) dei sistemi PKI più centralizzati. Le versioni più recenti di PGP supportano anche una data di scadenza per i certificati.

Utilizzo

In questo capitolo affronteremo l’utilizzo pratico del programma GPG, disponibile come Software Libero per tutti i maggiori sistemi operativi. Non utilizzeremo interfacce grafiche dato che di queste ne esistono molte e differenti tra loro. Utilizzeremo invece esclusivamente la modalità da riga di comando. Munitevi quindi di un terminale dove poter seguire i passi proposti.

Generiamo la nostra coppia di chiavi

Iniziamo creando la nostra coppia di chiavi pubblica/privata con il comando

gpg --gen-key

Ci verranno proposte una serie di scelte tra cui:

  • Che algoritmo usare
  • Data di scadenza delle chiavi
  • Informazioni Personali (Nome, cognome, email)
  • Passphrase per limitare l’accesso alla chiave privata
ATTENZIONE ALLA PASSPHRASE: Dal punto di vista della sicurezza, la passphrase usata per sbloccare la chiave privata è uno dei punti più deboli di GnuPG (così come di altri sistema di crittografia a chiave pubblica), in quanto è l’unica protezione che si possiede nel caso in cui un’altra persona entri in possesso della propria chiave privata. Idealmente la passphrase non dovrebbe utilizzare parole prese da un dizionario e dovrebbe usare tanto caratteri minuscoli e maiuscoli quanto caratteri non-alfabetici. Una buona passphrase è cruciale per un uso sicuro di GnuPG.

Una volta inseriti questi dati il programma impiegherà alcuni minuti per creare la coppia di chiavi partendo da informazioni casuali fornite dal sistema operativo stesso. Al fine di velocizzare questa operazione è consigliato eseguire altre applicazioni per aumentare la quantità di informazioni che il sistema operativo può utilizzare per la generazione dei numeri casuali.

Una volta concluse queste operazioni le chiavi create vengono memorizzate nella directory di GPG, usualmente /~/.gnupg

Generare un certificato di revoca

Una volta che la propria coppia di chiavi è stata creata, si dovrebbe immediatamente generare un certificato di revoca per la chiave pubblica primaria utilizzando l’opzione –gen-revoke. Se ci si dimentica la passphrase o se la propria chiave privata viene compromessa o persa, questo certificato di revoca può essere pubblicato per segnalare ad altri che la chiave pubblica non deve più essere usata. Una chiave pubblica revocata può comunque ancora essere utilizzata per verificare firme fatte in passato, ma non può più essere usata per cifrare futuri messaggi. Inoltre la revoca non influisce sulla propria capacità di decifrare messaggi spediti in passato, se si possiede ancora l’accesso alla chiave privata.

gpg --output revoca.asc --gen-revoke mia_chiave

L’argomento mia_chiave deve essere uno specificatore di chiave, cioè o l’ID della propria coppia primaria di chiavi o una qualsiasi altra parte dello User ID che identifica la propria coppia di chiavi come ad esempio l’indirizzo email utilizzato. Il certificato generato verrà riposto nel file revoca.asc. Se l’opzione –output è omessa, il risultato verrà stampato sullo standard output. Poiché il certificato è breve, si può pensare di stamparne una copia e tenerlo al sicuro da qualche parte, ad esempio nella propria cassetta di sicurezza. Il certificato non dovrebbe venir riposto in luoghi dove altri possono aver accesso in quanto chiunque può pubblicare il certificato di revoca e rendere la chiave pubblica corrispondente inutile.

Lo scambio delle chiavi

Per poter comunicare con altre persone cifrando i messaggi o verificando la firma altrui è prima necessario importare le chiavi pubbliche delle persone che saranno i nostri destinatari.

Per elencare le chiavi in nostro possesso possiamo digitare:

gpg --list-keys

Per esportare una chiave pubblica, in particolare la nostra in modo da poterla pubblicare o consegnare a terzi:

gpg --armor --output NOMEFILE --export CHIAVE

Note: l’opzione –armor forza l’output ad essere incapsulato in un messaggio ASCII in modo da renderlo più leggibile e fruibile.

Per importare una chiave si utilizza invece l’opzione –import

gpg --import blake.gpg

L’aver importato una chiave non significa però considerarla corretta o tanto meno autentica. GPG infatti gestisce una complessa organizzazione di fiducia che permette di convalidare una chiave personalmente o basandosi sulla fiducia già assegnata a quella chiave da un ente o persona di cui noi riteniamo poterci fidare.

Per convalidare personalmente una chiave dobbiamo prima di tutto ricavare l’impronta digitale della chiave stessa tramite il comando:

gpg --fingerprint blake@cyb.org
 pub  1024D/9E98BC16 1999-06-04 Blake (esecutore) <blake@cyb.org>
            Impronta digitale: 268F 448F CCD7 AF34 183E  52D8 9BDE 1A08 9E98 BC16 

Quindi dobbiamo verificarla col possessore stesso di quella chiave. Ciò può essere fatto di persona, per telefono o attraverso un qualsiasi altro mezzo con il quale sia possibile garantire che si sta comunicando con il vero possessore della chiave. Se l’impronta digitale che si riceve è la stessa impronta digitale che il possessore della chiave detiene, allora si può essere sicuri di possedere una corretta copia della chiave. Dopo aver controllato l’impronta digitale, si può procedere alla firma in modo da convalidarla. Poiché la verifica di una chiave rappresenta un punto debole nella crittografia a chiave pubblica, è necessario essere estremamente attenti è controllare sempre un’impronta digitale di una chiave con il possessore prima di firmare la chiave stessa.

Infine per convalidare una chiave pubblica non dobbiamo fare altro che firmarla con la nostra chiave con il comando:

gpg --sign-key blake@cyb.org

Cifrare e decifrare

Per cifrare un messaggio con una chiave pubblica in nostro possesso basta digitare:

gpg --output doc.gpg --encrypt --recipient blake@cyb.org doc

Mentre per decrifrare un messaggio cifrato con un una chiave pubblica di cui noi conosciamo la rispettiva chiave privata possiamo digitare:

gpg --output doc --decrypt doc.gpg

Firmare e verificare

Una firma digitale certifica e appone la data ad un documento. Se il documento viene successivamente modificato in qualsiasi modo, una verifica della firma fallirà. Una firma digitale può servire allo stesso scopo per il quale si utilizza una firma fatta a mano con l’ulteriore beneficio di essere a prova di manomissione. La distribuzione dei sorgenti di GnuPG, per esempio, è firmata in modo tale da permettere agli utenti di verificare che il codice sorgente non sia stato modificato dal momento in cui è stato creato il pacchetto.

Il procedimento di firma di un messaggio consiste nell’applicare la propria chiave privata all’hash (impronta digitale) del messaggio in modo che chiunque sia in possesso della nostra chiave pubblica possa applicandola alla firma vedere se il contenuto del messaggio è stato compromesso e se siamo stati veramente noi a inviare il messaggio.

Per firmare un file basta eseguire

gpg --sign nomefile

questo creerà un file nomefile.asc contenente la firma del messaggio in modo da non modificare il file originario.

Per verificare un file a sua volta basta eseguire:

gpg --verify file.asc file

Note: è possibile integrare messaggio e firma insieme aggiungendo l’opzione –clearsign durante la firma.

Gestione del mazzo di chiavi

Come si sa qualunque cosa si faccia si parte sempre da se stessi, anche qui perciò iniziamo dalle nostre chiavi prima di vedere come gestire quelle degli altri.

Ogni chiave è composta da più componenti: da uno o più UserID (identità) e da una o più chiavi strutturate in principali e subordinate. Queste informazioni vengono poi autofirmate per garantirne l’integrità stessa.

Possiamo accedere alla gestione della nostra coppia di chiavi mediante:

gpg --edit-key MiaEmail

da questa console interattiva possiamo poi aggiungere identità o chiavi rispettivamente con i comandi adduid e addkey. Per rimuovere identità o chiavi invece bisogna prima selezionarle tramite uid N o key N quindi rimuoverle tramite deluid o delkey

La semplice cancellazione però è inefficace se i nostri contatti contengono ancora la nostra chiave vecchia, infatti nel caso rimandassimo loro la nostra chiave nuova quella vecchia non sarebbe rimossa dai loro mazzi di chiavi ma associata a quella nuova. Per evitare ciò è sempre bene revocare le chiavi, invece che rimuoverle semplicemente, tramite il comando revkey. Per revocare delle identità invece è necessario rimuovere l’autofirma loro data tramite il comando revsign

Un’ultima operazione che potrebbe risultare utile è quella del cambio della data di scadenza della firma che si può eseguire mediante il comando expire .

Reti di fiducia e convalida chiavi

In alternativa al fatto di convalidare personalmente tutti i singoli contatti GPG può usare il concetto delle reti di fiducia. Questo concetto ci permette di ritenere più o meno valide chiavi pubbliche di terzi che sono state firmate da uno o più contatti già presenti nel nostro mazzo di chiavi a seconda della fiducia, nella capacità di firmare le chiavi, che riponiamo nei nostri contatti.

OpenPGP prevede 4 livelli di fiducia:

  • Sconosciuto

Non c’è nessuna informazione sul giudizio del possessore nella chiave di firma. Le chiavi del proprio mazzo che non siano le proprie hanno inizialmente questo livello di fiducia.

  • Nessuna

Si sa che il possessore non firma opportunamente le chiavi degli altri.

  • Marginale

Il possessore capisce le implicazioni che comporta firmare una chiave ed è capace di convalidare le chiavi propriamente prima di firmarle.

  • Piena

Il possessore ha un’eccellente comprensione di ciò che comporta firmare una chiave e la sua firma su una chiave è tanto valida quanto la propria.

Un livello di fiducia per la chiave è qualcosa che si assegna da soli alla chiave ed è considerata un’informazione privata. Non viene inclusa con la chiave quando questa è esportata; viene perfino salvata separatamente dal proprio mazzo di chiavi in un elenco a sé stante.

Tramite la modalità interattiva di GPG a cui si accede tramite:

gpg --edit-key chiave

è possibile impostare la nostra fiducia con il comando trust

Per ritenere valida una chiave pubblica all’interno di una rete di fiducia si deve verificare almeno una delle 3 condizioni seguenti:

  1. è stata firmata di persona, oppure
  2. è stata firmata da una chiave di cui ci si fida pienamente, oppure
  3. è stata firmata da tre chiavi con fiducia marginale
    • inoltre il percorso delle chiavi firmate che risale dalla chiave K alla propria chiave è al massimo di cinque passi
La lunghezza del percorso, il numero delle chiavi con fiducia marginale richiesto e il numero di chiavi con fiducia piena possono essere modificati. I numeri dati precedentemente sono quelli preimpostati in GnuPG.

Come distribuire le chiavi

Per semplificare l’aggiornamento dei dati relativi alle chiavi pubbliche, in particolare delle firme certificatrici effettuate da terzi, sono nati dei Server di chiavi cioè dei database dove vengono immagazzinate e mantenuti aggiornati i profili delle persone. Questi server possono essere di grandissima utilità quando non si sapesse dove trovare la chiave di una determinata persona a cui si vuole fare riferimento. Per ricevere informazioni da questi server e per inviarle si possono usare dei semplici istruzioni a linea di comando. Per il programma gpg l’opzione –keyserver <nomeServer> sta ad indicare quale sia il server a cui si sta facendo riferimento e cioè qual è l’indirizzo dove sono situate le chiavi mentre l’opzione –recv-key <ID chiave> interroga il server per ottenere informazioni riguardo ad una determinata chiave. L’esempio che segue interroga il server certserver.pgp.com riguardo alla chiave con ID 0xBB7576AC

gpg --keyserver certserver.pgp.com --recv-key 0xBB7576AC

Per inviare informazioni riguardo ad un profilo viene utilizzato l’opzione –send-key <mail>. Come si può facilmente notare, nell’esempio seguente, verrà inviata la chiave pubblica (aggiornata con le relative firme) al server certserver.pgp.com riguardo all’utente che ha come mail blake@cyb.org.

gpg --keyserver certserver.pgp.com --send-key blake@cyb.org

La legge italiana a riguardo

All’articolo 21, il Decreto Legislativo 82/2005 stabilisce, con un rimando al Codice Civile, che la firma digitale (o altra firma elettronica qualificata) fa piena prova fino a querela di falso se colui contro il quale la scrittura è prodotta ne riconosce la sottoscrizione, ovvero se questa e legalmente considerata come riconosciuta , equiparando così il documento informatico sottoscritto con firma digitale alla scrittura privata sottoscritta con firma autografa (e non, come avveniva in precedenza, all’atto pubblico). In ogni caso la firma digitale a crittografia asimmetrica è riconosciuta ed equiparata a tutti gli effetti di legge alla firma autografa su carta. C’è la possibilità poi di acquisire una firma digitale riconosciuta dallo stato per mezzo di enti certificatori. Ci sono delle normative europee che richiedono invitano ad aggiornare la legislazione in materia. La firma digitale p riconosciuta in moltissimi paesi in tutto il mondo tra cui Stati Uniti, Cina e Canada.

Algoritmi

Crittografia asimmetrica

RSA

L’RSA è un algoritmo di crittografia asimmetrica, utilizzabile per cifrare o firmare informazioni. Scritto nel 1977 da Ron Rivest, Adi Shamir e Len Adleman al MIT, prende il nome dalle iniziali dei cognomi dei suoi creatori. Un algoritmo simile era però stato descritto precedentemente da Clifford Cocks, un matematico britannico che lavorava per un dipartimento di spionaggio 1973. I documenti e gli studi furono posti sotto segreto e, visto il costo relativamente alto delle macchine necessario a quel tempo per implementarlo, non ci furono ulteriori indagini né prove pratiche e la cosa fu considerata come una curiosità, per quanto se ne sa. La scoperta di Cocks fu resa pubblica solo nel 1997. Nel 1983 l’algoritmo fu brevettato negli Stati Uniti dal MIT. Il brevetto è scaduto il 21 settembre 2000.

La base dell'RSA

Il funzionamento dell’RSA poggia sulle basi della matematica modulare, cioè delle classi resto.

  1. Per applicare l’algoritmo RSA ad un messaggio bisogna inizialmente scegliere a caso due numeri primi molto grandi (nell’ordine delle 300 cifre) chiamati P e Q;
  2. Si calcola il numero N = P*Q, da notare è che tutta la seguente aritmetica sarà modulare e in base N;
  3. Si calcola φ(N) che, essendo N un prodotto di due primi, si calcola semplicemente attraverso la forumla (P-1)*(Q-1);
  4. Si sceglie a caso un numero E coprimo minore di φ(N);
  5. Si calcola G, l’inverso di E cioè E * G ≡ 1%φ(N);

A questo punto si sono ottenute due chiavi: quella pubblica consiste in (N, E) mentre quella privata è (N, G). A questo punto, se un soggetto B deve inviare un messaggio M < N ad A

  1. B calcola C = ME % N e lo invia ad A;
  2. A riceve C che eleva alla G ottenendo così MEG % N = M1 % N = M;

La forza dell’algoritmo è che per calcolare G da E (così come il contrario) non basta la conoscenza di N, ma serve il numero φ(N), infatti fattorizzare (cioè scomporre un numero nei suoi divisori) è un’operazione molto lenta, soprattutto se N, è un numero grande a sufficienza, poiché non si conoscono algoritmi efficienti. Nel 2005 un gruppo di ricerca riuscì a scomporre un numero di 640 bit (193 decimali contro i 600 decimali utilizzati per questo protocollo) in due numeri primi da 320 bit, impiegando per cinque mesi un cluster Opteron con 80 processori da 2,2 GHz, potenzialmente decifrando un messaggio codificato con RSA-640.

Esempio
  1. P = 61 e Q = 53 , (P-1)(Q-1) = 3120
  2. N = P*Q = 61*53 = 3233
  3. E = 17, E<N ed è coprimo per 3120 (in questo caso è primo, ma in generale non è necessario)
  4. D = 2753 infatti E*D = 2753*17 = 46801 ≡ 1 % φ(N) ≡ 1 % 3120 poiché 46801/3120 = 15 con resto 1

Quindi abbiamo la chiave pubblica (3233,17) e la chiave privata (3233,2753).

Prendiamo ora in considerazione il messaggio M = 123 e cifriamolo per ottenere il messaggio cifrato ME, ovviamente possiamo usare i 3233 e 17, ma non 2753 che fa parte della chiave privata.

  1. C = ME%N = 12317%3233 = 855;
  2. E ora decifriamo C = 855 per ottenere M; qui utilizzeremo 2753, componente essenziale della chiave privata.
  3. M = Cd%N = 8552753%3233 = 123

DSA

Digital Signature Algorithm (DSA) è uno standard FIPS per la firma digitale. Proposto dal National Institute of Standards and Technology (NIST) nell’agosto del 1991 per essere impiegato nel Digital Signature Standard (DSS) viene definitivamente adottato nel 1993. Consiste in un sistema di crittazione a chiave pubblica che assomiglia al metodo Elgamal.

ElGamal

El Gamal è un sistema di cifratura a chiave pubblica, proposto dal ricercatore egiziano americano ElGamal nel 1985. Lo schema è basato sulla difficoltà del calcolo del logaritmo discreto. Come per tutti gli argomenti il trasferimento dei dati si suddivide in 3 fasi: la creazione delle chiavi, la cifratura e la decifratura.

Creazione delle chiavi
  1. Si sceglie a caso un numero primo P molto grande (10100 cifre);
  2. Si sceglie un numero G < P;
  3. Si calcola GA%P dove 0 < A < N-2;

Si vengono così a formare le due chiavi: quella pubblica (P, G, GA%P) e quella privata (A)

Cifratura del messaggio (M)
  1. Avendo la chiave pubblica e il messaggio M < P si sceglie un numero 1 < B < P-2;
  2. Si calcola GB%P;
  3. Si calcola M*(GA)B%P;
  4. Si inviano i dati criptati (GB%P, M*(GA)B%P)
Decifratura del messaggio

Per la decifratura, sapendo l’inverso di A (facilmente ottenibile possedendo A e P) basta

  1. Calcolare (GB)-A%P
  2. Eseguire la semplice operazione M*GBAG-BA = M

Tutte le operazioni coinvolte sono algoritmicamente fattibili, in maniera efficiente. Il costo computazionale di Encryption e Decryption sono paragonabili all’RSA però questo algoritmo è resistente ad attacchi di tipo criptoanalitico: l’unico modo di ricavare informazioni segrete dai dati pubblici è effettuare il logaritmo discreto di oa oppure di ok mod p. Ancora oggi non è conosciuto un algorimo EFFICENTE per calcolare tali valori.

Crittografia simmetrica

Algoritmi per la crittografia simmetrica ne esistono molti, in informatica però i più famosi ed utilizzati sono principalmente il DES, 3DES, AES, RC4 e BlowFish.

DES

Data Encryption Standard (DES) è un algoritmo di cifratura nato nel 1972 presso l’NBS (National Bureau of Standards) e standardizzato nello stesso anno dopo molte consultazioni con la NSA (National Security Agency) e la collaborazione dell’IBM. Questo algoritmo suscitò moltisse polemiche legate a possibili manomissioni dell’algoritmo da parte della NSA e sulla probabile esistenza di backdoor. Queste polemiche, smentite da diversi studi, abbero il merito di dare maggiore visibilità al campo della crittoanalisi che in quegli anni subì un fortissimo sviluppo. Negli anni 90, a seguito degli studi sul DES si potè confermare che le modifiche apportate furono esclusivamente miglioramenti resi possibili dalla conscenza da parte dell’IBM della crittanalisi differenziale, teoria mantenuta segreta fino al 1990. L’unica interferenza da parte dell’NSA fù quindi quella della riduzione della chiave di crittografia a 56 bits probabilmente prevedendo di riuscire ad attaccarla con attacchi bruteforce entro alcuni anni.

Nonostante tutto il DES fu approvato come standard federale nel novembre 1976 e pubblicato il 15 gennaio 1977 come FIPS PUB 46, certificato per l’uso su tutti i dati non classificati. È stato in seguito riconfermato come standard nel 1983, 1988 (riesaminato come FIPS-46-1), 1993 (FIPS-46-2) e nuovamente nel 1998 (FIPS-46-3), nel quale però si prescrive il “Triple DES” in seguito alla pubblicazione di un attacco teorico e di uno a forza bruta nel 1998 al DES tradizionale.

Il 26 maggio 2002, il DES è stato finalmente rimpiazzato dall’AES, l’Advanced Encryption Standard, in seguito ad un confronto pubblico. Ancora oggi, ad ogni modo, il DES è ancora largamente utilizzato.

Il DES è un algoritmo di crittografia a blocchi, ovvero opera sul messaggio per gruppi di 64 bit. Il DES usa inoltre una chiave per modificare la trasformazione in modo che l’operazione di decifratura possa essere effettuata solo conoscendo la chiave stessa. La chiave è lunga 64 bit ma solo 56 di questi sono effettivamente utilizzati dall’algoritmo. Otto bit sono utilizzati solo per il controllo di parità e poi scartati, per questo la lunghezza della effettiva è riportata come di 56 bit.

3DES

Triple DES è un cifrario a blocchi basato sulla ripetizione del cifrario Data Encryption Standard (DES) per tre volte. Quando si scoprì che la chiave a 56 bit del DES non era abbastanza da garantire la sicurezza contro attacchi brute force, il TDES fu scelto come modo semplice per aumentare la lunghezza della chiave senza bisogno di cambiare algoritmo.

Il 3DES sta lentamente sparendo in disuso, largamente rimpiazzato dal suo successore naturale, AES.

AES

L’Advanced Encryption Standard (AES), conosciuto anche come Rijndael (benché, più propriamente, AES sia una particolare implementazione dell’algoritmo Rijndael), è un algoritmo di cifratura a blocchi utilizzato attualmente come standard dal governo degli Stati Uniti d’America.

A differenza del DES, Rijndael è una rete a sostituzione e permutazione, non una rete di Feistel. AES è veloce sia se sviluppato in software sia se sviluppato in hardware, è relativamente semplice da implementare, e richiede poca memoria. Il nuovo standard di cifratura sta sostituendo i precedenti standard e la sua diffusione continua ad aumentare. Nell’AES il blocco è di dimensione fissa (128 bit) e la chiave può essere di 128, 192 o 256 bit

Funzioni Hash

Le funzioni hi Hashing sono una funzioni univoche operanti in un solo senso (ossia, che non possono essere invertite), atta alla trasformazione di un testo di lunghezza arbitraria in una stringa di lunghezza fissa (solitamente 128 bit). Tale stringa rappresenta una sorta di “impronta digitale” del testo in chiaro, e viene detta valore di hash, checksum crittografico o message digest. Le caratteristiche di una funzione di hash sono

  • L’algoritmo restituisce una stringa di numeri e lettere a partire da un qualsiasi flusso di bit di qualsiasi dimensione (può essere un file ma anche una stringa).
  • La stringa di output è univoca per ogni documento e ne è un’identificatore. Perciò, l’algoritmo è utlizzabile per la firma digitale.
  • L’algoritmo non è invertibile, ossia non è possibile ricostruire il documento originale a partire dalla stringa che viene restituita in output. (si calcola che per risalire, a partire da un hash di una stringa, ad un altra stringa con la stessa impronta si impegherebbe più tempo della vita dell’universo).

Essendo i message digest un numero limitato (infatti hanno una lunghezza ben definita di bit) e accettando la funzione di hash qulsiasi stringa, ci si trova ad avere dei casi in cui due messaggi differenti conducano allo stesso hash, anche se questo è molto improbabile. In questo caso si hanno delle “collisioni”. Le funzioni di hash sono strutturate appositamente per evitare quest’ultime e, infatti, una prova della poca qualità di una funzione del genere si può avere trovando delle collisioni tra parole. Nella crittografia queste funzioni vengono utilizzate per avere una verifica dell’integrità del documento: infatti un message digest viene calcolato prima della cifratura del messaggio e viene inviato al ricevente che, a sua volta, confronterà l’hash ricevuto con quello da lui stesso calcolato sul messaggio decifrato. Anche per file generici scaricabili da internet spesso si trovano, a fianco del download, un hash del documento per permettere a chi lo scarica di verificare l’integrità di questo e che non si sia corrotto durante la transazione. Tra le funzioni più famose si distinguono SHA-1, SHA-2, MD5 (famossisima funzione creata da Ronald Rivest). Ultimamente la funzione MD5 non è più molto usata in quanto sono state rilevate delle collisioni su alcuni file e si sta passando all’utilizzo dell’SHA-2.

Protocolli criptati

SSL & TLS

Secure Sockets Layer (SSL) è un protocollo progettato dalla Netscape Communications Corporation per realizzare comunicazioni cifrate su Internet. La versione 3.0, rilasciata nel 1996, è stata utilizzata come base di sviluppo per il protocollo Transport Layer Security (TLS), un un protocollo standard IETF. Lo scopo di questo protocollo è quello di creare delle comunicazioni affidabili e riservate sulla rete sfruttabili da qualsiasi applicazione. Questo protocollo garantisce:

  • L’autenticazione: l’identità nelle connessioni può essere autenticata usando la crittografia asimmetrica, ovvero a chiave pubblica (RSA, DSS, EL-Gamal). Così ogni client comunica in sicurezza con il corretto server, prevenendo ogni interposizione. È prevista la certificazione del server e, opzionalmente, quella del client.
  • La confidenzialità nella trasmissione dei dati: Dopo un primo accordo (handshake) iniziale può essere definita una chiave segreta di sessione in modo da poter utilizzare in seguito la crittografia simmetrica (AES,3DES, RC4, ecc.).
  • L’affidabilità: il livello di trasporto include un controllo dell’integrità del messaggio basato su un apposito MAC (Message Authentication Code) che utilizza funzioni hash sicure. In tal modo si verifica che i dati spediti tra client e server non siano stati alterati durante la trasmissione.

Le prime implementazioni di SSL erano limitate a cifratura a chiave simmetrica di 40 bit a causa delle restrizioni imposte dal governo statunitense per renderle così vulnerabili a degli attacchi di una eventuale forma giuridica. Attualmente si utilizzano delle chiavi simmetriche a 128 bit. Questi protocolli si interpongono tra il protocollo di trasporto TCP e dei protocolli applicativi quali HTTP, SMTP, NNTP e soprattutto HTTPS. Questi protocolli, anche sono molto simili non sono tra loro compatibili.

HTTPS

L’ HTTPS è un URI (Universal Resource Identifier) sintatticamente identico allo schema http:

Storia

Questo sistema fu progettato dalla Netscape Communications Corporation che si occupa delle autenticazioni e delle comunicazioni crittografate ed è largamente usato nel World Wide Web per situazioni che richiedono particolari esigenze in ambito di sicurezza come per esempio il pagamento di transazioni online.

Teoria

Rispetto al protocollo HTTP quello HTTPS utilizza la porta 443 invece che la 80 mentre, a livello di sintassi, è del tutto simile. Per impostare un web server in modo che accetti connessioni di tipo https, l’amministratore deve creare un certificato digitale ovvero un documento elettronico che associa l’identità di una persona ad una chiave pubblica. Questi certificati possono essere creati dai server basati su UNIX con l’ausilio di tools come ssl-ca di OpenSSL oppure usando gensslcert di SuSE. Questi certificati devono essere rilasciati da un’Autorità certificata o comunque da un sistema che accerta la validità dello stesso in modo da definire la vera identità del possessore (i browser web sono creati in modo da poter verificare la loro validità). Infatti se un browser non riuscirà a controllare la corrispondenza del certificato del server con l’ente certitificatore, richiederà all’utente se utilizzare la connessione, dal momento che non può più essere validata da un ente superiore. In particolari situazioni (come per esempio nel caso di aziende con una rete intranet privata) è possibile avere un proprio certificato digitale che si può rilasciare ai propri utenti. Questa tecnologia quindi può essere usata anche per permettere un accesso limitato ad un web server. L’amministratore spesso crea dei certificati per ogni utente che vengono caricati nei loro browser contententi informazioni come il relativo nome e indirizzo e-mail in modo tale da permettere al server di riconoscere l’utente nel momento in cui quest’ultimo tenti di riconnettersi senza immettere nome utente e/o password. Nel caso in cui questo non venga verificato al server è data la posibilità di interrompere la comunicazione al protocollo HTTP rendendo così inaccessibile il server a soggetti non autorizzati.

VPN

VPN (Virtual Private Network) è un servizio che permette la creazione di una rete privata instaurata tra soggetti che utilizzano un mezzo di trasmissione pubblico e condiviso come può essere per esempio internet. Il messaggio e il traffico della VPN transitano sulla rete pubblica utilizzando gli standard di trasmissione della rete e quindi potenzialmente possono essere insicuri dato che sono trasmessi in “chiaro” utilizzando protocolli comuni e quindi conosciuti anche da soggetti esterni alla VPN. Per far Fronte a questi problemi su utilizzano degli ulteriori protocolli cifrati. I più usati sono:

  • IPsec (IP security), parte obbligatoria dell’IPv6.
  • PPTP (point-to-point tunneling protocol), sviluppato da Microsoft.
  • SSL/TLS, che ha dimostrato grande flessibilità ed è quindi usato come strato di sicurezza per varie implementazioni (più o meno standard) di reti private virtuali. E’ da notare che il protocollo SSL/TLS non crea una rete virtuale ma crea solo una connessione protatta tra due Soggetti. Per questo il meccanismo di rete virtuale deve essere realizzato mediante un protocollo apposito che viene poi incapsulato.
  • Protocollo SOCKS: questo approccio è il più “standard”, in quanto SOCKS è uno standard IETF per Generic Firewall Traversal
  • OpenVPN mette a disposizione un eseguibile che crea un tunnel cifrato con un’altra istanza del medesimo programma su un computer remoto, e può trasportare l’intero stack TCP/IP.
  • OpenSSH è in grado, come OpenVPN, di creare dei tunnel tra le due macchine collegate.

SSH

SSH (Secure SHell, shell sicura) è un protocollo che permette di stabilire una sessione remota cifrata ad interfaccia a linea di comando con un altro host.

Il client SSH ha una interfaccia a linea di comando che appare simile alla consueta console, ma l’intera comunicazione (ovvero sia l’autenticazione che la sessione di lavoro) avviene in maniera cifrata. Per questo motivo, SSH è diventato uno standard di fatto per l’amministrazione remota di sistemi unix e di dispositivi di rete, rendendo obsoleto il protocollo telnet, giudicato troppo pericoloso per la sua mancanza di protezione contro le intercettazioni.

Pensato inizialmente nel 1995 da un ricercatore dell’università di Helsinki fù sviluppato velocemente e la seconda versione del protocollo fù proposta come standard internet pressto IETF. Attualmente la sua implementazione più usata e famosa è quella opensource di OpenSSH sviluppata dal team di OpenBSD

Chiavi pubbliche / private

Autenficazione dell'utente

Il protocollo prevede due metodi di autentificazione degli utenti al server:

  • Il primo utilizza una semplice password che deve essere validata dal server,

l’invio delle password, come tutta la comunicazione successiva, avviene all’interno di un canale criptato.

  • Il secondo, e anche il più sicuro e raccomandato dato che non soffre di attacchi di tipo

brute force, utilizza la crittografia asimmetrica: l’utente deve generare due chiavi una pubblica , che dovrà essere presente su tutti i server a cui ha intenzione di accedere, e una privata che potrà utilizzare, previo inserimento della passphrase, per autentificarsi presso il server.

Autentificazione del server

Il protocollo prevede infine un controllo aggiuntivo per prevenire attacchi Man In The Middle che consiste nell’autentificare il server stesso presso il client. Così facendo non è solo l’utente che deve dimostrare di essere autorizzato ma anche il server stesso che deve dimostrare al client di essere autentico. Anche questo si basa sulla crittografia asimmetrica e prevede che i client siano dotati della chiave pubblica del server il quale tramite la chiave privata in suo possesso deve dimostrare la sua atentificità.

Questo comportamento è abilitato di default e effettivamente a un primo collegamento se non siamo in possesso della chiave pubblica del server il programma ci mostrerà l’impronta digitale della chiave chiedendoci se la vogliamo accettare o meno. In seguito il programma controllerrà da solo l’autenticità del server informandoci se ci fossero incongruenze tra le chiavi.

Bibliografia

 
Tronweb on Facebook @tronweb on Twitter Recent changes RSS feed Creative Commons License Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki