Protocollo SSH - Capponcino · Tesina di Elementi di Crittograﬁa Prof.ssa Maria Gabriella...

Università degli studi di Roma Tre

Facoltà di Ingegneria

Corso di Laurea Magistrale in Ingegneria Informatica

Protocollo SSH

Tesina di Elementi di CrittografiaProf.ssa Maria Gabriella Murciano

Autori: Cappiello Irene - Di Fazio Alessio - El Saidi Amir

Anno accademico 2005/2006

Sommario

In questa tesina presentiamo una panoramica generale sul protocolloSSH Secure SHell, che facilita i collegamenti sicuri tra due sistemi, usandoun’architettura di tipo client/server e permettendo agli utenti di registrarsiin sistemi host server, in remoto.Dopo un’introduzione storica del protocollo SSH e l’analisi delle sue ver-sioni utilizzate,vengono presentati i principali algoritmi di crittografia e lefunzioni hash utilizzate da SSH, per una maggiore comprensione dei suoimeccanismi. Viene infine analizzata l’architettura del protocollo e il suofunzionamento.

Indice

Introduzione 4Sicurezza informatica . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Secure Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Un po’ di storia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Versioni a confronto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1 Algoritmi di crittografia supportati 8Algoritmo Diffie-Hellman . . . . . . . . . . . . . . . . . . . . . . . . . 81.1 Algoritmi a chiave pubblica . . . . . . . . . . . . . . . . . . . . . 9

1.1.1 Algoritmo RSA . . . . . . . . . . . . . . . . . . . . . . . . 91.1.2 Algoritmo DSA . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2 Algoritmi a chiave simmetrica . . . . . . . . . . . . . . . . . . . . 121.3 Funzioni hash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.3.1 Algoritmi di cifratura . . . . . . . . . . . . . . . . . . . . . 13

2 Struttura e Funzionamento 152.1 Architettura del protocollo . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2 Transport Layer Protocol . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.1 Scambio delle versioni . . . . . . . . . . . . . . . . . . . . 172.2.2 Negoziazione degli algoritmi . . . . . . . . . . . . . . . . 172.2.3 Scambio di chiavi . . . . . . . . . . . . . . . . . . . . . . . 182.2.4 Compressione . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.5 Integrità dei dati . . . . . . . . . . . . . . . . . . . . . . . 192.2.6 Cifratura . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Authentication Protocol . . . . . . . . . . . . . . . . . . . . . . . 202.3.1 Autenticazione: schema generale . . . . . . . . . . . . . . 202.3.2 Metodo di autenticazione a chiave pubblica. . . . . . . . . 212.3.3 Metodo di autenticazione con password . . . . . . . . . . 212.3.4 Autenticazione Host-based . . . . . . . . . . . . . . . . . . 21

2

3

2.4 Connection Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.1 Meccanismo dei canali: Schema generale . . . . . . . . . 222.4.2 TCP/IP Port Forwarding . . . . . . . . . . . . . . . . . . . 23

2.5 Estensibilità di SSH . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.1 Nomi di algoritmi . . . . . . . . . . . . . . . . . . . . . . . 23

2.6 Politiche Locali . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.7 Aspetti di Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 OpenSSH 26

4 Una sessione sicura 28

Conclusioni 29

Tesina di Elementi di Crittografia - Protocollo SSH

Introduzione 4

Introduzione

La necessità di nascondere messaggi strategici da occhi nemici è molto antica:si pensi che la prima traccia storica di uso della crittografia risale a Gaio GiulioCesare. A lui si attribuisce l’uso (se non addirittura l’invenzione) del cifrario diCesare, un sistema crittografico che diede vita ad un concetto totalmente nuovo eottimo per comprendere le idee basilari della crittografia e i primi attacchi dellasua “avversari”: la crittanalisi.

A partire dal cifrario di Cesare, i sistemi via via escogitati sono stati vari e manmano più evoluti: da questo elementare cifrario si è passati al più generalizza-to cifrario a scorrimento, successivamente al cifrario monoalfabetico, che a suavolta ha gettato le basi per i cifrari polialfabetici, tra cui l’imbattibile cifrario diVigénère1, come almeno era considerato quando Vigénère lo ideò (unendo molteidee che erano già state introdotte da tempo), visto che nel 1863 il colonnelloprussiano Friedrich Kasiski pubblicò un metodo per “forzarlo” (chiamato metodoKasiski - Prima guerra mondiale, 1863).

Sicurezza informatica

La Sicurezza informatica è quella branca dell’informatica che si occupa della sal-vaguardia dei sistemi informatici da potenziali rischi e/o violazioni dei dati. Iprincipali aspetti di protezione del dato sono la confidenzialità, l’integrità e ladisponibilità.

La protezione dagli attacchi informatici è quindi la chiave della sicurezza deisistemi telematici e si ottiene agendo su più livelli: a livello fisico/materiale (an-che se in questa fase intendiamo la sicurezza reale, non si tratta naturalmentedi “sicurezza informatica”) agendo direttamente sulla protezione dei sistemi piùimportanti, quali Server, Mainframe di database, ecc. . . Il livello logico che ante-pone uno strato di autenticazione e quindi una autorizzazione da parte dell’entitàche amministra il sistema protetto.

Sulla base di quanto detto, nella “sicurezza informatica” si usa spesso dividereil concetto di sicurezza, in due sottoclassi: la sicurezza passiva e la sicurezzaattiva.

Per sicurezza passiva si intendono un insieme di strumenti e tecniche che ven-gono adottate a scopo puramente difensivo, ossia quel complesso di soluzioni ilcui obiettivo è quello di impedire che utenti non autorizzati possano accedere arisorse, sistemi, impianti, informazioni e dati di natura riservata. È chiaro che ilconcetto di sicurezza passiva può essere esteso a molte altre situazioni al di fuori

1Il cifrario di Vigénère è il più semplice dei cifrari polialfabetici; fu pubblicato nel 1586 in untrattato di Blaise de Vigénère. Ritenuto per secoli un cifrario inattaccabile, ha goduto di una famadovuta soprattutto alla sua semplicità e in buona parte immeritata essendo molto più debole dialtri codici polialfabetici precedenti quali il disco dell’Alberti o le cifre del Bellaso.


Introduzione 5

dell’ambiente informatico, basti pensare alle soluzioni che si adottano per pro-teggere luoghi importanti come caveau di banche o locali che devono rimanereprotetti ad eventuali azioni di intrusione non autorizzate. In questi casi si adot-tano strumenti protettivi quali: porte di accesso blindate, personale di sicurezza,ecc. . . Questi sono indubbiamente considerati componenti di sicurezza passiva.

Per sicurezza attiva si intendono, invece, le tecniche e gli strumenti mediantei quali le informazioni ed i dati di natura riservata sono resi intrinsecamentesicuri, proteggendo gli stessi sia dalla possibilità che un utente - hacker - nonautorizzato possa accedervi (proprietà di confidenzialità2), sia dalla possibilitàche un individuo non autorizzato possa modificarli (proprietà di integrità3).

Secure Shell

Partendo dal concetto di sicurezza passiva, uno strumento fondamentale che si èaffermato il questi ultimi anni, è il protocollo SSH (Secure SHell). Tale sistemapermette di avere una sessione remota con un’altra macchina, dove si possonoeseguire operazioni in maniera protetta, attraverso una connessione dati criptata.

Analogamente ad altri protocolli come il famosissimo Telnet, SSH si presen-ta con un’interfaccia a riga di comando (solitamente una Shell4), dove tutto loscambio delle informazioni avviene in maniera cifrata. Secure Shell fornisce unaserie di servizi che lo rendono uno degli strumenti più potenti per l’amministra-zione di remota di sistemi “Unix Like” 5 e di dispositivi di rete quali:

� un’infrastruttura per connessioni crittografate;

� un’autenticazione forte tra i due host e tra utente ed host;

� la possibilità di creare un canale di comunicazione sicuro attraverso il qualeveicolare qualsiasi connessione TCP/IP;

� la soluzione ad alcuni problemi noti in TCP/IP come l’IP spoofing, il DNSspoofing e il Routine spoofing; dove con il termine spoofing si intende lafalsificazione delle informazioni inerente ad un servizio.

2Con il termine confidenzialità si intende la protezione dei dati e delle informazioni scambiatetra un mittente e uno o più destinatari nei confronti di terze parti.

3Con il termine integrità si intende, nell’ambito della sicurezza informatica, la protezione deidati e delle informazioni nei confronti delle modifiche del contenuto effettuate da una terzaparte; viene compreso anche il caso limite della generazione ex novo di dati ed informazioni nonlecite.

4In un sistema operativo, la shell è il programma che permette agli utenti di comunicare conil sistema e di avviare i programmi. È una delle componenti principali di un sistema operativo,insieme al kernel.

5per sistemi “Unix Like” si intende quei sistemi operativi derivati da Unix come Gnu/Linux,BSD, ecc. . .


Introduzione 6

Un po’ di storia

Il protocollo Secure Shell venne sviluppato per la prima volta nel 1995 dal ricer-catore finlandese Tatu Ylönen presso l’università finlandese Helsinki, dopo esserestato vittima di vari attacchi durante alcune sessioni tramite Telnet. In partico-lare gli attacchi erano stati compiuti tramite sniffing per cercare di recuperarela password. Per definizione, la parola sniffing indica quell’attività che permetteun’intercettazione passiva dei dati che transitano in una rete telematica. Taleattività può essere svolta sia per scopi legittimi (ad esempio l’individuazione diproblemi di comunicazione o di tentativi di intrusione) sia per scopi illeciti comel’intercettazione fraudolenta di password o altre informazioni riservate.

Con il passare del tempo la versione di SSH - denominata versione SSH1 -sviluppata da Tatu venne arricchita di funzionalità nuove tramite l’inserimentodi modifiche (anche pesanti) nella struttura del codice. Divenne chiaro che ilcodice andava totalmente riscritto e riorganizzato. Nel 1996 venne rilasciata laversione del protocollo SSH2, che non è considerata compatibile con il protocolloSSH1 iniziale.

Nel 1999 alcuni sviluppatori di software diedero vita alla prima implemen-tazione libera di SSH, partendo dalla release 1.2.12 che era l’ultima rilasciatasotto autorizzazione libera. Björn Grönvall creò OSSH che da lì a poco, vennerielaborata dagli sviluppatori di OpenBSD6 dando vita a OpenSSH inclusa nellaversione 2.6 di OpenBSD. Successivamente vennero creati vari port ad altri siste-mi operativi cosicché nel 2005 erano ormai moltissimi i sistemi che adottavanoOpenSSH.

Versioni a confronto

Come introdotto, le versioni di SSH esistenti sono due: la versione SSH1 e laversione SSH2. La differenza sostanziale tra queste due implementazioni, oltrealla totale incompatibilità, risiede nell’architettura adottata. La prima versione diSecure Shell, adotta una struttura “integrata” senza stratificazioni nelle varie fun-zioni di autenticazione, connessione e trasporto. La versione SSH2 del protocolloridefinisce l’architettura “integrata” adottata nella prima versione, dividendo instrati le varie funzioni, offrendo così maggiore sicurezza; vengono introdotti glistrati di SSH Transport Layer Protocol, SSH Authentication Protocol e SSH Con-nection Protocol. Per il controllo dell’integrità, la versione SSH1 adotta CRC32(non sicuro) mentre la versione SSH2 adotta il metodo di crittazione con hashHMAC. HMAC non è propriamente una funzione di hash, poiché per eseguirloè necessario non solo il testo in chiaro (preso come unico parametro di input

6OpenBSD è un sistema operativo basato sulla variante BSD di Unix, considerato par-ticolarmente interessante per la sua sicurezza e per possedere un sistema di crittografiaintegrato.


Introduzione 7

dalle funzioni di hash più comuni), ma anche una chiave. Un’altra caratteristicache contraddistingue le due versioni è la gestione dei canali di comunicazionetra host e host: la versione SSH1 può mantenere un solo canale per sessione, adifferenza della versione di SSH2 che per ogni sessione adotta molteplici canalidi comunicazione.

Per quanto riguarda l’utilizzo dei metodi di cifratura, e la gestione delle chia-vi, la versione SSH2 adotta vari metodi di negoziazione rispetto alla precedenteversione ed inoltre utilizza sia l’RSA che il DSA come algoritmo a chiave pubbli-ca. La negoziazione della chiave di sessione per il protocollo SSH2 viene gestitatramite l’algoritmo Diffie-Hellman7, ed inoltre viene rinnovata più volte nell’arcodi una stessa sessione. Parlando invece della versione SSH1, le cose sono moltopiù semplici a livello implementativo, ma indubbiamente meno sicure: la chiavedi sessione viene trasmessa dal lato client, e questa rimane invariata per tutta lasessione.

Tabella 1: Tabella comparativa delle versioni di SSH1 vs SSH2.

Release SSH1 Release SSH2Architettura Struttura “integrata”. Divisione della struttura negli

strati di autenticazione, connes-sione e trasporto.

Integrità CRC-32. HMAC (hash encryption).Sessione Utilizzo di un canale

per sessione.Molteplici canali per una singolasessione.

Negoziazione Algoritmo simmetri-co per la negoziazio-ne; stesso identifica-tivo di sessione perentrambe le parti.

Algoritmo simmetrico a chiavepubblica, e compressione; chia-ve di sessione indipendente tra ledue parti.

Algoritmi Algoritmo RSA a chia-ve pubblica.

Utilizzo di RSA e DSA a chiavepubblica.

Chiave di sessione Trasmessa dal latoclient. Stessa chiaveper la sessione.

Negoziata attraverso l’algorit-mo Diffie-Helman. Chiave sisessione rinnovabile.

7Si veda la sezione 1


Algoritmi di crittografia supportati 8

1 Algoritmi di crittografia supportati

I dati scambiati con SSH sono cifrati con algoritmi a chiave simmetrica negoziatitra le parti. Le chiavi per gli algoritmi di cifratura sono scambiate in precedenzatramite l’algoritmo di Diffie-Hellman. La cifratura previene, tra le altre cose, gliattacchi di tipo sniffing (cattura del traffico passante per una interfaccia di rete).Poiché i server SSH e i client possono essere configurati per autorizzare diversitipi di autenticazione, questo metodo offre un ottimo controllo a entrambe leparti. Il server stabilisce i metodi di cifratura supportati e il client può sceglierel’ordine dei metodi di autenticazione da utilizzare. SSH supporta algoritmi dicrittografia e sfrutta sia sistemi a chiave pubblica (RSA e DSA) che quelli a chiavesimmetrica quali IDEA, DES, 3DES, Arcfour e Blowfish.

Algoritmo Diffie-Hellman

L’algoritmo Diffie-Hellman risale al 1976 ed è quindi uno dei più antichi algo-ritmi a chiave pubblica; gli autori furono anche i primi a proporre l’idea deicifrari a chiave pubblica. Tale sistema è particolarmente adatto alla generazionedi una chiave segreta tra due corrispondenti che comunicano attraverso un ca-nale non sicuro. La sicurezza dell’algoritmo in esame si basa sulla complessitàcomputazionale del calcolo del logaritmo discreto.

Passi dell’algoritmo Supponiamo che due utenti Alice e Bob vogliono scam-biarsi una chiave segreta in modo sicuro. Alice genera e comunica pubblicamen-te a Bob un numero primo N molto elevato (ad esempio un numero costituitoda 1024bit, circa 300 cifre decimali) e un generatore g (che esiste sicuramenteessendo N primo); si potrebbero anche usare due numeri N e g pubblicati daun qualche ente. Arrivati a questo punto, l’algoritmo si composta nel seguentemodo:

1. Alice genera un numero casuale a < N e calcola A = gamodN . Il numeroA viene comunicato pubblicamente a Bob;

2. In modo del tutto analogo Bob genera due numeri b e B = gbmodN e inviaB ad Alice;

3. Alice calcola il numero k = BamodN ;

4. Bob calcola k = AbmodN .

È semplice intuire che le due chiavi k sono uguali! Infatti entrambe vale chega�bmodN . A questo punto Alice e Bob possono usare la chiave k per comunicarecon un cifrario simmetrico ad esempio il DES.



Sicurezza dell’algoritmo - L’attacco dell’Hacker La cosa importante per la si-curezza è che un terzo che intercettasse i quattro numeri N; g;A;B non sarebbein grado di ottenere k = gab non conoscendo né a né b. In effetti a = logg(A)

e b = logg(B) ma essendo il calcolo del logaritmo discreto computazionalmen-te proibitivo come una fattorizzazione è pressoché impossibile calcolare questilogaritmi per numeri di 1024 bit.

Come altri sistemi a chiave pubblica anche DH è però esposto all’attacco delterzo uomo interposto. Nel nostro esempio immaginiamo che Trudy intercetti ilnumero A che Alice invia a Bob e, fingendo di essere Bob, generi un suo numeroB e lo invii ad Alice. A questo punto Alice e Trudy generano la chiave segreta ke comunicano via DES; e Trudy può tranquillamente leggere tutti i messaggi cheAlice crede di inviare a Bob! Peggio ancora: Trudy può ripetere il gioco anchecon Bob fingendosi Alice e di qui in avanti, intercettare e leggere tutta la corri-spondenza tra i mal capitati Alice e Bob. Per prevenire simili attacchi la soluzioneè quella di usare una Certification Authority8 che garantisca l’identità dei corri-spondenti. Alice e Bob potranno ad esempio identificarsi con un meccanismo difirma digitale, utilizzando le chiavi pubbliche fornite dall’ente certificatore.

1.1 Algoritmi a chiave pubblica

La crittografia a chiave pubblica o asimmetrica, conosciuta anche come crittogra-fia a coppia di chiavi o a chiave pubblica/privata, è fondata sull’algoritmo RSA.Ogni attore coinvolto possiede una coppia di chiavi:

� la chiave privata, personale e segreta, viene utilizzata per decodificare undocumento criptato;

� la chiave pubblica, che deve essere distribuita, serve a criptare un docu-mento destinato alla persona che possiede la relativa chiave privata.

La sicurezza del sistema dipende dalla segretezza della chiave di codifica utiliz-zata, quindi è necessario almeno un canale sicuro attraverso il quale trasmetterela chiave.

1.1.1 Algoritmo RSA

Il nome dell’algoritmo RSA deriva dalla prima lettera dei cognomi di coloro chelo inventarono nell’Aprile del 1977: Ronald L. Rivest, Adi Shamir e Leonard M.Adleman.

8In crittografia, una Certificate Authority o Certification Authority (in breve CA) è una entitàche rilascia certificati digitali verso terze parti.



Analisi dell’algoritmo L’algoritmo potrebbe essere facilmente suddiviso in dueparti: la generazione della coppia di chiavi e il loro utilizzo.

La prima parte, la generazione della coppia di chiavi, viene solitamente effet-tuata in questo modo:

� vengono scelti due numeri primi p, q molto grandi;

� viene calcolato n = pq, e la funzione di Eulero �(n) = (p � 1)(q � 1) dopodi che i due primi p, q vengono eliminati;

� si sceglie un intero e minore di �(n) e primo con esso;

� utilizzando la versione estesa dell’algoritmo di Euclide viene calcolato l’in-tero d così da avere e x d = 1mod�(n);

� vengono resi pubblici i valori e, n che costituiscono la chiave pubblica emantenuto segreto d che, utilizzato con n rappresenta la chiave privata.

Una volta generata la coppia di chiavi, le operazioni effettuabili da due uten-ti, l’Utente A e l’Utente B, entrambi con la propria coppia di chiavi, pubblica eprivata, più la chiave pubblica della controparte, sono:

� L’Utente A invia del materiale cifrato all’Utente B, utilizzando la chiave pub-blica dell’Utente B.L’operazione di firma prevede l’utilizzo della chiave privata dell’Utente A

� Ricevuti i dati cifrati, l’Utente B utilizza la sua chiave privata per eseguirel’operazione opposta di decifratura.Per verificare i dati ricevuti, l’Utente B utilizzerà la chiave pubblica dell’u-tente A.

Il testo in chiaro viene visto come una stringa di bit e viene diviso in blocchicostituiti da kbit, dove k è il più grande intero che soddisfa la disequazione2k < n.

A questo punto per ogni blocco M si procede con la cifratura calcolandoMc = M e mod n. In ricezione, invece, per decifrare Mc si calcola Md

c mod n.Come si può capire, da quanto appena detto, per la cifratura si devono conosceree ed n, cioè la chiave pubblica, mentre per decifrare è necessario conoscere d edn, ovvero la chiave segreta.

Sicurezza dell’RSA Il codice RSA viene considerato sicuro perché non è anco-ra stato trovato il modo per fattorizzare numeri primi molto grandi, che significariuscire a trovare p e q conoscendo n. Nel corso degli anni l’algoritmo RSA ha piùvolte dimostrato la sua robustezza: in un esperimento del 1994, coordinato daArjen Lenstra dei laboratori Bellcore, per rompere una chiave RSA di 129 cifre,svelando il meccanismo con cui quella chiave generava messaggi crittografati,



sono stati necessari 8 mesi di lavoro coordinato effettuato da 600 gruppi di ricer-ca sparsi in 25 paesi, che hanno messo a disposizione 1600 macchine da calcolo,facendole lavorare in parallelo collegate tra loro attraverso Internet.

Data la mole delle risorse necessarie per rompere la barriera di sicurezza del-l’algoritmo RSA, è chiaro come un attacco alla privacy di un sistema a doppiachiave non sia praticamente realizzabile. Inoltre, nell’esperimento era stata uti-lizzata una chiave di 129 cifre mentre i programmi di crittografia attualmentea disposizione prevedono chiavi private con una robustezza che raggiunge e su-pera i 2048 bit, risultando quindi praticamente inattaccabili, visto anche chel’ordine di grandezza dei tempi necessari alla rottura di chiavi di questo tipo èesponenziale.

1.1.2 Algoritmo DSA

DSA (Digital Signature Algorithm) è un algoritmo che viene utilizzato prettamen-te per firmare messaggi e non può essere utilizzato per criptare. La sicurezza diquesto algoritmo dipende dalla difficoltà di calcolare logaritmi discreti.Nel 1994 il NIST, l’ente federale USA, nel quadro degli standard DSS (DigitalSignature Standard) ha approvato l’algoritmo DSA come standard federale perla firma digitale (DSA non è utilizzabile per la crittazione). Usa un algoritmoinventato da David Kravitz e derivato da quello di Schnorr.La configurazione dell’algoritmo DSA richiede di fissare alcuni parametri e quindidi generare le chiavi segreta e pubblica:

� Si fissa un numero primo m da usare nelle operazioni di resto modulo, con2511 < m < 2512.

� Si fissa un numero Q, divisore primo di m� 1, con 2159 < Q < 2160.

� Si fissa un numero G, con 0 < G < m� 1.

� Si sceglie una chiave segreta SA, con 0 < SA < Q.

� La chiave pubblica si calcola come PA = GSA.

Indicando esplicitamente il modulo impiegato come pedice della coppia di pa-rentesi quadrate, per la firma del messaggio M si procede così:

� Si sceglie un numero h, con 0 < h < Q.

� Si calcola u = [[Gh]m]Q.

� Si determina il valore di v risolvendo la relazione D(M) = [SAu + hv]Q,dove D() è la funzione digest scelta.

� La firma digitale di M è la coppia di numeri (u; v).



Per la verifica della firma digitale:

� Si determina w tale che wv = [1]Q;

� Si calcola i = [D(M)w]Q;

� Si calcola l = [uw]Q;

� Si calcola t = [[GiPA]m]Q;

� Si verifica che sia t = u.

DSA è stato criticato dalla comunità crittografica per varie ragioni: la verificadella firma, una operazione senzaltro più comune della sua generazione, è parti-colarmente inefficiente ed è più lenta dalla generazione della firma stessa; l’iterdi approvazione di questo standard da parte del NIST è stato piuttosto arbitrarioe con un ampio contributo da parte di NSA; esistono alcuni particolari numeriprimi che, se usati dal programma per la generazione della firma, possono in-debolire l’algoritmo e, sebbene alcuni di questi numeri sono stati individuati, èplausibile che ve ne siano altri ancora da scoprire; il range dei parametri ammessisembra piuttosto arbitrario.

1.2 Algoritmi a chiave simmetrica

La crittografia simmetrica si basa su un algoritmo che modifica i dati in base auna chiave (di solito una stringa di qualche tipo) che permette il ripristino deidati originali soltanto conoscendo la stessa chiave usata per la cifratura. Per uti-lizzare una cifratura simmetrica, due persone si devono accordare sull’algoritmoda utilizzare e sulla chiave. La forza o la debolezza di questo sistema, si basasulla difficoltà o meno che ci può essere nell’indovinare la chiave, tenendo con-to anche della possibilità elaborative di cui può disporre chi intende spiare lacomunicazione.

3DES Il 3DES è un cifrario a blocco che consiste nella tripla applicazione delDES (Data Encryption Standard) usando due chiavi, ciò irrobustisce molto il si-stema rispetto al DES (anche se sembra che il 3DES non sia così sicuro quantoci aspetteremmo). Il DES fu sviluppato da IBM nei primi anni ’70 con la colla-borazione dell’NSA ed usa chiavi a 64 bits, dei quali solo 56 sono effettivamenteutilizzati, gli altri 8 servono per il controllo di parità. Il DES è stato forzato gene-rando tutte le chiavi possibili (ricerca esaustiva); per il 3DES sono stati propostivari tipi di attacco, ma la richiesta di informazioni necessarie per attuarli li ren-dono impraticabili. Il 3DES è compatibile all’indietro col DES: tutto ciò che èstato cifrato col DES può essere decifrato col 3DES.



BLOWFISH Il Blowfish, sviluppato da B. Schneier, opera su blocchi di 64 bitscon chiavi di lunghezza variabile fino a 448 bits. È significativamente più velocedel DES e, si ritiene che sia, forse, l’algoritmo più sicuro attualmente disponibile.

1.3 Funzioni hash

Esistono dei meccanismi di cifratura che permettono soltanto di mascherare un’in-formazione senza prevedere una chiave per poter successivamente decodificareil messaggio. Tali metodi sono detti funzioni hash o cifratura a senso unico (one-way hash function) e sono utilizzati per la cifratura delle password o per la gene-razione di impronte digitali o message digest.Le password, infatti, non sono memorizzate in chiaro sul sistema, ma viene me-morizzata soltanto la loro cifratura, dalla quale non è possibile ritornare allapassword in chiaro. Quando un utente vuole accedere al sistema, il meccanismodi autenticazione richiede la password, la cifra con l’algoritmo di hashing con-siderato e confronta la password cifrata con quella memorizzata sul sistema perl’utente in questione. Se le due password cifrate coincidono, all’utente è permes-so accedere al sistema.Il message digest invece è un valore caratteristico di un messaggio o documento,calcolato applicando al messaggio stesso la funzione hash, che varia sensibilmen-te al variare del contenuto del messaggio.L’algoritmo di hashing deve essere in grado di generare un messaggio cifratoquanto più scorrelato possible dall’informazione originale e tale che sia estrema-mante improbabile che due messaggi diversi diano luogo allo stesso messaggiocifrato.

1.3.1 Algoritmi di cifratura

Di seguito sono riportati alcuni tra gli algoritmi più utilizzati per la cifratura confunzioni hash.

� MD5 (Message Digest 5) creato da R. Rivest nel 1991, è nato per sostituireMD4. Produce valori hash di 128 bit, accettando messaggi di input con lun-ghezza massima di 264 bit e scomponendoli in blocchi di 512 byte (vieneeventualmente effettuato un padding dei bit mancanti nell’ultimo blocco - ilpadding comprende comunque un valore di 64 bit che indica la lunghezzadel messaggio originale). Una descrizione dell’algoritmo è riportata nellaRFC 1321.

� SHA (Secure Hash Algorithm) è un algoritmo sviluppato nel 1994 dal NI-ST (National Istitute of Standard and Tecnology), FIPS 180, e dalla NSA(National Security Agency). Fornisce valori hash di 160 bit. La cifraturaviene effettuata su messaggi con lunghezza massima di 264 bit, scompo-nendoli in blocchi di 264 bit. Risulta un po’ più lento di MD5, ma produce



un message digest più grosso che lo rende più sicuro agli attacchi per forzabruta.

– SHA-1 è una revisione del 1995 dell’algoritmo SHA, che ne correggealcune falle (v. FIPS 180-1). Una sua descrizione è contenuta in nellostandard ANSI X9.30.

– SHA-2 è una nuova versione dell’algoritmo SHA, pubblicata nel 2002,che fornisce valori hash di 256 bit


Struttura e Funzionamento 15

2 Struttura e Funzionamento

2.1 Architettura del protocollo

Il funzionamento di SSH è molto simile a quello di SSL (infatti non è una coinci-denza che le funzioni crittografiche usate da OpenSSH siano fornite da OpenSSL,una versione open source del Secure Socket Layer sviluppato da Netscape). En-trambi possono instaurare una comunicazione cifrata autenticandosi usando hostkey ed eventualmente certificati che possono essere verificati tramite una autori-tà fidata.

Figura 1: Architettura del protocollo SSH

Ecco come si instaura una connessione:Prima il client ed il server si scambiano le loro chiavi pubbliche. Se la macchinadel client riceve per la prima volta una data chiave pubblica, SSH chiede all’u-tente se accettare o meno la chiave. Successivamente client e server negozianouna chiave di sessione che sarà usata per cifrare tutti i dati seguenti attraversoun cifrario a blocchi come il 3DES o Blowfish. Il Transport Layer Protocol si oc-cupa di questa prima parte, cioè di fornire autenticazione host, confidenzialità,integrità e opzionalmente compressione. Tale protocollo gira tipicamente su una



connessione TCP, ma potrebbe essere usato anche su un qualsiasi altro flusso didati affidabile.

Lo User Authentication Protocol autentica l’utente del client sul server. Sonoattualmente supportati tre tipi di autenticazione:

� Con chiave pubblica: il client invia un pacchetto firmato con la propriachiave privata. La firma è verificata dal server tramite la chiave pubblicadel client, che il server può possedere da eventuali connessioni precedenti.Nel caso in cui il server non possieda la chiave pubblica del client, questometodo fallisce.

� Con password: all’utente sul client viene presentato il solito prompt perl’inserimento della password. Generalmente questo metodo viene utilizzatosolo alla prima connessione ad un server.

� Host based: è simile al metodo rhosts di UNIX, ma è più sicuro, in quantoaggiunge ad esso la verifica dell’identità dell’host tramite la Host key.

Il server guida l’autenticazione, inviando al client la lista contenente i metodidi autenticazione supportati. Il client sceglie quello che considera più convenien-te. Infine, dopo una autenticazione con successo, tramite il Connection Protocolcomincia la vera sessione: il client può richiedere una shell remota, l’esecuzio-ne di un comando , un trasferimento di file sicuro, ecc. Il protocollo divide laconnessione in canali logici; tutti questi canali sono multiplexati in una singolaconnessione. In questo modo è possibile accedere a più servizi con un singolotunnel cifrato.

2.1.1 Host Keys

Ogni server dovrebbe avere una Host Key per ogni algoritmo a chiave pubblicasupportato. La Host Key del server è utilizzata durante lo scambio di chiavi perverificare che il client stia realmente comunicando con il server corretto. Duedifferenti modelli di fiducia possono essere utilizzati:

� Il client ha un database locale che associa ciascun nome di host con lacorrispondente chiave pubblica. Questo metodo non richiede infrastrutturecentralizzate. Lo svantaggio è che la gestione del database di associazionenome-chiavi può diventare gravosa.

� L’ associazione nome-chiavi è certificata da una autorità fidata di certifica-zione. Il client deve conoscere solo la chiave dell’autorità centrale e puòverificare la validità di tutte le chiavi in base alla certificazione dell’autoritàcentrale. Il protocollo prevede anche l’opzione che l’associazione nome-chiave non sia controllata alla prima connessione ad un dato host. Questoconsente la comunicazione senza che ci sia stata prima comunicazione dichiavi o certificazioni.



2.2 Transport Layer Protocol

Il Transport Layer Protocol è un protocollo di trasporto sicuro a basso livello.Fornisce crittografia forte, autenticazione crittografica degli host e protezionedell’integrità delle informazioni. Questo protocollo non si occupa dell’autentica-zione in quanto questo compito è demandato ai protocolli di livello superiore.Il protocollo è stato progettato per essere semplice, flessibile, per permettere lanegoziazione dei parametri e per minimizzare il numero di round-trips 9. Tut-ti gli algoritmi (scambio di chiavi, chiave pubblica, cifratura simmetrica ed ha-sh)vengono negoziati. Ci si aspetta che in molti ambienti siano necessari solo2 round-trips per completare lo scambio delle chiavi, l’autenticazione del server,la richiesta dei servizi e la notifica dell’accettazione della richiesta dei servizi.Il caso peggiore è 3 round-trips. Una volta completata la connessione TCP/IP, siprocede, in primis, allo scambio delle versioni di protocollo e software, che le dueparti si inviano vicendevolmente. Questo scambio serve a garantire la compati-bilità. Durante la fase di negoziazione degli algoritmi, poi, vengono stabiliti glialgoritmi per la cifratura, il controllo d’integrità e la compressione. Infine vieneeffettuato lo scambio delle chiavi. In questa fase avviene anche la verifica dell’i-dentità del server da parte del client e viene inoltre generato un identificatore disessione, utilizzato in molte fasi del protocollo e che verrà passato ai protocolliallo strato superiore.

2.2.1 Scambio delle versioni

Entrambe le parti devono mandare una stringa identificativa della forma SSH-protoversion-softwareversion-comments seguita da un carriage return ed uncarattere di newline. La lunghezza massima della stringa è di 255 caratteri, com-presi il carriage return ed il newline. La stringa di versione deve essere in formatoUS-ASCII, priva di spazi bianchi o segni ‘-’. La stringa di versione è utilizzata perabilitare estensioni di compatibilità e per indicare le capacità di una implementa-zione. La stringa di commento dovrebbe contenere informazioni addizionali utiliper risolvere problemi dell’utente.

2.2.2 Negoziazione degli algoritmi

All’inizio della fase di negoziazione degli algoritmi, entrambe le parti inviano lalista degli algoritmi supportati. Ogni parte coinvolta ha un algoritmo preferitoper ogni categoria, e si assume che molte implementazioni ad un dato tempopossano avere lo stesso algoritmo preferito. Ogni lato può indovinare quale algo-ritmo sta usando l’altro, e può mandare un pacchetto iniziale di scambio chiavi

9Tempo che trascorre tra l’invio di un pacchetto dati e la ricezione del corrispondentepacchetto di riscontro



appropriato per quei metodi. Se la scelta è giusta il pacchetto mandato vieneconsiderato come il primo pacchetto di scambio di chiavi, altrimenti il pacchettoviene ignorato e la controparte deve rinviare correttamente il pacchetto iniziale.Ciascuna delle stringhe degli algoritmi deve essere una lista di nomi separati davirgola. Ogni algoritmo supportato deve essere citato in ordine di preferenza. Ilprimo algoritmo deve essere quello preferito. Ogni stringa deve contenere alme-no un nome. Il cookie deve essere un valore casuale generato dal mittente. Ilsuo scopo è di rendere impossibile per entrambe le parti di determinare piena-mente le chiavi e l’identificatore di sessione. Se entrambe le parti fanno la stessascelta per un determinato algoritmo, quest’ultimo deve essere usato. Altrimentil’algoritmo deve essere scelto iterando sulla lista del client e scegliendo il primosupportato anche dal server.

2.2.3 Scambio di chiavi

Lo scambio di chiavi parte dalla generazione di due valori: un segreto condivi-so K, ed un valore hash di scambio H. La modalità di generazione di tali valoridipende dall’algoritmo utilizzato. Al momento l’unico metodo che tutte le imple-mentazioni devono supportare è quello di Diffie-Hellman. Le chiavi per gli algo-ritmi di cifratura ed autenticazione sono derivate da questi. Il valore di scambioH del primo scambio di chiavi è anche utilizzato come identificatore di sessione,che è unico per la connessione ed una volta calcolato non cambia anche se lechiavi sono riscambiate in seguito. Ogni metodo di scambio di chiavi specificauna funzione hash che è usata nello scambio. Lo stesso algoritmo hash deve es-sere utilizzato per il calcolo delle chiavi.Una volta ottenuti H e K, chiavi e vettori di inizializzazione (IV) sono calcolaticome funzioni HASH con i seguenti parametri:

� IV iniziale da client a server: HASH(KjjHjj00A00jjsessionid)

� IV iniziale da server a client: HASH(KjjHjj00B00jjsessionid)

� Chiave di cifratura da client a server: HASH(KjjHjj00C 00jjsessionid)

� Chiave di cifratura da server a client: HASH(KjjHjj00D00jjsessionid)

� Chiave di integrità da client a server: HASH(KjjHjj00E 00jjsessionid)

� Chiave di integrità da server a client: HASH(KjjHjj00F 00jjsessionid)

I dati della chiave vanno scelti dall’inizio dell’output dell’hash. Per gli algo-ritmi a chiave di lunghezza variabile dovrebbero essere usati 128 bit. Lo scam-bio delle chiavi termina con entrambe le parti che si scambiano il messaggioSSH_MSG_NEWKEYS. Altri messaggi validi dopo lo scambio delle chiavi sono:SSH_MSG_DEBUG, SSH_MSG_DISCONNECT e SSH_MSG_IGNORE



2.2.4 Compressione

La fase di compressione viene inizializzata dopo lo scambio delle chiavi. Se èstata negoziata la compressione, il campo payload (e solo quello) sarà compressoutilizzando l’algoritmo negoziato.I campi lunghezza e MAC saranno computati dal campo payload compresso. Lacifratura sarà eseguita dopo la compressione. Le implementazioni devono con-sentire di scegliere l’algoritmo indipendentemente per ogni direzione.Sono attualmente definiti i seguenti metodi di compressione:

none REQUIRED no compressionzlib OPTIONAL GNU ZLIB (LZ77) compression

2.2.5 Integrità dei dati

L’integrità dei dati è protetta includendo in ogni pacchetto un MAC che è compu-tato da un segreto condiviso, un numero di sequenza del pacchetto e il contenutodel pacchetto.Gli algoritmi e le chiavi di autenticazione sono negoziate durante lo scambio del-le chiavi.Dopo lo scambio delle chiavi, il MAC selezionato sarà computato prima della ci-fratura dalla concatenazione dei seguenti dati:mac = MAC(key, sequence_number || unencrypted_packet)dove unencrypted_packet è l’intero pacchetto senza MAC (campi lunghezza, pay-load e padding), e sequence_number è un numero di sequenza del pacchettorappresentato come un intero a 32 bit privo di segno. Il sequence_number è ini-zializzato a zero per il primo pacchetto, ed è incrementato dopo ogni pacchetto.Esso non è mai incluso nei dati del pacchetto.

Gli algoritmi di MAC devono girare in maniera indipendente l’uno dall’altro,quindi le implementazioni devono permettere di scegliere gli algoritmi indipen-dentemente per ogni direzione. Il campo mac deve essere trasmesso alla finedel pacchetto senza essere cifrato. Il numero di byte di questo campo dipendonodall’algoritmo scelto.

2.2.6 Cifratura

L’algoritmo di cifratura viene negoziato durante lo scambio delle chiavi. I campilunghezza, padding_length, payload e padding devono essere cifrati con l’algorit-mo stabilito. Tutti gli algoritmi di cifratura dovrebbero usare chiavi di lunghezzaeffettiva pari o superiore a 128 bit. Gli algoritmi di cifratura devono girare in ma-niera indipendente l’uno dall’altro, quindi le implementazioni devono permettere



3des-cbc REQUIRED three-key 3DES in CBC modeblowfish-cbc RECOMMENDED Blowfish in CBC modetwofish256-cbc OPTIONAL Twofish in CBC mode, with 256-

bit keytwofish-cbc OPTIONAL alias for twofish256-cbctwofish192-cbc OPTIONAL twofish with 192-bit keytwofish128-cbc RECOMMENDED Twofish with 128-bit keyaes256-cbc OPTIONAL AES (Rijndael) in CBC mode,

with 256-bit keyaes192-cbc OPTIONAL AES with 192-bit keyaes128-cbc RECOMMENDED AES with 128-bit keyserpent256-cbc OPTIONAL Serpent in CBC mode, with 256-

bit keyserpent192-cbc OPTIONAL Serpent with 192-bit keyserpent128-cbc OPTIONAL Serpent with 128-bit keyarcfour OPTIONAL the ARCFOUR stream cipheridea-cbc OPTIONAL IDEA in CBC modecast128-cbc OPTIONAL CAST-128 in CBC modenone OPTIONAL no encryption; NOT RECOM-

MENDED

di scegliere gli algoritmi indipendentemente per ogni direzione. Sono attualmen-te definiti i seguenti algoritmi di cifratura:

2.3 Authentication Protocol

L’SSH Authentication Protocol è un protocollo di autenticazione dell’utente general-purpose. Gira al di sopra dell’SSH Transport Layer Protocol.L’Authentication Protocol assume che il protocollo sottostante fornisca protezionedell’integrità dei dati e confidenzialità. Quando questo protocollo parte, ricevedal protocollo al livello inferiore un identificatore (questo è il valore di scambioH dal primo scambio di chiavi) che indica univocamente la sessione.

2.3.1 Autenticazione: schema generale

Il server guida l’autenticazione comunicando al client quali metodi di autentica-zione possono essere utilizzati ad ogni istante. Il client ha la libertà di provarei metodi elencati dal server in qualsiasi ordine. Questo dà al server il completocontrollo sul processo di autenticazione ed al client la libertà di scegliere i metodipiù convenienti quando il server offre più metodi. I metodi sono identificati condei nomi:



� Nel metodo publickey, il client invia al server un pacchetto firmato con lasua chiave privata, il server autorizza l’autenticazione se la firma è valida.

� Il metodo “password” è quello tradizionale: Il client invia la sua passworddi login ed il server la verifica.

� Il metodo host based è simile agli stili di autenticazione rhosts e hosts.equivdi UNIX, ma l’identità dell’host del client è controllata più rigorosamentetramite una firma generata con la chiave dell’host del client.

� Il metodo “none” (nessuna autenticazione) è riservato è non deve essere in-cluso nella lista dei metodi supportati. Il server deve comunque respingereun tale richiesta, a meno che il client non sia effettivamente autorizzato adentrare nel sistema senza autenticarsi.

Da notare che, in base alla sua politica, il server può richiedere autenticazionimultiple per un dato utente o gruppo di utenti o per client connessi da un de-terminato host; inoltre dovrebbe avere un timeout per l’autenticazione e discon-nettere se l’autenticazione non è stata completata entro quel periodo. Il periodoraccomandato è 10 minuti. Addizionalmente, le implementazioni dovrebberolimitare il numero di tentativi di autenticazione falliti da parte del client.

2.3.2 Metodo di autenticazione a chiave pubblica.

L’unico metodo di autenticazione richiesto è quello a chiave pubblica. Tutte le im-plementazioni devono supportare tale metodo che consente di autenticarsi grazieal possesso di una chiave privata. Il metodo funziona inviando una firma creatacon la chiave privata dell’utente. Il server deve controllare sia che la chiave è unautenticatore valido per l’utente, sia che la firma è valida. Se entrambe questecose sono verificate, il server accetta la richiesta, altrimenti la rifiuta.

2.3.3 Metodo di autenticazione con password

È compito del server verificare la password all’interno del proprio database. An-che se la password è trasmessa in chiaro all’interno del pacchetto, l’intero pac-chetto è criptato al livello di trasporto. Se non vengono utilizzati confidenzialitàe controllo dell’integrità, il cambio della password dovrebbe essere disabilitato.Normalmente il server risponde con un messaggio di successo o di fallimento,ma potrebbe anche chiedere il cambio della password.

2.3.4 Autenticazione Host-based

Questa forma di autenticazione è opzionale. È basata sul nome dell’host su cuigira il client e dell’utente che lo sta utilizzando. Non è consigliabile per siti adalta sicurezza, ma può risultare molto utile in alcuni ambienti.



Quando viene utilizzata, si dovrebbe porre molta attenzione a che l’utente nonottenga la chiave privata dell’host.Questo metodo funziona tramite un algoritmo di firma: il client crea una firmacon la chiave privata dell’host che il server verifica tramite la chiave pubblica del-l’host stesso. Una volta stabilita l’identità, l’autorizzazione è effettuata basandosisugli username dell’utente sul client e sul server, e sul nome host del client.Il client include la firma, generata usando la sua chiave privata, nel messaggioseguente. Il server deve verificare che la host key appartenga effettivamente alclient, che l’utente specificato abbia il permesso di fare il login, e che la firma siavalida.

2.4 Connection Protocol

Il Connection Protocol è stato progettato per girare al di sopra dello User Au-thentication Protocol. Il suo scopo è quello di permettere sessioni interattive dilogin, esecuzione remota di comandi, inoltro di connessioni TCP/IP ed inoltro diconnessioni X11.Il service name per questo protocollo è ssh-connection. La connessione è divisain canali logici; tutti questi canali sono multiplexati in un singolo tunnel cifra-to. Tutti gli pseudo-terminali, connessioni inoltrate, ecc. sono considerati canali,essi possono essere aperti sia dal client che dal server e sono identificati da nu-meri(da entrambe le parti), che possono essere differenti tra lato client e latoserver. Le richieste di apertura di un canale conterranno il numero di canaledel mittente ed ogni altro messaggio relativo ad un canale conterrà il numerodel canale del ricevente. I canali hanno un meccanismo di controllo del flusso,questo significa che non possono essere inviati dati su di un canale se prima nonsi è ricevuto messaggio circa la disponibilità della “window space”. Si possonoavere richieste che coinvolgono globalmente lo stato della parte remota e chesono indipendenti dai canali. Un esempio è una richiesta di iniziare un TCP/IPforwarding per una porta specifica.

2.4.1 Meccanismo dei canali: Schema generale

Quando una delle parti desidera aprire un nuovo canale per prima cosa allocalocalmente un numero per quel canale. Fatto ciò invia un messaggio alla contro-parte contenente il numero di canale allocato, il tipo di canale desiderato (pty,x11 forwarding ecc.), la dimensione iniziale per la “window size” e la dimensio-ne massima per i pacchetti in transito su quel canale (ad esempio si potrebberovolere pacchetti più piccoli per sessioni interattive come terminali per miglioriprestazioni su link lenti).La parte remota quindi decide se può aprire il canale. Quando una delle partivuole chiudere una canale spedisce un messaggio SSH_MSG_CHANNEL_CLOSE.



Un canale è considerato chiuso quando è stato sia inviato che ricevuto un mes-saggio di chiusura.

2.4.2 TCP/IP Port Forwarding

Questo è un meccanismo che permette di creare un canale di comunicazionesicuro attraverso il quale veicolare qualsiasi tipo connessione TCP. Quello cheavviene nella pratica è che viene creato una canale di comunicazione cifratotra la porta all’indirizzo remoto a cui ci si vuole collegare e una porta locale(libera). Fatto ciò le applicazioni punteranno il collegamento alla porta localee la connessione verrà inoltrata automaticamente all’ host remoto attraverso uncanale sicuro.

2.5 Estensibilità di SSH

Per come è strutturato il protocollo SSH potrà essere oggetto di evoluzioni con-tinue nel tempo, ed alcune organizzazioni potrebbero voler utilizzare i proprialgoritmi di cifratura, autenticazione e scambio delle chiavi. Una registrazionecentrale di tutte le estensioni è gravosa ma senza essa ci sarebbero conflitti negliidentificatori dei metodi, rendendo difficile l’interoperabilità. Si è perciò sceltodi identificare algoritmi, metodi, formati e protocolli di estensione con nomi te-stuali di un formato specifico: vengono utilizzati i nomi DNS per creare spazi dinomi locali, di modo che estensioni sperimentali o estensioni classificate possanoessere utilizzati senza timore di conflitti con altre implementazioni. Lo scopo èquello di mantenere il protocollo quanto più semplice possibile, con un insiemedi algoritmi fondamentali quanto più piccolo possibile. Tutte le implementazionidevono supportare tale insieme per assicurare l’interoperabilità.

2.5.1 Nomi di algoritmi

Il protocollo identifica gli algoritmi e i protocolli con stringhe in formato US-ASCII non più lunghe di 64 caratteri. Tali nomi devono essere case-sensitive.Ci sono degli algoritmi standard che tutte le implementazioni devono supporta-re. Anche altri algoritmi sono stati definiti nell specifica del protocollo, ma sonoopzionali. Ci sono due formati per i nomi degli algoritmi. I nomi che non conten-gono il segno ‘@’ sono riservati e non possono essere utilizzati senza il consensodell’IETF (es. 3des-cbc, sha-1, hmac-sha1 e zlib). Chiunque invece può definirealgoritmi addizionali usando nomi nel formato name@domainname. La parteche segue il carattere ‘@’ deve essere un autentico nome di dominio internet.



2.6 Politiche Locali

Il protocollo consente la piena negoziazione di algoritmi e formati di cifratura, in-tegrità, scambio di chiavi e compressione. Le politiche locali dovrebbero guidarela configurazione dei seguenti passi:

� Specificare l’algoritmo preferito di cifratura, integrità e compressione (se-paratamente per ogni direzione).

� Stabilire i metodi a chiave pubblica e di scambio delle chiavi da usare perl’autenticazione dell’host.

� Stabilire i metodi di autenticazione richiesti per ogni utente. Le politichelocali possono richiedere autenticazioni multiple per alcuni o per tutti gliutenti.

� Le operazioni che l’utente può effettuare tramite il Connection Protocol. Peresempio le politiche non dovrebbero permettere al server di iniziare sessio-ni o impartire comandi al client. Le politiche dovrebbero inoltre stabilirequali porte possono essere inoltrate e da chi, dal momento che la tecnicadi port forwarding può oltrepassare le restrizioni di sicurezza stabilite daifirewall .

2.7 Aspetti di Sicurezza

Il Transport Layer Protocol fornisce un canale criptato sicuro su di una rete insi-cura. Effettua autenticazione del server, scambio di chiavi, cifratura e protezionedell’integrità. Ottiene anche un unico identificatore di sessione che può esse-re usato dai protocolli allo strato superiore. Questo protocollo è progettato peressere usato su uno strato di trasporto affidabile. Se avvengono errori di trasmis-sione o manipolazione dei messaggi, la connessione è chiusa. Se ciò accade, laconnessione dovrebbe essere ristabilita.Attacchi del tipo denial of service sono quasi impossibili da evitare. Il protocolloSSH non è stato progettato per eliminare canali coperti. Per esempio il padding,messaggi SSH_MSG_IGNORE, ed altri punti del protocollo possono essere usatiper passare informazioni coperte, ed il destinatario non ha alcun mezzo affidabileper verificare che informazioni del genere siano state spedite. Lo scopo dell’Au-thentication Protocol è di effettuare l’autenticazione dell’utente. Si assume chequesto protocollo giri su un protocollo a livello di trasporto sicuro, che ha già au-tenticato il server, stabilito un canale di comunicazione criptato e computato unidentificatore di sessione. È il protocollo di trasporto a fornire segretezza per l’au-tenticazione con password. Il server può andare in sleep dopo numerosi tentatividi autenticazione falliti per evitare attacchi di ricerca della chiave. Se il livellodi trasporto non fornisce cifratura, i metodi di autenticazione che si basano su



dati segreti dovrebbero essere disabilitati. Se non fornisce integrità, le richiestedi cambiare i dati di autenticazione (password) dovrebbero essere disabilitati perevitare che vengano cambiati da un hacker in un attacco di tipo denial of servi-ce, rendendo impossibile un accesso futuro. Il server può decidere, in base allepolitiche locali di sicurezza, quali e quanti metodi di autenticazione utilizzareper ciascun utente. Particolare attenzione va posta nel progettare i messaggi didebug. Essi potrebbero rivelare più informazioni sull’host di quante questi nonne voglia rivelare. I messaggi di debug possono comunque essere disabilitati.Si assume che il Connection Protocol giri al di sopra di un protocollo di trasportosicuro che ha già autenticato la macchina server, stabilito un canale di comuni-cazione cifrato, computato un identificatore di sessione, autenticato l’utente.Come si è visto questo protocollo permette l’esecuzione di comandi su macchineremote e permette così anche al server di eseguire comandi sul client. Normal-mente le implementazioni devono evitare questa possibilità dato che un servercorrotto può essere usato per attaccare tutti i client che si connettono. Miglioratala sicurezza per connessioni al server X11, alla chiusura del canale non restanoinformazioni riguardo all’autenticazione sul server. Il port forwarding può po-tenzialmente permettere ad un intruso di scavalcare sistemi di sicurezza come ifirewall; tuttavia questo poteva già essere fatto in altri modi. In ogni caso si ren-de necessaria una buona politica di controllo poiché, in quanto cifrato, il trafficonon può essere esaminato dal firewall. Quindi le implementazioni di SSH do-vrebbero disabilitare tutte le politiche potenzialmente dannose (ad esempio X11forwarding e TCP/IP forwarding) nel momento dello scambio delle chiavi.


OpenSSH 26

3 OpenSSH

OpenSSH è una suite di protocolli gratuita che fornisce cifratura per servizi direte, come il login remoto o il trasferimento di file remoto. OpenSSH è princi-palmente sviluppato dal Progetto OpenBSD, e la sua prima inclusione all’internodel sistema operativo avvenne in OpenBSD 2.6. Il software viene sviluppato aldi fuori degli USA, usando codice proveniente da circa 10 paesi diversi, ed essoè utilizzabile e riutilizzabile da chiunque sotto la licenza BSD. OpenSSH criptatutto il traffico (password compresa) per eliminare a tutti gli effetti l’ascolto pas-sivo, l’hijacking della connessione e altri attacchi a livello di rete. Fornisce inoltreuna miriade di possibilità di tunneling sicuro, così come vari metodi di autenti-cazione.Ecco alcune caratteristiche:

� Progetto Open Source;

� Licenza Gratuita;

� Crittografia forte (3DES, Blowfish);

� X11 Forwarding (cifratura automatica del traffico X11);

� Port Forwarding (canali criptati per altri protocolli);

� Autenticazione Forte (Rhosts, Chiave Pubblica, Password);

� Interoperabilità(Conformità con SSH 1.3, 1.5, e gli Standard del protocollo2.0);

� Supporto per client e server SFTP nei protocolli SSH1 e SSH2;

� Kerberos e AFS Ticket Passing;

� Compressione Dati.

Progetto Open Source Il codice di OpenSSH è disponibile gratuitamente perchiunque via Internet. Questo incoraggia il riutilizzo e la verifica del codice.

Licenza Gratuita OpenSSH non è coperto da nessuna licenza restrittiva. Puòessere usato per qualsiasi scopo, incluso quello commerciale. Tutte le componentisoggette a brevetto, sono state rimosse dal codice sorgente. Tutte le componentisoggette a restrizioni sulla licenza o brevetto, sono state scelte da librerie esterne(ad esempio OpenSSL).


OpenSSH 27

Crittografia forte (3DES, Blowfish) OpenSSH usa 3DES e Blowfish come al-goritmi di cifratura. Nessuno di essi è soggetto a brevetto. 3DES è un cifrarioben conosciuto e a prova di tempo che fornisce crittografia forte. Blowfish è uncifrario a blocchi veloce, inventato da Bruce Schneier, che risponde bene all’esi-genza di cifratura veloce. La cifratura inizia prima dell’autenticazione e non sonotrasmesse password o altre informazioni in chiaro.

X11 Forwarding L’X11 10 forwarding consente la cifratura del traffico remoto diX11, cosicché nessuno possa curiosare in xterm remoti di altri o inserire comandimaliziosi. Il programma setta automaticamente la variabile di ambiente DISPLAYsulla macchina server e inoltra ogni connessione X11 su di un canale sicuro.

Port Forwarding Il port forwarding consente l’inoltro di connessioni TCP/IP aduna macchina remota verso un canale cifrato. Servizi standard di Internet, comei server POP, possono essere resi sicuri con esso.

Autenticazione Forte L’autenticazione forte protegge contro alcuni problemi disicurezza, come IP spoofing, rotte false e DNS spoofing. I metodi di autenticazio-ne sono: rhosts con autenticazione host basata su RSA, autenticazione RSA purae autenticazione con password.

Interoperabilità Le versioni di OpenSSH anteriori alla 2.0 supportano i pro-tocolli SSH 1.3 e SSH 1.5, permettendo la comunicazione con molte versioni diUNIX, Windows ed altre implementazioni commerciali di SSH.OpenSSH supporta anche il protocollo SSH 2.0, che consente di scegliere tra RSAe DSA come algoritmi di firma.OpenSSH include un supporto completo per SFTP, usando il comando sftp(1) co-me client. Il deamon sftp-server(8) funziona automaticamente sia in SSH1 chein SSH2.La suite di OpenSSH include il programma ssh che sostituisce l’rlogin e il tel-net, scp che sostituisce l’rcp, e l’sftp che sostituisce l’ftp. Inoltre è incluso sshdche è il lato server del pacchetto e altre utility di base come ssh-add, ssh-agent,ssh-keysign, ssh-keyscan, ssh-keygen and sftp-server.

10X Window System, noto anche come X11 o ancor più semplicemente X, è il sistema graficostandard per tutti i sistemi Unix


Una sessione sicura 28

4 Una sessione sicura

Il protocollo SSH permette di creare dei tunnel che permettono ad altri program-mi di raggiungere una destinazione specifica attraverso appunto questi tunnel.Il transito dei pacchetti in tal modo è criptato anche se i programmi ed i proto-colli usati non hanno la capacità di farlo autonomamente. Il tuneling SSH vie-ne messo in pratica da un meccanismo chiamato “port forwarding”. Configuria-mo il nostro client SSH in modo che accetti connessione su certe porte sulla mac-china locale. Tutti i dati mandati a questa porte sono inviati e tornano attraver-so il tunnel. Dall’altra parte dei tunnel, il server SSH passa i dati e li riceve al-la macchina che avete indicato. Questo meccanismo è conosciuto come “port for-warding”.Con SSH potete rendere sicuri protocolli TCP/IP altrimenti insicuri mediante ilport forwarding. Con questa tecnica, il server SSH diventa un passaggio cifratoal client SSH.Il port forwarding consiste nel mappare una porta locale sul client verso una por-ta remota sul server. SSH vi permette di mappare qualsiasi porta dal server versoqualsiasi porta sul client. I numeri delle porte non devono essere uguali perfunzionare. Il port forwarding può risultare particolarmente utile per ricevere in-formazioni in modo sicuro tramite i firewall di rete. Se firewall è configurato perconsentire il traffico SSH tramite la porta standard, ma blocca l’accesso tramite lealtre porte, una connessione tra due host che usano porte bloccate è comunquepossibile se si reindirizza la comunicazione tramite una connessione SSH.


Conclusioni 29

Conclusioni

In definitiva lo scopo primario del protocollo SSH è migliorare la sicurezza suInternet. Tutti gli algoritmi di cifratura, integrità e a chiave pubblica sono benconosciuti e ben stabiliti.Inoltre vengono tutti negoziati. Nel caso in cui uno diessi venga rotto è facile passare ad un altro senza modificare il protocollo dibase. Vengono infine utilizzate chiavi sufficientemente lunghe da stabilire unaforte protezione contro gli attacchi crittoanalitici per decadi.


RIFERIMENTI BIBLIOGRAFICI 30

Riferimenti bibliografici

[1] SSH -http://www.dia.unisa.it/ãds/corso-security/www/CORSO-0001/SSH/protocollo.htmhttp://it.wikipedia.org/wiki/Crittografia_asimmetrica

[2] RSA -http://www.amagri.it/Crittologia/Crittografia/Algoritmi_crittografici/RSA/algoritmo_rsa.htm

http://sicurezza.html.it/guide/lezione.asp?IdGuida=6&idlezione=93

[3] DSA - http://www.firmasicura.it/faq_a.asphttp://www.icosaedro.it/crittografia/chiavi-asimmetriche.html

[4] Algoritmi a chiave simmetrica - http://a2.pluto.it/a2320.htmhttp://telemat.die.unifi.it/book/1999/crittografia/capitolo11.html

[5] Funzioni Hash -http://www.techtown.it/public/html/InfoLinux/MyLinuxsu209.html

[6] OpenSSH - http://www.dia.unisa.it/ãds/corso-security/www/CORSO-0001/SSH/introduzione.htm

[7] Tunneling SSH - http://www.freshnet.org/docs/pdf/ssh_tunneling.pdf

[8] Protocollo SSH -http://www.dia.unisa.it/ ads/corso-security/www/CORSO-0001/SSH/protocollo.htm

[9] Secure Shell - http://it.wikipedia.org/wiki/Secure_shell

[10] Algoritmo Diffie-Hellman-http://www.liceofoscarini.it/studenti/crittografia/critto/rsa/dh.html

[11] Storia della Crittografia -http://it.wikipedia.org/wiki/Crittografia#Approcci_storici_alla_crittografia

[12] Sicurezza Informatica - http://it.wikipedia.org/wiki/Sicurezza_Informatica


Protocollo SSH - Capponcino · Tesina di Elementi di Crittograﬁa Prof.ssa Maria Gabriella...

Documents

Transcript of Protocollo SSH - Capponcino · Tesina di Elementi di Crittograﬁa Prof.ssa Maria Gabriella...