dispensa

Sicurezza Informatica Introduzione

Luca Grilli

Che cosa significa “sicuro”?

• La parola “sicurezza” e l’aggettivo “sicuro” vengono sempre associati a beni che si desidera proteggere da possibili danni, danneggiamenti, perdita, etc. – un bene è al sicuro se è ben protetto

– la messa in sicurezza non deve impedirne il suo “utilizzo”

• La sicurezza di un sistema può definirsi come il grado di protezione contro una qualunque minaccia – [Wiki-en] “Security is the degree of protection against

danger, damage, loss, and criminal activity”

– [ISECOM] “Security is a form of protection where a separation is created between the assets and the threat”

Sicurezza e conoscenza

– La parola “sicurezza” deriva dal latino “sine cura”: senza preoccupazione

• [Wiki-it] La sicurezza di un sistema può essere definita come la conoscenza che l’evoluzione del sistema NON produrrà stati indesiderati

• Le cause che possono minare la sicurezza sono molteplici e spesso non prevedibili non si può parlare di sicurezza in senso assoluto!

non si può garantire con certezza la sicurezza totale di un bene; esiste sempre una percentuale di rischio

Trasversalità della sicurezza

• Problematiche di sicurezza interessano molteplici campi: – attività lavorative, vita domestica, hobby, giochi, sport, etc.

• ogni settore della vita moderna ha delle implicazioni relative alla sicurezza: – l'informatica, le comunicazioni, i trasporti, la finanza, etc.

• Il livello di sicurezza di un’organizzazione dipende dai livelli di sicurezza di tutti i suoi comparti/settori – NON può essere superiore al livello di sicurezza del suo

comparto più debole (insicuro)

SICUREZZA IN INFORMATICA Sicurezza Informatica – Introduzione

Sicurezza di un sistema informativo

• Per sistema informativo (information system) di un’organizzazione si intende l’insieme – delle informazioni prodotte ed elaborate, e – delle risorse, sia umane che tecnologiche, coinvolte nel

processo di elaborazione

• Non va confuso con il sistema informatico (Information and Communication Technology system) – insieme delle tecnologie coinvolte nel sistema informativo

• In altri termini, il sistema informatico è l’insieme degli

apparati hardware e software per la gestione e per l’elaborazione dell’informazione

Sicurezza di un sistema informativo

• Questo corso verterà sulla sicurezza dei sistemi informativi

– si approfondiranno maggiormente questioni inerenti la sicurezza dei sistemi informatici

• Per sicurezza di un sistema informativo si intende il grado di protezione contro una qualsiasi minaccia.

Principi della sicurezza informatica

– La gestione della sicurezza di un sistema informativo deve tener presente i seguenti principi

• (P1) Principio della penetrazione più semplice

• (P2) Principio della temporalità

• (P3) Principio di efficacia

• (P4) Principio dell’anello più debole

Penetrazione più semplice (P1)

• Un avversario utilizzerà qualsiasi mezzo di penetrazione disponibile – non necessariamente i mezzi più ovvi (prevedibili)

– non necessariamente i mezzi per i quali sono state installate le difese più solide

• L’applicazione di P1 presenta le seguenti difficoltà: – saper anticipare l’avversario, cioè riuscire a prevederlo

– gestire in modo equilibrato la sicurezza delle diverse parti di un sistema • rafforzare le difese di una parte può indurre gli avversari ad

attaccare un’altra parte (più debole) del sistema

Principio di temporalità (P2)

• Gli elementi di un sistema informativo – devono essere protetti solo fino a quando

possiedono un valore, e

– devono essere protetti in modo proporzionale al loro valore

• Generalmente P2 si riferisce ai dati – il loro valore più subire brusche variazioni

temporali • es.: dati sull’andamento dei mercati prima di essere resi

pubblici

Principio di efficacia (P3)

• Ogni misura di protezione per essere efficace deve essere

– utilizzata in modo appropriato,

– efficiente,

– adeguata, e

– facile da applicare

Principio dell’anello più debole (P4)

• La sicurezza di un sistema NON può essere più forte del suo anello più debole

• la gestione della sicurezza deve tener conto del sistema nel suo insieme – laddove c’è una scomposizione in parti (sottosistemi)

di un sistema complesso • un elevato grado di sicurezza delle singole parti non implica

un elevato grado di sicurezza globale, ma

• è necessario prevedere anche una strategia di coordinamento della varie parti priva di debolezze

Risorse da proteggere

• Un sistema informatico presenta tre componenti preziose ma separate: hardware, software e dati – nel definire un piano di sicurezza, si esaminano le

cause/situazioni per la quali tali componenti possono subire un danno o una perdita

– ad esempio, è possibile identificare i dati il cui contenuto deve essere protetto in qualche modo. Il sistema di protezione deve assicurare che • nessun dato sia accessibile a parti non autorizzate, o

modificabile in modo illegittimo, e

• gli utenti legittimi abbiano acceso ai dati

– l’esame di questi aspetti può evidenziare le debolezze nel sistema

Vulnerabilità

• Una vulnerabilità (o falla o breccia) è una debolezza intrinseca di un sistema, che potrebbe essere sfruttata per provocare perdite o danni – scaturisce spesso da errate procedure di sicurezza e/o

da errori di progettazione/implementazione

– in alcuni casi è intimamente legata alla natura del sistema • un calcolatore è vulnerabile all’acqua

– ad esempio • un sistema potrebbe essere vulnerabile alla manipolazione

non autorizzata dei dati causa un bug nella procedura di autenticazione dell’utente

Minacce

• Una minaccia a un sistema informatico è un insieme di circostanze potenzialmente in grado di causare perdite e danni

– cioè un evento potenziale, accidentale o deliberato, che, nel caso accadesse, produrrebbe perdite e danni

– il realizzarsi di una minaccia generalmente avviene sfruttando una o più vulnerabilità del sistema

Differenza tra minaccia e vulnerabilità

• L’acqua a sinistra del muro è una minaccia per l’uomo alla destra – potrebbe salire di livello e

sommergerlo oppure far crollare il muro

• La crepa nel muro è una vulnerabilità che minaccia la sicurezza dell’uomo – se l’acqua sale fino al livello della

crepa, sfrutterà la vulnerabilità e procurerà un danno all’uomo

Attacco

• Chi sfrutta deliberatamente una vulnerabilità perpetra un attacco al sistema

– un attacco può essere lanciato anche da un altro sistema

• si considerino ad esempio gli attacchi di tipo negazione del servizio (denial of service) ove un sistema invia un insieme interminabile di messaggi a un altro, sovraccaricando quest’ultimo e impedendolo di funzionare

Controllo

• Un controllo è una misura di protezione tesa a rimuovere o ridurre una vulnerabilità

– può trattarsi di un’azione, un dispositivo, una procedura o una tecnica

• facendo riferimento alla figura precedente,

• l’uomo chiude la crepa con il proprio dito, in questo modo controlla la minaccia della fuoriuscita di acqua, in attesa di individuare una soluzione permanente

Minacce, vulnerabilità e controlli

• La relazione tra minacce, vulnerabilità e controlli può sintetizzarsi come segue

“Una minaccia viene bloccata

dal controllo di una vulnerabilità”

– chi si occupa di sicurezza informatica deve

conoscere i vari tipi di controlli e come questi possono migliorare la protezione di un sistema • per tale motivo è fondamentale conoscere e classificare

le varie minacce

Tipologie di minacce

• Esistono quattro tipi principali di minacce:

– intercettazione,

– interruzione,

– modifica, e

– falsificazione

intercettazione interruzione

modifica falsificazione

Interruzione

• In un’interruzione, una risorsa del sistema va persa, diventa non disponibile o diventa inutilizzabile

– un esempio è

• la distruzione maliziosa di un dispositivo hardware,

• la cancellazione di un file di programma o di dato, o

• il malfunzionamento del file manager di un sistema operativo che non consente di accedere ai vari file

Modifica

• Si ha una modifica quando un’entità non autorizzata, oltre ad accedere a una risorsa, interferisce con essa modificandola

– per esempio, qualcuno o qualcosa potrebbe

• cambiare i valori di un database o modificare un programma in modo che esegua dei calcoli diversi,

• modificare i dati trasmessi elettronicamente, oppure

• modificare l’hardware

– alcuni casi di modifica possono essere facilmente rilevati, mentre altre modifiche, più sottili, possono essere estremamente difficili da individuare

Falsificazione

• La falsificazione consiste nella creazione di oggetti (dati/informazioni) contraffatti da parte (chiaramente) di un’entità non autorizzata – un intruso potrebbe inserire transazioni illegittime in

un sistema di comunicazione di rete, o

– aggiungere record a un database esistente

• A volte le falsificazioni sono facilmente rilevabili, ma se attuate con abilità potrebbero essere del tutto indistinguibili da normali operazioni reali legittime

Mezzi, Occasione e Movente (MOM)

• Per perpetrare un attacco un aggressore deve disporre di tre elementi

– mezzi: le capacità, le conoscenze, gli strumenti e altre cose necessarie a sferrare l’attacco

– occasione: il tempo e l’accesso per compiere l’attacco

– movente: un motivo per eseguire l’attacco

• In assenza di uno di questi tre elementi l’attacco non potrà avvenire

– tuttavia nessuno di essi è facile da negare all’aggressore

Sui mezzi di un aggressore

• La conoscenza dei sistemi è molto diffusa

– i sistemi operativi general-purpose sono ampiamente disponibili, così come le applicazioni e i DBMS più comuni

– spesso i produttori rilasciano guide dettagliate sulla progettazione dei sistemi e sul loro funzionamento

• come le guide per gli utenti e/o per gli integratori che vogliono implementare sistemi software complementari

– anche senza la documentazione gli aggressori possono acquistare e sperimentare molti sistemi

• l’unico limite è il tempo

Sull’occasione di un aggressore

• Molti sistemi sono ampiamente disponibili

– i sistemi a disposizione del pubblico sono, per definizione, accessibili

• si considerino tutte le applicazioni di rete pubbliche

– nel caso dell’hardware la disponibilità dei pezzi di ricambio è ritenuto un requisito indispensabile

• in caso di guasto ad un componente il proprietario deve poter ottenere in tempo brevi un ricambio

Sul movente di un aggressore

• È difficile determinare il movente per un attacco – alcuni sistemi rappresentano dei “bersagli attraenti”,

tra gli obiettivi più comuni vi sono i computer di organizzazioni militari, • forse proprio perché dovrebbero trattarsi di sistemi molto

ben protetti risultano più “appetibili” agli aggressori che vogliono vantarsi della propria bravura

– altri sistemi vengono attaccati perché sono bersagli facili (università, enti statali, etc.)

– altri sistemi vengono attaccati semplicemente perché esistono: si tratta di vittime casuali, modeste

– in fine, alcuni attacchi vengono perpetrati per appropriarsi illegittimamente di beni

SIGNIFICATO DI SICUREZZA INFORMATICA

Sicurezza Informatica – Introduzione

Significato di sicurezza informatica

• Abbiamo visto che qualsiasi sistema informatico presenta delle debolezze sia teoriche sia reali

• La scopo della sicurezza informatica è escogitare modi per impedire che le debolezze vengano sfruttate

• Per scegliere adeguatamente il tipo di misura preventiva è necessario chiarire cosa significa che un sistema informatico (o in generale informativo) è sicuro

Sicurezza informatica

• Per sicurezza informatica si intende la protezione di tre aspetti di un sistema informativo:

– confidenzialità

– integrità

– disponibilità

INTEGRITÀ

CONFIDENZIALITÀ

DISPONIBILITÀ

SICURO

Confidenzialità (Confidentiality)

• La confidenzialità (confidentiality) assicura che alle risorse informatiche accedano solo le parti autorizzate – l’accesso è consentito solo a chi ha i diritti

– per accesso non si intende solo la lettura, ma anche la visualizzazione, la stampa o la semplice consapevolezza dell’esistenza di una data risorsa

– è a volte definita segretezza, riservatezza o privacy

• Def. Confidentiality: the property that information is not made available or disclosed to unauthorized individuals, entities, or processes [ISO/IEC 13335-1:2004]


• Si ha un attacco alla confidenzialità quando una entità (persona, processo o risorsa) accede in maniera non autorizzata a informazioni protette

– mentre queste sono memorizzate, oppure durante l’elaborazione, oppure ancora durante una comunicazione

• La confidenzialità è un concetto chiaro, immediato e di facile comprensione

– solo le persone o i sistemi autorizzati possono accedere ai dati protetti


• Assicurare la confidenzialità può essere difficile – chi assicura quali sistemi e/o persone sono autorizzati

all’accesso di una risorsa?

– i dati possono essere complessi e può essere difficile stabilire una politica di accesso • si pensi ad un database in cui dati sensibili possono risiedere

in alcune relazioni o peggio in alcuni record

– le persone autorizzate possono divulgare i dati?

• La confidenzialità può ottenersi mediante un rigoroso controllo di chi o cosa può accedere a quali risorse e in quale modo

Integrità (Integrity)

• Per integrità (integrity) si intende che le risorse possono essere modificate solo dalle parti autorizzate e solo nei modi autorizzati – le modifiche comprendono la scrittura, la variazione, il

cambiamento dello stato, l’eliminazione e la creazione

• Def. Integrity: safeguarding the accuracy and completeness of information and processing methods [BS ISO/IEC 17799:2000]

• Def. Integrity: the property of safeguarding the accuracy and completeness of assets [ISO/IEC 13335-1:2004]


• Si ha un attacco all’integrità quando una entità (persona, processo o risorsa), in maniera non autorizzata, – accede al sistema e ne altera le risorse, oppure

inserisce oggetti nel sistema, oppure

– essendo un utente autorizzato del sistema ne esegue una modifica non autorizzata

• L’integrità è molto più difficile da inquadrare – il concetto di modifica o alterazione non

autorizzata dei dati può avere sfumature diverse in contesti differenti


– due aspetti chiave dell’integrità sono l’integrità:

• del contenuto dei dati (data o content integrity) – i dati vanno protetti da alterazioni non autorizzate che

possono avvenire durante la memorizzazione, elaborazione o trasmissione

• della sorgente dati, (source authentication o origin integrity) – un sistema deve eseguire le funzioni per le quali è

preposto, esente da alterazioni non autorizzate

• L’integrità può ottenersi in modo del tutto simile alla

confidenzialità – stabilendo una politica di accesso alle risorse, e – attuando dei controlli di accesso rigorosi

Disponibilità (Availability)

• Per disponibilità (availability) si intende che le risorse siano accessibili (nei tempi e nei modi prestabiliti) alle parti autorizzate ogni volta che le richiedono – se una persona o un sistema dispone dei diritti di accesso

ad una risorsa, l’accesso non deve essergli impedito

– spesso la disponibilità viene citata tramite il suo opposto: la negazione di servizio

• Def. Availability: ensuring that authorized users have access to information and associated assets when required [BS ISO/IEC 17799:2000]


• La disponibilità si riferisce sia ai dati che ai servizi erogati e può essere difficile da inquadrare – si possono attribuire significati/sfumature diverse al

concetto di disponibilità

– in generale un dato/servizio/sistema è disponibile se • si ottiene una risposta tempestiva ad una richiesta,

• le risorse sono allocate equamente; non vi sono richiedenti favoriti rispetto ad altri,

• è prevista una ragionevole tolleranza degli errori; ad un errore hardware/software non corrisponde una cessazione brusca del servizio o tantomeno un crash,

• il servizio/sistema è di facile utilizzo (usabilità)

• la concorrenza è controllata; cioè l’accesso simultaneo, la gestione dei blocchi critici e l’accesso esclusivo sono supportati


• Vista la sua “ampiezza” il requisito di disponibilità è il più difficile da garantire – l’avvento delle reti ha di fatto introdotto tale requisito,

storicamente i meccanismi di protezione sono stati applicati per garantire confidenzialità e integrità

– un controllo centralizzato degli accessi può garantire confidenzialità e integrità, ma

– un singolo punto di controllo in genere non garantisce la disponibilità • per la disponibilità spesso è necessario applicare delle

politiche di sicurezza distribuite sui vari sistemi coinvolti in un servizio

Confidenzialità, integrità e disponibilità

• Confidenzialità, integrità e disponibilità possono riguardarsi come i tre obiettivi della sicurezza informatica – spesso tali obiettivi sono in conflitto tra loro ed è

necessario trovare il “mix ottimale” • per esempio, è facile garantire la confidenzialità di un

oggetto impedendo a chiunque di leggerlo, ma

• tale soluzione non può considerarsi sicura in quanto può limitare severamente la disponibilità

– in un sistema sicuro esiste un equilibrio tra confidenzialità e disponibilità

SICUREZZA DI UN SISTEMA INFORMATIVO

Sicurezza Informatica – Introduzione

Realizzare un sistema sicuro

• La realizzazione (progettazione, implementazione e test) di un sistema sicuro in genere prevede due fasi distinte

– prima si cerca di immaginare quali possono essere le possibili minacce/vulnerabilità,

– poi si stabiliscono i meccanismi di sicurezza che garantiscono i tre requisiti di protezione

• Per aumentare il livello di sicurezza è necessario instaurare un ciclo virtuoso di queste due fasi

Analisi delle minacce/vulnerabilità

• L’attuazione della prima fase è più agevole – se si suddividono le minacce/vulnerabilità in base alle

categorie di risorse di sistema (hardware, software e dati),

– anziché iniziare con i singoli obiettivi di protezione

• Indipendentemente dal tipo di risorsa spesso è utile distinguere tra – minacce/vulnerabilità accidentali

– minacce/vulnerabilità intenzionali (o deliberate) • nelle prossime slide si analizzeranno sommariamente le

minacce/vulnerabilità tipiche di ogni risorsa, e in generale

• gli aspetti da considerare nel pianificare la sicurezza

Sicurezza dell’hardware

• L’hardware, avendo una sua struttura fisica è facilmente danneggiabile da qualunque persona – non sono richieste competenze

specifiche per distruggere un calcolatore

• Esempi di vulnerabilità sono il furto, l’incendio, la rottura, l’umidità, la polvere, l’aggiunta e/o sostituzione di apparati

• Tuttavia, non è difficile proteggere l’hardware – basta custodirlo in luoghi e

condizioni sicure, – installando sistemi di protezione

fisica per difendere le macchine

HARDWARE

interruzione (negazione del servizio)

intercettazione (furto)

modifica falsificazione (sostituzione)

Vulnerabilità del software

• Le vulnerabilità del software vanno ricercate nei bug inevitabilmente introdotti dal programmatore

• Principalmente tali bug riguardano problemi di

– buffer overflow

– mediazione incompleta

– gestione errata dei controlli

SOFTWARE

interruzione (eliminazione)

intercettazione

modifica falsificazione

Sicurezza del software

• Nella gestione della sicurezza del software vanno considerati i seguenti aspetti – non sempre è facile rilevare che un software è stato

maliziosamente alterato • apparentemente potrebbe sembrare funzionare correttamente,

ma in realtà … • la modifica potrebbe riguardare poche linee di codice o pochi bit

– il software è facilmente eliminabile e modificabile (non è ingombrante) • quante volte capita di eliminare/modificare un file

accidentalmente

– il software può essere contaminato da virus e può contaminare a sua volta altro software e/o arrecare danni ai dati

– il software proprietario può essere copiato e distribuito senza licenza

Modifiche malevole del software

• esistono vari tipi di modifiche malevole ecco le più note

– bombe logiche: programmi che funzionano correttamente fino al verificarsi di una certa data/condizione

– cavalli di Troia: programmi che apertamente svolgono un’operazione, ma in segreto ne svolgono un’altra

– virus: tipi specifici di cavalli di troia che hanno la capacità di diffondere l’infezione

– worm: tipi particolari di virus che si diffondono tramite Internet (rete)

– trapdoor: programmi con punto di accesso segreto

Protezione del software

• La protezione del software si basa principalmente sull’attuazione misure preventive e controlli a posteriori – miglioramento del processo di produzione del

software; riduzione di bug/difetti

– controllo (monitoraggio) dei programmi installati • verificare che non vi siano modifiche non autorizzate

– controllo dei dati/programmi trasferiti dalla rete • in particolare controllo dei programmi eseguibili

– aggiornamento e installazione delle patch di tutti i programmi installati • in particolare del software antivirus e del sistema operativo

Vulnerabilità dei dati

• I dati sono entità astratte

– ha poco senso parlare di vulnerabilità

• In altri termini, i dati sono vulnerabili se lo sono

– gli apparati hardware/software, e

– il (in generale) sistema informativo

in cui sono mantenuti ed elaborati

DATI

interruzione (perdita)

intercettazione

falsificazione modifica

Sicurezza dei dati

• Nella gestione della sicurezza vanno considerati i seguenti aspetti, i dati

– spesso rappresentano il bene più prezioso di un’organizzazione

• ricavarli/produrli potrebbe essere stato molto costoso

• segreti industriali, segreti militari

– hanno un valore pubblico superiore rispetto all’hardware e al software

• i programmi (codice sorgente) possono essere interpretati solo da esperti

Sicurezza dei dati

– frammenti isolati di dati possono non avere alcun valore se non inseriti in un contesto

– possono essere riferiti a persone (dati sensibili) e non possono essere divulgati

– il loro valore (che può essere ingente) è difficile da stimare/prevedere e può variare notevolmente nel tempo

• dati sull’andamento dell’economia da rendere pubblici

• vedi considerazioni fatte sul principio della temporalità

Sicurezza dei dati

• I tre obiettivi della sicurezza si applicano perfettamente ai dati

– è difficile parlare di confidenzialità dell’hardware!

– confidenzialità: impedire la divulgazione non autorizzata di un dato

– integrità: impedire le modifiche non autorizzate

– disponibilità: impedire la negazione degli accessi autorizzati

Confidenzialità dei dati

• I dati possono essere ottenuti in vari modi

– intercettandoli quando vengono trasmessi • sfruttando i cavi,

monitorando le radiazioni elettromagnetiche, inserendo delle cimici, etc.

– accedendo o rubando i supporti in cui sono mantenuti

DATI

CONFIDENZIALITÀ

Integrità dei dati

• La modifica o la falsificazione dei dati richiedono un elevato grado di conoscenza della tecnologia con cui sono trasmessi e/o memorizzati i dati

• Piccole e sapienti modifiche potrebbero essere difficile da individuare – salami attack

• La falsificazione è un processo più complicato

DATI

INTEGRITÀ

Disponibilità dei dati

• La disponibilità dei dati è strettamente legata alla disponibilità delle tecnologie hardware e software

DATI

DISPONIBILITÀ

Altre risorse da proteggere

• Le reti sono insiemi specializzati di hardware, software e dati che meritano una attenzione particolare – interagiscono con risorse esterne la cui sicurezza non può

essere controllata,

– un’errata politica di gestione della sicurezza di rete espone un sistema informatico ad attacchi dall’esterno

– un accesso non autorizzato può comportare • il furto del tempo macchina

• la distruzione/alterazione di software o dati

• la negazione di servizio agli utenti legittimi

• Le persone chiave – i dipendenti potrebbero sabotare il sistema informatico,

– è necessario scegliere persone di cui potersi fidare

CRIMINALI INFORMATICI Sicurezza Informatica – Introduzione

Criminali informatici

• Un crimine informatico è un qualsiasi crimine che coinvolge un computer o che è favorito dall’impiego di un computer

• Non esiste lo stereotipo del criminale informatico – non esiste il “tipico” criminale informatico

• Una stima delle perdite economiche derivanti da crimini informatici è difficile – esistono pochi dati e spesso i crimini informatici non

vengono separati dagli altri crimini – chi subisce un crimine preferisce spesso non denunciarlo

per salvare la propria reputazione; spesso si preferisce venire a patti con i criminali

– negli USA le stime variano dai 300 ai 500 milioni di dollari l’anno

Criminali informatici

• La strategia di difesa contro i crimini informatici consiste nel – cercare di prevenirli, o almeno di

– attenuarne gli effetti

• In ogni caso, è importante comprendere chi commette questi crimini e perché – cioè conoscere le varie tipologie di criminali

• Una prima classificazione dei criminali è la seguente: – dilettanti

– cracker (o hacker malevoli)

– criminali professionisti

– terroristi

Dilettanti

• Moltissimi crimini informatici sono commessi da dilettanti

• I dilettanti sono persone normali prive di particolari competenze informatiche, ma che in talune situazioni possono commettere dei crimini – causalmente rilevano una debolezza e la sfruttano per i

propri interessi – non venendo controllate al lavoro perché ritenute oneste,

decidono di sabotare il sistema informativo per motivi personali (vendetta)

• Un crimine è anche l’uso del computer al lavoro per i propri fini – un dipendente usa il computer e la rete per i propri scopi e

non per le mansioni lavorative

Cracker (o hacker malevoli)

• La comunità della sicurezza distingue tra

– hacker: una persona dotata di grandi capacità tecniche, che padroneggia la programmazione e conosce profondamente le tecnologie IT

– cracker: un malfattore che tenta di violare i sistemi informatici

• Attualmente, all’esterno della comunità della sicurezza il termine hacker indica

– sia gli utenti in buona fede,

– sia gli utenti maliziosi

Cracker (o hacker malevoli)

• I cracker dei sistemi, spesso sono studenti, tentano di accedere alle infrastrutture informatiche senza esserne autorizzati

– le ragioni che li muovono sono svariate

• curiosità, guadagno, senso della sfida, etc.

– generalmente rubano solo un po’ di tempo-macchina o oltre risorse (banda, memoria)

– in alcuni casi possono arrecare perdite o danni

Criminali professionisti

• I criminali informatici professionisti sono persone che compiono dei crimini informatici per profitto – sono pienamente consapevoli di quello che fanno e

del motivo per cui lo fanno • cioè ricavare un profitto nel tempo

– a differenza dei cracker non sono spinti da curiosità e non lo fanno per vantarsi puntano invece ad ottenere stabilmente delle risorse; questa diversità di obiettivi comporta approcci differenti: • il cracker compie dei blitz,

• l’aggressore professionista attua un metodo di attacco pulito, robusto e difficile da rilevare

Criminali professionisti

• Alcune aziende sono reticenti a perseguire i criminali informatici

– dopo la scoperta di un crimine si accontentano di essere lasciate in pace

– spesso si limitano a chiudere un sistema attaccato e non raccolgono le prove per l’identificazione del criminale

spesso il criminale è libero di proseguire le sue attività illegali con un’altra azienda

Terroristi

• I terroristi usano i computer nei seguenti modi:

– come bersagli di un attacco

• gli attacchi DoS (Denial of Service o negazione di servizio) o di “defacciamento” di siti Web (web site defacements) danno popolarità alle organizzazioni terroristiche e umiliano il bersaglio dell’attacco

– come mezzi di propaganda

• siti Web e le varie tecnologie di rete sono un mezzo veloce e a basso costo per veicolare dei messaggi

– come strumenti di attacco

• per lanciare un’offensiva (ad esempio di tipo DoS) occorrono dei computer

METODI DI DIFESA Sicurezza Informatica – Introduzione

Metodi di difesa

• In un sistema informativo avviene un danno quando si realizza una minaccia attraverso una (o più) vulnerabilità

• Per proteggersi dai danni si può

– neutralizzare la minaccia e/o

– eliminare la/le vulnerabilità (prevenzione)

• Il rischio è la possibilità che si verifichi un danno

Metodi di difesa

• In particolare si può affrontare un danno cercando di: – prevenirlo, bloccando l’attacco o tappando la

vulnerabilità

– scoraggiarlo, rendendo più difficile, ma non impossibile un attacco

– deviarlo, rendendo più attraente un altro obiettivo (o meno attraente quello attuale)

– rilevarlo, quando si verifica o dopo poco tempo che si è verificato

– ripristinare il sistema dai suoi effetti

Metodi di difesa

• Un meccanismo di sicurezza è un qualsiasi metodo, strumento, o procedura per rilevare, prevenire o porre rimedio agli effetti di un attacco alla sicurezza

– la strategia di difesa, qualunque essa sia, combina in modo opportuno uno o più meccanismi di sicurezza

– molti meccanismi di sicurezza consistono in controlli hardware/software

Controlli

• La scelta del mix di controlli dipende da

– ciò che si sta proteggendo

– rapporto costo-protezione/rischio-perdita

– sforzo dei potenziali intrusi per eludere le protezioni

Meccanismi di sicurezza

• Un elenco dei principali meccanismi di sicurezza è il seguente

– crittografia

– controlli software

– controlli hardware

– controlli fisici

– politiche e procedure

Crittografia

• La cifratura (o crittazione) consente di offuscare i dati rendendoli non intellegibili ad un intruso

– si tratta del meccanismo di sicurezza più importante

– i dati nella forma originale, testo in chiaro, vengono rimescolati in modo da essere incomprensibili ad un osservatore esterno

– il risultato della cifratura viene detto testo cifrato

Crittografia

• La cifratura viene utilizzata

– per garantire la confidenzialità dei dati

– per assicurare l’integrità di dati e programmi

• generalmente, se i dati non possono essere letti non possono neanche essere modificati con facilità

• tecniche di cifratura sono impiegate per effettuare controlli di integrità di dati e programmi

– nell’ambito di molti protocolli di rete,

– nell’ambito di molte attività di sistema

Controlli software

• Controlli interni al programma: le parti di un programma che assicurano le restrizioni di protezione – come i limiti di accesso in un DBMS

• Controlli del sistema operativo e del sistema di rete: le limitazioni imposte dal sistema operativo o dalla rete per proteggere ogni utente da tutti gli altri

• Programmi di controllo indipendenti: i programmi applicativi come – gli strumenti di controllo delle password,

– le utilità di rilevamento delle intrusioni, o

– gli anti-virus, che proteggono da specifici tipi di vulnerabilità

Controlli software

• Controlli di sviluppo: gli standard di qualità con cui un programma viene progettato, implementato, testato e manutenuto per evitare che malfunzionamenti si traducano in vulnerabilità

• I controlli software influenzano (riducono) notevolmente l’usabilità di un sistema

– vanno pertanto progettati con cura

Controlli hardware

• Alcuni dei principali controlli hardware sono

– implementazioni della crittografia per hardware o smart card

– serrature o cavi che limitano l’accesso o fungono da deterrenti per il furto

– dispositivi per verificare l’identità dell’utente

– sistemi di rilevamento delle intrusioni

– schede circuitali che controllano l’accesso ai supporti di memorizzazione

Controlli fisici

• Alcuni dei principali controlli fisici sono

– le serrature alle porte

– le guardie agli ingressi

– le copie di backup di software e dati importanti

– una pianificazione del luogo fisico che riduca il rischio di disastri naturali

Politiche e procedure

• La sicurezza richiede anche l’adozione di procedure e politiche convenute tra gli utenti – ogni politica di sicurezza richiede una fase di

addestramento e di informazione del personale coinvolto

– si pensi ad esempio alle regole di comportamento per un utilizzo sicuro della rete • evitare di aprire i messaggi (allegati) di posta elettronica

sospetti

• non rispondere ai messaggi di posta elettronica che richiedono la comunicazione di informazioni riservate o personali

• …

Efficacia dei controlli

• Alcuni aspetti che possono migliorare l’efficacia dei controlli sono

– la consapevolezza del problema: le persone che utilizzano i controlli devono essere convinte della necessità del controllo

• chi ritiene superflue le misure di sicurezza non le applicherà o le applicherà in modo superficiale

• chi ha sempre eseguito un’operazione in modo poco sicuro è restio a cambiare

Efficacia dei controlli

– l’efficienza: i controlli per poter essere utilizzati devono essere efficienti in termini di tempo, spazio di memoria, attività umana o altre risorse utilizzate • l’applicazione del controllo non deve influenzare

(appesantire) l’attività da proteggere

– la selettività: i controlli devono filtrare gli intrusi, ma consentire gli accessi legittimi

– l’uso di controlli sovrapposti o a strati: uso di più controlli per una singola vulnerabilità • tenendo presente il principio dell’anello più debole

– revisioni periodiche: pochi controlli garantiscono la loro efficacia nel tempo • c’è uno sforzo continuo per migliorare le strategie di attacco

Bibliografia

• [PFL08] C. P. Pfleeger, S. L. Pfleeger. Sicurezza in Informatica. Pearson, Prentice Hall.

• [STA07] W. Stallings. Sicurezza delle reti. Pearson, Prentice Hall.

• [Wiki-it] http://it.wikipedia.org/wiki/

• [Wiki-en] http://en.wikipedia.org/wiki/

• [ISECOM] Institute for Security and Open Methodologies

Introduzione alla Crittografia

Luca Grilli

CHE COS’È LA CRITTOGRAFIA Introduzione alla Crittografia

Che cos’è la crittografia?

• La parola crittografia deriva dalle parole greche

– κρυπτός (kriptós): nascosto o segreto, e

– γραφία (graphía): scrivere

• Quindi, la crittografia è l’arte e la scienza dello scrivere in modo segreto

– l’arte di offuscare delle informazioni in modo apparentemente del tutto incomprensibile,

– prevedendo una tecnica segreta per ricostruirle in modo esatto

Applicazioni della crittografia

• Un’applicazione immediata (servizio base) è la – trasmissione di messaggi tra soggetti che desiderano

comunicare, – rendendo il contenuto incomprensibile ad un

ascoltatore non autorizzato

• Le moderne tecniche crittografiche – nella quali l’informazione viene rappresentata in

forma binaria (o numerica)

forniscono ulteriori servizi – Controllo di Integrità – Autenticazione

Applicazioni della crittografia

• Controllo di Integrità (Integrity Checking)

– assicura il destinatario (recipient) di un messaggio che il messaggio non è stato alterato dal momento in cui è stato generato da una fonte attendibile

• Autenticazione (Authentication)

– verifica dell’identità di qualcuno (o qualcosa)

Terminologia e definizioni preliminari

• Testo in chiaro (plaintext o cleartext): messaggio nella sua forma originale

• Testo cifrato (ciphertext): messaggio cifrato • Cifratura o crittazione o criptazione (encryption):

processo che produce il testo cifrato a partire dal testo in chiaro

• Decifratura o decrittazione o decriptazione (decryption): processo inverso della cifratura

ENCRYPTION DECRYPTION

PLAINTEXT PLAINTEXT CIPHERTEXT


• Crittografo (cryptographer): esperto di crittografia

• Crittoanalisi o crittanalisi (cryptanalysis): l’arte o la scienza di violare testi cifrati

– ricostruire il testo in chiaro senza conoscere l’informazione segreta utilizzata in fase di decifratura

• Crittoanalista o crittanalista (cryptanalyst): esperto di crittoanalisi


• [Wiki-it] Crittologia (cryptology): l’arte o la scienza delle scritture nascoste, nel suo duplice significato:

– da un lato comprende l'ideazione di metodi sempre più sicuri per occultare il reale significato di determinati segni (crittografia),

– dall'altro riguarda la decifrazione di testi occultati senza conoscerne a priori il metodo usato (crittanalisi).

Crittografi vs Crittoanalisti

• Crittografi e crittoanalisti sono in continua sfida

– i primi sviluppano codici segreti sempre più raffinati

– i secondi tentano costantemente di migliorare le tecniche di crittoanalisi

• Il vantaggio/successo dei crittografi si fonda sul seguente principio

– Principio fondamentale della crittografia: If lots of smart people have failed to solve a problem, then it probably won't be solved (soon)

Sistemi crittografici

• I sistemi crittografici generalmente prevedono l’utilizzo combinato di – un algoritmo, e

– un valore segreto detto chiave

• La chiave segreta è stata introdotta essenzialmente perché – è difficile concepire ogni volta nuovi algoritmi di cifratura,

– è difficile spiegare rapidamente il funzionamento di un nuovo algoritmo ad un soggetto con il quale si desidera comunicare in modo sicuro

Complessità computazionale

• Uno schema di crittografia

– non è impossibile da violare se non si conosce la chiave

• un avversario può seguire un approccio esaustivo (brute force) che esamina tutte le possibili chiavi finché non trova quella corretta

– è tanto più sicuro quanto maggiore è il costo computazionale necessario a violarlo

– deve permettere di cifrare e decifrare messaggi in modo efficiente quando si conosce la chiave

• le fasi di cifratura e decifratura devono richiedere un tempo ragionevolmente ridotto quando si conosce la chiave

Lunghezza della chiave

• Alcuni schemi di crittografia prevedono una chiave avente lunghezza variabile – aumentando la lunghezza della chiave si aumenta il

livello di sicurezza, ma

– diminuisce l’efficienza: aumenta il tempo di cifratura/decifratura del messaggio (per chi conosce la chiave)

• Altri schemi non consentono la modifica della lunghezza della chiave – in tal caso è necessario sviluppare algoritmi simili che

utilizzano chiavi di lunghezza diversa

Algoritmo pubblico o segreto?

• Qualcuno sostiene che mantenere segreto un algoritmo di crittografia aumenti la sua sicurezza – un crittoanalista deve prima individuare l’algoritmo e

poi tentare di forzarlo

• Altri sostengono invece che pubblicando l’algoritmo, rendendolo noto a tutti, la sicurezza aumenti – scoprire un algoritmo segreto potrebbe non essere

così difficile, e

– se l’algoritmo segreto ha delle debolezze queste potrebbero essere individuate da un crittoanalista


– se l’algoritmo invece è pubblico eventuali debolezze possono essere segnalate dalla comunità scientifica

– se molti esperti confermano la “bontà” dell’algoritmo è molto probabile che sia realmente sicuro

• È difficile mantenere segreto un algoritmo molto diffuso – tecniche di reverse engineering possono permettere

di risalire al codice,

– essendo molto diffuso può venirne in possesso un crittoanalista abile


• In passato, la segretezza era richiesta perché gli algoritmi sicuri erano estremamente costosi – gli algoritmi a basso costo erano insicuri!

– gli attuali algoritmi non richiedo questa “extra protezione” essendo di per se molto sicuri

• La tendenza attuale è che – gli algoritmi commerciali/civili sono pubblici,

mentre

– gli algoritmi militari sono tenuti segreti


• L’esigenza della segretezza può dipendere da altre cause (e non dall’aumento di sicurezza)

– l’autore dell’algoritmo potrebbe tenerlo segreto per ragioni commerciali (segreto industriale)

– nel caso militare, è possibile che si ricorra alla segretezza per evitare che il nemico usi uno schema di crittografia ritenuto sicuro

• costringendolo ad utilizzare tecniche note o a svilupparne di proprie

Codici segreti (cifrari)

• Con il termine codice segreto o cifrario si intende un qualunque metodo di cifratura – il più antico cifrario è attribuito a Giulio Cesare

• consiste nella sostituzione di ogni lettera di un messaggio con la lettera che la segue di 3 posizioni nell’alfabeto

• si considera l’ordinamento circolare dell’alfabeto (la A segue la Z)

• ad esempio: “INFORMATICA” diventa “LQIRUPDWLFD”

– un’ovvia variante del cifrario di Cesare consiste nel considerare un numero segreto n compreso tra 1 e 25, invece di usare sempre il 3


– Ovviamente, decifrare dei messaggi risulta molto semplice • se si è certi che è usato questo cifrario, e

• se si è in grado di riconoscere il testo decifrato

– basta fare pochi tentativi (al più 25) per individuare il numero segreto n ed ottenere il messaggio originale

– successivamente fu introdotto il cifrario monoalfabetico che consiste nell’applicare un mapping arbitrario di una lettera in un’altra • si basa sulla scelta di una biiezione segreta sull’insieme

delle lettere alfabetiche


– Teoricamente, per decifrare un messaggio sono necessari, nel caso peggiore, 26! ≈ 4 × 1026 tentativi

• Assumendo 1 μS per tentativo sono necessari 10 trilioni di anni (1013 anni)

– Tuttavia, applicando tecniche statistiche di analisi dei linguaggi (alcune lettere e combinazioni di lettere sono più probabili di altre) risulta abbastanza facile decifrare i messaggi cifrati


• Con l’avvento dei computer, l’introduzione di schemi di cifratura più sofisticati

– da un lato è stata resa necessaria

• un computer permette di automatizzare gli approcci brute force dei crittoanalisti

– dall’altro è stata resa possibile

• un computer può eseguire un algoritmo di cifratura complesso in tempi veloci e senza errori

VIOLARE UNO SCHEMA DI CRITTOGRAFIA


Tipologie di attacchi

• Si possono distinguere tre tipi di attacchi base per violare uno schema di crittografia – solo testo cifrato (ciphertext only)

– testo in chiaro conosciuto (known plaintext)

– testo in chiaro selezionato (chosen plaintext)

• Altri due tipi di attacco meno frequenti sono – testo cifrato selezionato (chosen ciphertext)

– testo selezionato (chosen text)

Solo testo cifrato (ciphertext only)

• Scenario

– Fred, il cattivo ragazzo, ha ottenuto il testo cifrato di un messaggio che Alice ha inviato a Bob nell’ambito di una comunicazione cifrata con una chiave segreta

• Fred può analizzare con comodo il testo cifrato

– in genere, non è difficile ottenere il testo cifrato

• se fosse impossibile non si avrebbe la necessità di cifrare i messaggi!

• Domanda

– come può Fred risalire al testo in chiaro se dispone soltanto del testo cifrato?


• Risposta 1 – Fred può seguire un approccio di tipo brute force:

• considera tutte le chiavi,

• per ogni chiave decripta il testo cifrato, e

• verifica se il testo decifrato è un messaggio verosimile

– tale approccio può funzionare solo se Fred è in grado di riconoscere il testo in chiaro originale, • cioè una volta decriptato il testo cifrato deve poter dire, con

elevata probabilità, se quanto ottenuto è il messaggio di Alice

• tale attacco è anche noto come testo in chiaro riconoscibile (recognizable plaintext)


• Riguardo la riconoscibilità del testo in chiaro valgono le seguenti osservazioni

– è molto improbabile che una chiave di decifratura errata permetta di ottenere un messaggio verosimile

– è essenziale avere abbastanza testo cifrato

• si consideri ad esempio il cifrario monoalfabetico, se l’unico testo cifrato di cui si dispone è “XYZ” non c’è abbastanza informazione,

• il testo in chiaro corrispondente potrebbe essere “THE”, “CAT”, “HAT”, etc.


• Risposta 2

– in alcuni casi, si potrebbe tentare un approccio a forza bruta computazionalmente meno costoso

• se la chiave viene generata con tecniche note a partire da un input segreto, conviene applicare un approccio esaustivo su tale input

• non di rado la chiave di cifratura viene generata a partire dalla password d’utente applicando un algoritmo noto; così avviene nello schema di autenticazione Kerberos che usa una cifratura DES


• se la password viene scelta in modo avventato (una parola del dizionario) anziché scandire uno spazio di 256 chiavi è sufficiente scandire uno spazio di circa 10000 parole

• Un algoritmo di crittografia deve SEMPRE essere sicuro contro attacchi di tipo ciphertext only

– il testo cifrato è sempre facilmente intercettabile e ottenibile

• in molti casi i crittoanalisti possono disporre di informazioni aggiuntive e sferrare degli attacchi più forti, come illustrato nelle prossime slide

Testo in chiaro conosciuto (known plaintext)

• Scenario – Fred ha in qualche modo ottenuto alcune coppie plaintext, ciphertext relative ad una o più comunicazioni cifrata tra Alice e Bob (con stesso schema e chiave) • dati segreti non rimangono segreti in eterno (se un

messaggio conteneva la prossima città da attaccare una volta avvenuto l’attacco …)

– nel caso di cifrario monoalfabetico, una piccola quantità di testo in chiaro conosciuto vale una fortuna • si dedurrebbe in modo immediato il mapping segreto di

tutte le lettere del testo in chiaro

Testo in chiaro conosciuto (known plaintext)

• Alcuni schemi di crittografia potrebbero essere

– molto resistenti ad attacchi di tipo ciphertext only,

– ma rivelarsi vulnerabili ad attacchi di tipo known plaintext

• un sistema che impiega un algoritmo di crittografia vulnerabile ad attacchi di tipo known plaintext,

• deve essere progettato in modo tale da prevenire il più possibile l’ottenimento di coppie plaintext, ciphertext

Testo in chiaro selezionato (chosen plaintext)

• Scenario

– Fred può scegliere a piacimento il testo in chiaro ed ottenere il corrispondente testo cifrato

• con lo stesso schema e chiave usati nella comunicazione cifrata tra Alice e Bob

– Come è possibile ottenere coppie plaintext, ciphertext con testo in chiaro scelto dal crittoanalista?

• un servizio di comunicazione potrebbe sbadatamente usare la stessa chiave per ogni messaggio inviato (per ogni coppia mittente destinatario)


• se Alice usa tale servizio, pure Fred potrebbe usarlo decidendo di inviare un messaggio (cifrato) a se stesso

• se il servizio usa un cifrario monoalfabetico, Fred potrebbe inviarsi il seguente messaggio:

“The quick brown fox jumps over the lazy dog”

ottenendo la biiezione segreta in modo immediato

• se il servizio di comunicazione usa uno schema di crittografia più evoluto, potrebbe essere ancora vulnerabile se Fred ha un’elevata conoscenza a priori del contenuto del messaggio di Alice, ad esempio Fred potrebbe aspettarsi o il messaggio “Surrender” o il messaggio “Fight on”,

• può quindi inviarsi entrambi i messaggi e confrontare le loro versioni cifrate con quelle del messaggio cifrato di Alice


– è possibile che un sistema crittografico sia sicuro contro attacchi di tipo ciphertext only e known plaintext, ma sia vulnerabile ad attacchi di tipo chosen plaintext

– un sistema crittografico dovrebbe resistere a tutti e tre i tipi di attacco

• in questo caso si avrebbe la massima protezione,

• non sempre è così, solitamente un algoritmo di cifratura è progettato per resistere ad attacchi di tipo ciphertext only

Tipologie di attacchi (tabella riassuntiva)

Tipologia di attacco Informazioni in possesso del crittoanalista

Solo testo cifrato • Algoritmo di cifratura • Testo cifrato da decifrare

Testo in chiaro conosciuto

• Algoritmo di cifratura • Testo cifrato da decifrare • Uno o più testi in chiaro e corrispondenti testi cifrati

Testo in chiaro selezionato

• Algoritmo di cifratura • Testo cifrato da decifrare • Testo in chiaro scelto dal crittoanalista e corrispondente testo cifrato

Testo cifrato selezionato

• Algoritmo di cifratura • Testo cifrato da decifrare • Testo cifrato, con significato, scelto dal crittoanalista e corrispondente testo in chiaro

Testo selezionato

• Algoritmo di cifratura • Testo cifrato da decifrare • Testo in chiaro scelto dal crittoanalista e corrispondente testo cifrato • Testo cifrato, con significato, scelto dal crittoanalista e corrispondente testo in chiaro

Sistema computazionalmente sicuro

• Un sistema di cifratura è computazionalmente sicuro se il testo cifrato generato soddisfa uno dei seguenti requisiti: – il costo per rendere inefficace il cifrario supera il

valore dell’informazione cifrata;

– il tempo richiesto per rendere inefficace il cifrario supera l’arco temporale in cui l’informazione ha una qualche utilità

• Si noti che – stimare lo sforzo computazionale richiesto per

effettuare con successo la crittoanalisi del testo cifrato è molto difficile

Sistema computazionalmente sicuro

– il tempo richiesto per un approccio a forza bruta • fornisce soltanto un limite superiore, ed

• è realistico solo se l’algoritmo non presenta delle debolezze intrinseche di tipo matematico; in questo caso si possono effettuare stime ragionevoli su tempi e costi

– in un approccio a forza bruta mediamente si devono provare metà di tutte le possibili chiavi • si consulti la tabella della slide successiva

Tempo medio per una ricerca esaustiva

Key Size (bits) Number of Alternative Keys

Time required at 1 decryption/µs

Time required at 106 decryptions/µs

32 232 = 4.3 109 231 µs = 35.8 minutes 2.15 milliseconds

56 256 = 7.2 1016 255 µs = 1142 years 10.01 hours

128 2128 = 3.4 1038 2127 µs = 5.4 1024 years 5.4 1018 years

168 2168 = 3.7 1050 2167 µs = 5.9 1036 years 5.9 1030 years

26 characters (permutation)

26! = 4 1026 2 1026 µs = 6.4 1012 years 6.4 106 years

TIPI DI FUNZIONI CRITTOGRAFICHE Introduzione alla Crittografia

Tipi di funzioni crittografiche

• Ci sono tre tipi di funzioni crittografiche

– funzioni a chiave pubblica (public key functions)

• richiedono l’uso di due chiavi

– funzioni a chiave segreta (secret key functions)

• richiedono l’uso di una sola chiave

– funzioni hash (hash functions)

• non usano alcuna chiave

• a cosa può servire un algoritmo di cifratura noto a tutti e che non usa chiavi?

CRITTOGRAFIA A CHIAVE SEGRETA (SECRET KEY CRYPTOGARPHY)


Crittografia a chiave segreta

• La crittografia a chiave segreta richiede l’uso di una sola chiave

– dato un messaggio (il testo in chiaro) e la chiave, la cifratura produce dati non intellegibili (il testo cifrato)

– il testo cifrato ha circa la stessa lunghezza di quello in chiaro

– la decifratura è l’inverso della cifratura, ed usa la stessa chiave

Crittografia a chiave segreta

• La crittografia a chiave segreta è talvolta chiamata crittografia convenzionale o crittografia simmetrica – il cifrario monoalfabetico è un esempio di algoritmo a

chiave simmetrica, sebbene sia facile da violare



KEY

Crittografia a chiave segreta – Impieghi

• Gli impieghi della crittografia a chiave segreta sono

– comunicazioni su un canale insicuro (uso classico)

– memorizzazione sicura su un supporto insicuro

– autenticazione

– controllo di integrità

Comunicazioni su un canale insicuro

• Spesso è impossibile evitare che due entità comunicanti possano essere ascoltate da una terza parte,

– la crittografia a chiave segreta permette a due entità che condividono un segreto (la chiave),

– di comunicare su un mezzo insicuro

• non è garantita l’assenza di intercettazioni/ascoltatori

– senza preoccuparsi di eventuali ascoltatori

Memorizzazione sicura

• Si supponga di disporre di un supporto di memorizzazione non protetto

– se si desidera salvare dei dati in forma sicura

• che non consente ad una terza parte di ottenerli

– si può inventare una chiave segreta e salvare i dati in forma crittata

• chiaramente, se si dimentica la chiave i dati sono irrevocabilmente persi

Autenticazione

– Nei film di spionaggio, quando due agenti che non si conoscono devono incontrarsi, usano una parola o frase segreta per riconoscersi

• ciò ha il seguente svantaggio: se qualcuno ascolta la loro conversazione o tenta di iniziarne una falsa, può ottenere informazioni utili per impersonare successivamente uno degli agenti

Autenticazione forte

• Il termine autenticazione forte (strong authentication) significa che si è in grado di provare la conoscenza di un segreto senza rivelarlo

– l’autenticazione forte è possibile con la crittografia

– è particolarmente utile quando due computer devono comunicare su una rete insicura

• Si supponga che Alice e Bob condividano una chiave segreta KAB e che vogliano autenticarsi

– cioè ciascuno vuole accertarsi dell’identità dell’altro

Autenticazione

– Bob e Alice scelgono ciascuno un numero random, noto come sfida (challenge),

• Alice sceglie il numero random rA

• Bob sceglie il numero random rB

– il valore x cifrato con la chiave KAB è noto come la risposta alla sfida x; cioè E(KAB, x) è la risposta ad x

– la slide seguente mostra come Alice e Bob usano sfide e risposte per autenticarsi

Possibile schema di autenticazione

Alice Bob

rA

E(KAB, rA)

rB

E(KAB, rB)


• Assunzione – Alice e Bob sono le uniche persone (o macchine) che

condividono la chiave segreta KAB

• Procedura di autenticazione – Alice genera un numero random rA (la sfida) e la invia al

presunto Bob – il presunto Bob critta la sfida con la sua chiave segreta K? e

restituisce ad Alice la risposta E(K?, rA) – Alice riceve la risposta del presunto Bob e la decritta con la

chiave KAB cioè calcola D(KAB, E(K?, rA)) • se ottiene rA, cioè se D(KAB, E(K?, rA)) = rA, allora il presunto Bob è

realmente Bob poiché K? = KAB

• altrimenti il presunto Bob è un impostore


• In modo analogo Bob verifica l’identità di Alice

– Bob genera un numero random rB (la sfida) e lo invia alla presunta Alice

– la presunta Alice critta la sfida con la sua chiave segreta K? e restituisce a Bob la risposta E(K?, rB)

– Bob riceve la risposta della presunta Alice e la decritta con la chiave KAB cioè calcola D(KAB, E(K?, rB)) • se ottiene rB, cioè se D(KAB, E(K?, rB)) = rB, allora la presunta

Alice è realmente Alice poiché K? = KAB

• altrimenti la presunta Alice è un impostore

Test di sicurezza

• Proviamo a testare la sicurezza dello schema di autenticazione appena proposto

• In particolare, un impostore, diciamo Fred, potrebbe seguire una strategia a due fasi:

1. impersonando Alice potrebbe ottenere alcune informazioni nell’autenticarsi con Bob

2. impersonando Bob e utilizzando le informazioni di cui sopra, potrebbe riuscire ad autenticarsi con Alice

Test di sicurezza

– Più precisamente, se Fred stesse impersonando Alice,

– potrebbe ottenere dal presunto Bob la risposta E(K?, rA*) ad una sua sfida rA*,

• Fred non può essere certo che il presunto Bob sia realmente Bob, se così fosse allora K? = KAB

– ma conoscere E(K?, rA*) non aiuterebbe Fred ad impersonare Bob nell’autenticazione con Alice reale

• anche se fosse K? = KAB,

• la conoscenza di E(KAB, rA*) non è sufficiente; la sfida rA che genera Alice è con elevata probabilità diversa da rA*

Osservazioni

• Possiamo concludere che

– se Alice e Bob completano con successo lo scambio di informazioni,

– ciascuno ha provato all’altro la conoscenza della chiave segreta KAB

• senza rivelarla ad un impostore e/o ascoltatore

Osservazioni

• Tuttavia, risulta anche che

– è possibile per Fred ottenere delle coppie

chosen plaintext, ciphertext

• Fred può affermare di essere Bob (Alice) e chiedere ad Alice (Bob) di cifrare una sfida

– quindi è essenziale che le sfide siano scelte da uno spazio sufficientemente grande, ad esempio 264 valori

• in questo modo risulta estremamente improbabile che venga generata la stessa sfida

Domanda

• Il precedente test di sicurezza è completo?

– esiste un metodo computazionalmente semplice per violare lo schema di autenticazione?

Controllo di integrità

• La crittografia a chiave segreta può servire a generare codici (somme) di controllo cifrati a lunghezza fissa – fixed-length cryptographic checksum

• uso poco intuitivo della tecnologia a chiave segreta!

• Un checksum ordinario (non cifrato) serve a proteggere i messaggi da eventuali corruzioni; cioè a verificarne l’integrità – la parola checksum deriva dal procedimento seguito per

ottenere il codice di controllo 1. scomposizione di un messaggio in blocchi di lunghezza fissa (ad

esempio parole da 32 bit)

2. somma bit a bit dei blocchi (OR oppure XOR )

Confronto di checksum

• La sorgente del messaggio ms rende pubblico/invia il corrispondente checksum c(ms)

• Chi riceve il messaggio mr calcola il checksum e confronta se vale l’uguaglianza c(ms) = c(mr) – se c(ms) = c(mr) conclude che ms = mr

• anche se potrebbero esserci degli errori che si compensano,

• cioè potrebbe darsi che ms ≠ mr e che risulti comunque c(ms) = c(mr)

Checksum non segreti

• I codici di controllo servono per proteggere l’hardware da difetti e da inevitabili errori/guasti

– esistono dei codici di controllo molto più sofisticati (codici CRC Controllo a Ridondanza Ciclica) tali che

• se ms ≠ mr allora è quasi certo che c(ms) ≠ c(mr), cioè

• è estremamente improbabile che sia c(ms) = c(mr)

– ma non sono utilizzabili per la protezione contro attacchi intelligenti

• essendo pubblici un avversario che vuole cambiare un messaggio potrebbe modificare anche il codice di controllo

Checksum segreto

• Per la protezione contro modifiche maliziose ad un messaggio, è richiesto un codice di controllo (checksum) segreto

– se l’algoritmo non è noto nessuno può calcolare il checksum corretto per il messaggio modificato

– chiaramente, come nel caso degli algoritmi di cifratura, anziché un algoritmo segreto conviene avere

• un algoritmo per il calcolo del checksum noto a tutti, che sfrutta una chiave segreta per calcolare il checksum di un messaggio

– in ciò consiste appunto un checksum cifrato

MIC – Message Integrity Code

• Data una chiave K e un messaggio m,

– l’algoritmo produce un codice di autenticazione di lunghezza fissa c(K, m)

• fixed-length MAC Message Authentication Code, o

• fixed-length MIC Message Integrity Code

– il codice MIC c(K, m) viene trasmesso insieme al messaggio m stesso

MIC – Message Integrity Code

• Se un avversario volesse modificare il messaggio m in m’

– dovrebbe anche calcolare il codice MIC c(K, m’)

• generalmente un codice MIC ha una lunghezza di almeno 48 bit

• la possibilità di ottenere il MIC corretto è una su 280 trilioni (1 trilione = 1012)

CRITTOGRAFIA A CHIAVE PUBBLICA (PUBLIC KEY CRYPTOGARPHY)


Crittografia a chiave pubblica

• La crittografia a chiave pubblica (public key cryptogarphy); talvolta detta anche crittografia asimmetrica (asymmetric cryptography)

– fu pubblicamente introdotta nel 1975

• alcune voci sostengono che l’NSA già la utilizzasse

– diversamente dalla crittografia a chiave segreta NON PREVEDE la condivisione delle chiavi, ma

– ogni individuo ha due chiavi

• una chiave privata da NON RIVELARE a nessuno

• una chiave pubblica da rivelare preferibilmente a tutto il mondo

Terminologia e notazione

• Per convenzione non si userà il termine “chiave segreta” in luogo di “chiave privata”

– in base all’aggettivo della chiave sarà immediato risalire allo schema di crittografia usato

• “chiave segreta” denota l’informazione segreta condivisa in uno schema di crittografia a chiave segreta

• “chiave privata” denota la chiave che non deve essere resa pubblica in uno schema di crittografia a chiave pubblica

• “chiave pubblica” denota la chiave da divulgare in uno schema di crittografia a chiave pubblica

Terminologia e notazione

• Si userà la seguente notazione – PU rappresenta la chiave PUbblica

• ad esempio PUB indica la chiave pubblica di Bob

– PR rappresenta la chiave PRivata • ad esempio PRB indica la chiave privata di Bob



PU PUBLIC KEY

PR PRIVATE KEY

Schema di cifratura a chiave pubblica

• La figura sotto mostra uno schema di cifratura a chiave pubblica – cifratura e decifratura sono due funzioni matematiche

che sono l’una l’inverso dell’altra

– m = D(PR, E(PU, m))



PU PUBLIC KEY

PR PRIVATE KEY

E(PU, m) m D(PR, E(PU, m))

Firma digitale (a chiave pubblica)

• La tecnologia a chiave pubblica consente anche di generare una firma digitale su un messaggio

– basta invertire il ruolo delle chiavi

– m = D(PU, E(PR, m))


PLAINTEXT PLAINTEXT SIGNED MESSAGE

PR PRIVATE KEY

PU PUBLIC KEY

SIGNING VERIFICATION

S(PR, m) E(PR, m) m

V(PU, E(PR, m)) D(PU, E(PR, m))


• Una firma digitale (digital signature) è un numero associato ad un messaggio – una sorta di checksum o MAC, ma diversamente

da un checksum, che può essere generato da tutti,

– una firma digitale può essere generata soltanto da chi conosce la chiave privata PR

– una firma a chiave pubblica differisce da un MAC a chiave segreta • la verifica di un MAC richiede la conoscenza dello stesso

segreto (chiave segreta) usato per crearlo

• quindi chi può verificare un MAC può anche generarlo e sostituirsi alla sorgente iniziale


– invece, nel caso della firma a chiave pubblica,

– la verifica della firma richiede soltanto la conoscenza della chiave pubblica PU

• Alice può firmare un messaggio generando una firma che solo lei può generare, in quanto usa la sua chiave privata PRA

• chiunque altro può verificare se quella generata è realmente la firma di Alice (basta usare la chiave pubblica di Alice PUA), ma non può falsificarla

– si parla di firma digitale perché condivide con la tradizionale firma manuale la proprietà di poter essere riconosciuta autentica senza poter essere falsificata

Uso della crittografia a chiave pubblica

• La crittografia a chiave pubblica – può fare tutto ciò che la crittografia a chiave segreta

può fare • comunicazioni su un canale insicuro (uso classico)

• memorizzazione sicura su un supporto insicuro

• autenticazione

• controllo di integrità

– ma gli attuali algoritmi crittografici a chiave pubblica sono di alcuni ordini di grandezza più “lenti” dei migliori algoritmi a chiave segreta,

– viene pertanto utilizzata in congiunzione alla crittografia a chiave privata


– agevola la configurazione/gestione della sicurezza di una rete

• potrebbe usarsi all’inizio di una comunicazione in fase di autenticazione, e

• per stabilire una chiave segreta temporanea,

• che a sua volta (per motivi di efficienza) può essere usata per cifrare il resto della comunicazione

• ad esempio, si supponga che Alice voglia parlare con Bob, Alice può usare la chiave pubblica di Bob PUB per cifrare una chiave segreta (che genera) KAB

• poi può usare la chiave segreta KAB per cifrare qualunque messaggio voglia inviare a lui


• dato che la chiave segreta KAB è molto più corta di un generico messaggio, la sua cifratura a chiave pubblica non impatta sulle prestazioni

• la chiave KAB generata da Alice può essere decifrata soltanto da Bob, che può continuare la comunicazione utilizzando quest’ultima (in uno schema di cifratura a chiave segreta) con chiunque abbia inviato il messaggio

• si osservi che usando questo protocollo Bob non può essere certo che sia stata Alice ad inviare il messaggio

• una soluzione potrebbe essere che Alice invia la chiave segreta KAB crittata con la chiave pubblica di Bob PUB dopo averla firmata digitalmente con la sua chiave privata PRA


Alice Bob

E(PUB, KAB)

gen. KAB

KAB = D(PRB, E(PUB, KAB))

E(KAB, mA)

mA

mA = D(KAB, E(KAB, mA))

mA

E(KAB, mA)

KAB

Bob non può essere certo di comunicare con Alice


Alice Bob

E(PUB, KAB)

gen. KAB

V(PUA, S(PRA, E(PUB, KAB))) = = D(PUA, D(PRB, E(PUB, KAB))) = E(PUB, KAB)

E(KAB, mA)

mA

mA = D(KAB, E(KAB, mA))

mA

E(KAB, mA)

KAB

Bob può essere certo di comunicare con Alice

Firma digitale S(PRA, E(PUB, KAB)) = E(PRA, E(PUB, KAB))

D(PRB, E(PUB, KAB)) = KAB


• Si supponga che – PUA, PRA sia la coppia public key, private key di Alice

– PUB, PRB sia la coppia public key, private key di Bob

– Alice conosce la chiave pubblica di Bob PUB

– Bob conosce la chiave pubblica di Alice PUA

• si osservi che procurarsi le chiavi pubbliche di altre persone è una delle principali sfide poste dalla crittografia a chiave pubblica

• per il momento non ce ne preoccupiamo

– la slide che segue illustra come avviene la comunicazione su un canale insicuro


Alice Bob

E(PUB, mA)

E(PUB, mA)

D(PRB, E(PUB, mA)) = mA

E(PUA, mB) E(PUA, mB)

mB = D(PRA, E(PUA, mB))


• Esattamente come avviene nel caso di crittografia a chiave segreta

– si possono crittare i dati con la chiave pubblica PUX

– nessuno può decrittare i dati tranne chi conosce la chiave privata PRX

• tuttavia, per ragioni di efficienza, non conviene cifrare i dati direttamente con la chiave pubblica,

• ma piuttosto conviene generare randomicamente una chiave segreta KX, e

• crittare i dati con la chiave segreta KX, e

• crittare la chiave segreta con la chiave pubblica E(PUX, KX)


• Come nel caso di tecnologia a chiave segreta – perdere la chiave privata implica perdere

irrimediabilmente i dati

– per evitare questo rischio, si può crittare una copia della chiave di cifratura segreta KX con la chiave pubblica di una persona fidata PUFidata

– o memorizzare copie della chiave privata PRX presso una persona fidata

• Si noti che la tecnologia a chiave pubblica offre un chiaro vantaggio rispetto quella a chiave segreta – Alice può cifrare un messaggio per Bob senza conoscere la

sua chiave di decifratura

Autenticazione

• La tecnologia a chiave segreta presenta i seguenti svantaggi:

– Alice e Bob per poter autenticarsi devono condividere un segreto

– se Bob deve provare la sua identità a molte entità, allora deve mantenere molte chiavi segrete

• una chiave segreta per ogni entità alla quale deve provare la sua identità

• potrebbe anche usare la stessa chiave segreta con Alice e Carol, ma ciò comporterebbe che Alice e Carol potrebbero impersonare Bob in una comunicazione tra loro due

Autenticazione

• La tecnologia a chiave pubblica semplifica notevolmente la gestione dei “segreti” – Bob deve soltanto ricordare un singolo segreto: la

sua chiave privata

– chiaramente, deve anche mantenere/ottenere tutte le chiavi pubbliche delle entità di cui desidera verificare l’identità • potrebbero essere anche migliaia di chiavi pubbliche

• la gestione delle chiavi pubbliche sarà discussa in seguito

Schema di autenticazione

• Assunzione – Alice conosce la chiave pubblica di Bob PUB

– la chiave privata di Bob PRB è conosciuta soltanto da Bob

– Bob conosce la chiave pubblica di Alice PUA

– la chiave privata di Alice PRA è conosciuta soltanto da Alice

• Procedura di autenticazione – Alice verifica l’identità di Bob

– Bob verifica l’identità di Alice

Alice verifica l’identità di Bob

Alice Bob

rA

gen. rA

E(PUB, rA)

D(PRB, E(PUB, rA)) = rA

Alice verifica l’identità di Bob

• Usando la tecnologia a chiave pubblica Alice può verificare l’identità di Bob come segue: – Alice estrae un numero random rA (la sfida)

– Alice critta rA con la chiave pubblica di Bob e invia il risultato E(PUB, rA) a Bob

– Bob dimostra la sua identità mostrando che conosce la sua chiave privata PRB, ovvero decritta E(PUB, rA) riottenendo rA = D(PRB, E(PUB, rA))

– Bob rispedisce indietro ad Alice la sfida rA

– Alice ha la prova che il suo interlocutore è realmente Bob

Altro vantaggio

• Un altro vantaggio dell’autenticazione a chiave pubblica è che Alice non deve mantenere alcuna informazione segreta per verificare Bob – Alice potrebbe essere un computer i cui backup sono in

chiaro e incustoditi

– nell’autenticazione a chiave segreta se Carol ruba un backup e legge una chiave segreta condivisa tra Alice e Bob

– può fingersi Alice in una comunicazione con Bob • o viceversa

• Invece, nel caso di autenticazione a chiave pubblica – i backup di Alice contengono soltanto chiavi pubbliche

(quella privata va custodita in modo diverso) non possono consentire di impersonare Bob

Firma digitale

• Spesso è utile provare che un messaggio è stato generato da un particolare individuo

– ciò è semplice con la tecnologia a chiave pubblica

– la firma di Bob per un messaggio m può essere generata soltanto da chi conosce la chiave privata di Bob PRB, e

– la firma dipende anche dal contenuto di m

– se il messaggio viene modificato in qualche modo,

– la corrispondenza con la firma viene persa

Firma digitale

• Pertanto, le firme digitali hanno una duplice funzione – provano CHI ha generato l’informazione,

– provano che l’informazione non è stata modificata in alcun modo dal momento in cui il messaggio e la corrispondente firma furono generati

• Inoltre, le firme digitali offrono un vantaggio importante rispetto ai checksum crittografici a chiave segreta (cioè i MAC/MIC): – garantiscono il requisito del non-ripudio (non-repudiation)

Non-ripudio

• Obiettivo del non-ripudio è impedire che il mittente o il destinatario neghino che sia stato trasmesso un messaggio

– il destinatario può provare che il messaggio è stato inviato dal presunto mittente (non ripudio della sorgente o del mittente)

– il mittente può provare che il messaggio è stato effettivamente ricevuto dal presunto destinatario (non ripudio del destinatario)

Non ripudio – esempio

• Si supponga che Bob venda articoli che Alice solitamente compra – la procedura di vendita prevede che Alice deve prima

inviare a Bob, via servizio postale, un ordine di acquisto da lei firmato

– per snellire la procedura Alice e Bob decidono di usare l’email per la spedizione degli ordini di acquisto

– per evitare falsificazioni Alice include in ogni email un MIC (Message Integrity Code) • per evitare che qualcuno ordini degli articoli dichiarandosi Alice

– il MIC potrebbe essere • o un MAC che sfrutta una chiave segreta MIC = c(KAB, ordine)

• o una firma digitale a chiave pubblica MIC = S(PRA, ordine)


– si supponga che Alice richieda un articolo di grande valore, ma subito dopo cambi idea • per un qualunque motivo

– visto che la cancellazione dell’ordine prevede una penale considerevole, Alice anziché cancellare l’ordine preferisce negare di averlo piazzato

– Bob le fa causa • se il MIC era stato ottenuto con una chiave segreta KAB

Bob è certo che Alice sta truffando (oltre a lui solo lei conosce KAB), ma non può provarlo in tribunale

• Alice potrebbe sostenere che è stato lui stesso ad ordinarsi l’articolo di valore!


• invece, se il MIC era stato ottenuto con una tecnologia a chiave pubblica MIC = S(PRA, ordine)

• Bob può mostrare l’ordine firmato al giudice e il giudice può verificare che la firma è quella di Alice

• Alice potrebbe sostenere che qualcuno ha rubato la sua chiave privata

• tuttavia il contratto stipulato tra Alice e Bob potrebbe prevedere che eventuali danni che Bob subisce causa lo smarrimento della chiave privata PRA siano a carico di Alice

– il vantaggio della tecnologia a chiave pubblica è che Alice può cifrare un messaggio per Bob senza conoscere la sua chiave di decifratura

ALGORITMI DI HASH (CRITTOGRAFICI)


Algoritmi di hash (crittografici)

• Noti anche come algoritmi di digest o one-way transformation

– Una funzione di hash crittografica è una trasformazione matematica che

• prende in input un messaggio m di lunghezza arbitraria (codificato in una stringa di bit), e

• calcola un numero h(m), l’output, avente una lunghezza fissa prestabilita

• h(m) dipende dal messaggio

• la lunghezza (numero di bit) del numero h(m) è fissa

• h : {0, 1}* → {0, 1}b b: numero di bit dell’output

Funzioni di hash crittografiche – Proprietà

1) Per ogni messaggio m, è relativamente facile calcolare h(m) – non si tratta di un’operazione computazionalmente dispendiosa

2) Noto h(m), “non c’è modo” di calcolare un messaggio il cui hash sia h(m) – l’unico approccio noto è quella di tipo brute force

3) Sebbene sia ovvio che molti valori distinti di m ammettano lo stesso hash h(m) – poiché lo spazio {0, 1}* è molto più grande di {0, 1}b

è computazionalmente impraticabile trovare due valori aventi il medesimo hash

Idea base per una funzione hash

• Un possibile approccio per il calcolo di una funzione hash è il seguente

– dato un messaggio m, interpretare la codifica binaria di m come un numero intero,

– sommare ad m alcune grandi costanti intere,

– elevare al quadrato il tutto,

– l’hash h(m) è il numero ottenuto considerando le n cifre centrali

Idea base per una funzione hash

• Si osservi che

– h(m) è calcolabile efficientemente a partire da m

– non è chiaro come sia possibile

• trovare un messaggio avente uno specifico hash

• trovare due messaggi aventi lo stesso hash

– tuttavia si può dimostrare che quello appena descritto non è un buon algoritmo di digest

• l’idea base di una buona funzione di digest è comunque la stessa: l’input è strapazzato così tanto da rendere proibitiva l’inversione

Funzioni hash e password

• Spesso un sistema deve verificare le password dei suoi utenti – se tutte le password sono memorizzate in chiaro,

– tutti coloro che hanno accesso al sistema (amministratori, tecnici, etc.) possono rubare le password

– fortunatamente, non è necessario conoscere una password per verificarla! • A proper password is like pornography. You can't tell what it

is, but you know it when you see it.

– invece delle password in chiaro un sistema potrebbe memorizzare l’hash delle password


– per verificare una password d’utente p, il sistema • calcola prima l’hash della password h(p)

• e verifica se h(p) coincide con l’hash memorizzato per quell’utente,

• se coincidono la password è considerata corretta

– se un avversario ottiene il file (relazione db) con l’elenco delle password d’utente,

– non può usarlo in modo immediato perché la funzione di hash è non invertibile • addirittura in passato l’elenco contenente l’hash delle

password è stato in alcuni casi reso pubblico; era un modo per ostentare sicurezza da NON IMITARE


• infatti, anche se la funzione di hash non presenta difetti crittografici intrinseci che possono essere sfruttati,

• è sempre possibile scegliere delle password a caso, calcolarne l’hash e verificare la corrispondenza,

• se un utente U sceglie superficialmente la propria password pU (situazione frequente), ad esempio una parola di un dizionario, una ricerca esaustiva su una repository di password probabili consentirebbe di risalire a pU

• per tale ragione molti sistemi nascondono l’elenco contenete l’hash delle password

Funzioni hash – Integrità di messaggi

• Le funzioni di hash vengono spesso impiegate per verificare l’integrità di un messaggio – permettono cioè di generare dei MAC/MIC

• Come è possibile generare MAC/MIC? – data una coppia m, h(m), se il messaggio viene

accidentalmente corrotto, diciamo diventa m’, risulta h(m) ≠ h(m’) – tuttavia, se un avversario modifica deliberatamente il

messaggio può calcolare anche il suo nuovo hash • gli algoritmi di hash sono pubblici

– di per sé le funzioni di hash non sono utilizzabili per verificare l’integrità dei messaggi contro attacchi maliziosi


• Tuttavia, se Alice e Bob condividono un segreto KAB e Alice vuole inviare un messaggio m a Bob

– Alice può concatenare il messaggio m con il segreto KAB

• ottenendo un nuovo messaggio m’ = (m||KAB)

– calcolare l’hash del nuovo messaggio h(m’) = h(m||KAB) • l’hash h(m||KAB) è detto keyed hash e può considerarsi un MAC

(anche se presenta delle sottili debolezze)

– ed inviare la coppia m, h(m||KAB) a Bob

– Bob concatena il messaggio ricevuto con il segreto e calcola l’hash • se l’hash ottenuto coincide con l’hash ricevuto

• allora Bob può, con un elevato grado di confidenza, ritenere che il messaggio è stato inviato da qualcuno che conosceva il segreto


m II CONCATENATION

KAB

mIIKAB h(∙)

HASH

II

CONCATENATION

h(∙)

HASH

KAB

=?

Alice Bob

“Impronta digitale” di dati

• Si supponga di disporre di un grande repository di dati di sola lettura e di voler periodicamente verificare che non vi siano modifiche – si potrebbe mantenere una copia di backup del repository

in un luogo a prova di manomissione, e

– periodicamente confrontarla con la repository attiva

• usando una funzione di hash si ha un notevole risparmio di memoria e tempo – basta salvare l’hash del repository in un luogo protetto, e

– confrontare l’hash del repository con l’hash precedentemente salvato

“Impronta digitale” di dati

• nota: il programma che calcola l’hash va protetto in modo indipendente dall’hash stesso – altrimenti, un avversario può modificare il repository, e

– modificare il programma per il calcolo dell’hash in modo tale che l’hash finale sia quello salvato

• L’hash del repository funge pertanto da “impronta digitale” utilizzabile nei test di integrità – garantendo un notevole risparmio di memoria, e

– di tempo necessario al confronto

Downline load security

• Spesso molti dispositivi di rete (router, stampanti, etc.) – anziché memorizzare in una memoria non-volatile i

programmi che generalmente eseguono • perché non hanno una memoria non-volatile o ne hanno una di

ridotte dimensioni

– li richiedono in fase di bootstrap via rete ad un server preposto a svolgere tale servizio

– tale schema viene detto downline load

• in questi casi l’hash viene usato per verificare che il programma scaricato sia quello corretto cioè non vi siano state modifiche accidentali o intenzionali – basta memorizzare soltanto l’hash del programma corretto – e, ad ogni download, calcolare l’hash del programma

scaricato verificando che coincida con quello in memoria

Firma digitale efficiente

• I migliori algoritmi di cifratura a chiave pubblica (conosciuti) sono computazionalmente dispendiosi, conviene pertanto (anziché firmare l’intero messaggio)

– calcolare prima un digest del messaggio con una funzione di hash, e

– firmare il digest ottenuto,

• Si osservi che – gli algoritmi per il calcolo del digest sono

computazionalmente molto più efficienti, e

– il digest è molto più corto dell’intero messaggio

Bibliografia

• [KPS02] C. Kaufman, R. Perlman, M. Speciner. Network Security – Private Communication in a Public World. Prentice Hall.



• [Wiki-it] http://it.wikipedia.org/wiki/ • [Wiki-en] http://en.wikipedia.org/wiki/ • [ISECOM] Institute for Security and Open

Methodologies

Crittografia a Chiave Segreta (Secret Key Cryptography)

Luca Grilli

INTRODUZIONE Crittografia a Chiave Segreta

Introduzione

• Si descriverà il funzionamento degli algoritmi di crittografia a chiave segreta

– si vedranno in dettaglio gli algoritmi DES e IDEA

– tali algoritmi non si applicano direttamente ad un messaggio di lunghezza qualsiasi, ma ricevono in input

• un blocco del messaggio di lunghezza fissa (64 bit nel caso di DES e IDEA)

• una chiave di lunghezza fissa (56 bit per DES e 128 bit per IDEA)

– l’output è un blocco cifrato (della stessa lunghezza del blocco di input)

• per tale ragione si parla di algoritmi di cifratura a blocchi

Introduzione

– la cifratura di un messaggio di lunghezza qualsiasi viene ricondotta alla cifratura dei singoli blocchi

• il messaggio m viene scomposto in blocchi di lunghezza fissa

• la cifratura del messaggio m viene ottenuta combinando opportunamente le cifrature dei suoi blocchi

– In altri termini, è possibile ottenere un algoritmo di cifratura simmetrica per messaggi di lunghezza qualsiasi utilizzando come modulo base un algoritmo di cifratura simmetrica a blocchi

CIFRATURA A BLOCCHI – SCHEMA GENERALE

Crittografia a Chiave Segreta

Cifratura a blocchi – introduzione

• L’algoritmo di cifratura converte un blocco di testo in chiaro in un blocco di testo cifrato

– la chiave K non deve essere troppo corta

• es. se K ha lunghezza 4 bit, sono sufficienti 24 = 64 tentativi per individuarla!

– analogamente, la lunghezza (fissata) di un blocco non deve essere troppo piccola

• es. se un blocco ha lunghezza 8 bit, ottenendo delle coppie plaintext, ciphertext si potrebbe costruire una tabella di 28 = 256 coppie utilizzabile per la decifratura

Cifratura a blocchi – introduzione

– d’altra parte, avere blocchi esageratamente lunghi • oltre a non essere necessario dal punto di vista della

sicurezza,

• comporta una gestione più complicata, e

• può degradare le prestazioni

– 64 bit è una lunghezza ragionevole per un blocco • è improbabile ottenere ordine di 264 coppie plaintext,

ciphertext per costruire una tabella di decifratura, e

• anche se fosse possibile, la sua memorizzazione richiederebbe una spazio enorme 264 record da 64 bit,

• come pure l’ordinamento per consentire ricerche efficienti

Cifratura a blocchi – concetti generali

• Il modo più generale per cifrare un blocco da 64 bit è definire una biiezione γ: {0, 1}64 {0, 1}64

– memorizzare la definizione della biiezione in una struttura dati è impraticabile

• sono richiesti 64 ∙ 264 bit, cioè 270 bit

• ad essere precisi ce ne vogliono un po’ di meno, trattandosi di un biiezione, comunque almeno 269 bit sono richiesti

– inoltre, così facendo la chiave è incorporata nella biiezione

• per rendere parametrica la biiezione rispetto la chiave è necessario memorizzare una biiezione per ogni possibile chiave!


• I sistemi di crittografia a chiave segreta sono concepiti per – usare una chiave ragionevolmente lunga

• ad esempio 64 bit

– generare una biiezione che appare, a chi non conosce la chiave, completamente random

– cioè, la biiezione sembra essere definita utilizzando un generatore di numeri casuali • l’output γ(i) di un input i si ottiene lanciando un dado a 64

facce o facendo 64 lanci di monete

• avendo l’accortezza di ripetere la procedura se il valore ottenuto per l’output γ(i) coincide con qualche γ(j) con j < i (cioè se γ(i) era già stato assegnato ad un precedente input)


• Se la biiezione fosse realmente random – un input i’ ottenuto cambiando un qualunque bit di un

input i

– sarebbe mappato in un output γ(i’) tale che γ(i’) e γ(i) risultano statisticamente indipendenti • ad esempio, non può succedere che il terzo bit dell’output

cambia sempre quando il dodicesimo bit dell’input cambia

• Gli algoritmi crittografici sono pensati per diffondere/spargere in tutti i bit dell’output il valore di ogni bit dell’input – ogni bit dell’output deve dipendere da tutti i bit

dell’input e allo stesso modo

Sostituzione

– Sostituzioni e permutazioni sono due trasformazioni base applicabili ad un blocco di dati

• Si assuma di dover cifrare un blocco di k bit

• Una sostituzione specifica, per ciascuno dei 2k possibili valori dell’input, i k bit dell’output

– per specificare una sostituzione “completamente random” sono necessari circa k∙2k bit

• è impraticabile implementare una sostituzione per blocchi di 64 bit,

• ma è fattibile per blocchi di lunghezza di 8 bit

Permutazione

• Una permutazione specifica, per ciascuna delle k posizioni dei bit in input, la posizione del corrispondente bit nell’output

• ad esempio, il bit in posizione 1 diventa il bit in posizione 13 nell’output,

• il bit in posizione 2 diventa il bit in posizione 61 nell’output, e così via

– per specificare una permutazione “completamente random” per un blocco di lunghezza k bit sono necessari k∙log2k bit

Permutazione

– per ciascuno dei k bit va specificata la sua posizione nell’output; ogni posizione richiede log2k bit

• ad esempio, essendo 26 = 64, sono necessari 6 = log264 bit per specificare la nuova posizione che l’i-esimo bit in input avrà in output

Permutazione vs Sostituzione

• Una permutazione è un caso particolare di sostituzione in cui ogni bit dell’output ottiene il suo valore da esattamente un bit dell’input

– per blocchi di 64 bit è possibile specificare e realizzare un permutatore

• un modulo che riceve in input un blocco di 64 bit e produce in output una data permutazione dei bit in input

Cifrario a blocchi – schema generale

• Un algoritmo di cifratura a chiave segreta può funzionare come segue – scompone il blocco in input in pezzi più piccoli (blocchi da

8 bit)

– applica una sostituzione a ciascun pezzo da 8 bit • la sostituzione dipenderà dal valore della chiave

– gli output delle sostituzioni vengono riuniti in un unico blocco (64 bit),

– tale blocco viene permutato in un permutatore a 64 bit • che ha il compito di diffondere le modifiche eseguite nelle

sostituzioni

– il processo viene ripetuto un certo numero di volte riportando l’output in ingresso

Esempio di cifrario a blocchi

Esempio di cifrario a blocchi

• Ogni attraversamento del cifrario viene detto round

– con un solo round, un bit bx di input può influenzare soltanto 8 bit bx1, bx2, …, bx8 dell’output

• poiché bx ha attraversato soltanto un blocco di sostituzione

• in generale i bit bx1, bx2, …, bx8 non sono consecutivi essendo stati mescolati nel permutatore

– alla fine del secondo round, assumendo che i bit bx1, bx2, …, bx8 siano smistati in un diverso blocco di sostituzione

– il bit bx iniziale influenza tutti i bit in output

ALGORITMO DES DATA ENCRYPTION STANDARD


Data Encryption Standard (DES)

• DES fu pubblicato nel 1977 dal National Bureau of Standards – ora rinominato National Institute of Standards and

Technology (NIST)

– per usi commerciali e “altre” applicazioni del governo statunitense

– progettato da IBM, si basa sul precedente cifrario Lucifer ed è frutto della collaborazione con consulenti della NSA

– DES usa una chiave di 56 bit, e mappa un blocco di input da 64 bit in un blocco di output da 64 bit


– la chiave è in realtà costituita da una sequenza di 64 bit, ma un bit in ogni ottetto (il blocco da 64 bit è formato da 8 sequenze di 8 bit dette ottetti) è usato come odd parity su ciascun ottetto

– di fatto, soltanto 7 bit in ogni ottetto sono veramente significativi come chiave

– DES è efficiente se realizzato in hardware, ma relativamente lento se implementato in software • sebbene l’essere difficilmente implementabile come

software non era un requisito specificato nel progetto,

• molti sostengono che in realtà era un fatto voluto,


• forse per limitarne l’uso ad organizzazioni in grado di realizzare sistemi hardware, o

• forse perché rese più facile controllare l’accesso alla tecnologia

• ad ogni modo, l’aumento delle capacità di calcolo delle CPU rese possibile realizzare una versione software di DES

– una 500-MIPS (Million Instruction Per Second) CPU può cifrare ad un tasso di circa 30 KB/s,

– e forse più, dipende dai dettagli architetturali della CPU e dalla intelligenza dell’implementazione

– un processore Intel Core i7 Extreme Edition i980EE ha una capacità di calcolo di circa 150 MIPS può cifrare ad un tasso di circa 9 KB/s per cifrare 1 MB impiega circa 110 secondi

• l’implementazione software è pertanto adeguata a molte applicazioni

Perché chiavi da 56 bit?

• La scelta di una chiave da 56 bit causò molte controversie

– prima che DES fu adottato, le persone al di fuori della intelligence community lamentavano che 56 bit non offrivano una sicurezza adeguata

– perché solo 56 dei 64 bit di una chiave DES sono effettivamente usati nell’algoritmo?

• lo svantaggio di usare 8 bit della chiave per un controllo di parità è che ciò rende DES molto meno sicuro (256 volte meno sicuro contro una ricerca esaustiva)


• Qual è il vantaggio di usare 8 bit per un controllo di parità? – una possibile risposta è: per verificare che la

chiave non sia corrotta!

– ma questa spiegazione non regge! • se si considerassero 64 bit a caso invece della chiave,

c’è una probabilità su 256 che il controllo di parità dia esito positivo la probabilità che la chiave sia comunque errata è troppo alta!

• inoltre avere una chiave corrotta non comporta un problema di sicurezza, semplicemente la cifratura/decifratura non viene eseguita correttamente


– chiaramente è anche ridicolo sostenere che la scelta di 56 bit è stata fatta per risparmiare memoria

• La risposta ormai condivisa è che il governo statunitense abbia deliberatamente indebolito la sicurezza di DES di una quantità appena sufficiente da consentire alla NSA di violarlo

Sulla violabilità di DES

• Gli avanzamenti tecnologici dell’industria dei semiconduttori hanno reso ancora più critico il problema della lunghezza della chiave di DES – la velocità dei chip e un po’ di furbizia permettono di

violare (individuare) le chiavi DES con approcci a forza bruta in tempi ragionevoli

– forse una chiave a 64 bit sarebbe stata sicura per pochi anni in più rispetto ad una chiave a 56 bit

– il rapporto prestazioni/prezzo dell’hardware cresce del 40% per anno la lunghezza delle chiavi dovrebbe aumentare di 1 bit ogni 2 anni

Sulla violabilità di DES

– assumendo che 56 bit erano appena sufficienti nel 1979 (quando DES fu standardizzato)

– 64 bit erano adeguati nel 1995, e

– 128 bit dovrebbero essere sufficienti fino al 2123

Quanto sicuro è DES?

• Se si dispone di un singolo blocco plaintext, ciphertext quanto è difficile trovare la chiave?

– un approccio a forza bruta dovrebbe provare ordine di 256 ≈ 1017 chiavi

– se ogni tentativo richiede una singola istruzione sono necessarie ordine di 1000 MIPS-year istruzioni

• 1 MIPS = 1 Milione di Istruzioni Per Secondo

• 1 MIPS-year = numero di istruzioni eseguite in un anno ad un tasso pari a 1 MIPS

• 1 MIPS-year = 1 MIPS ∙ (365 ∙ 86400) secondi in un anno = 3,1536 ∙ 1013 istruzioni

• 256 ≈ 1017 ≈ 103 MIPS-year


• Anche nell’ipotesi più scomoda per l’avversario di disporre solo di testo cifrato – una ragionevole quantità di testo cifrato

• un attacco a forza bruta può essere ancora possibile – se ad esempio l’avversario sa soltanto che il testo in chiaro

è ASCII a 7 bit

– ogni volta che prova una chiave deve verificare se sono nulli tutti i bit nelle posizioni 8, 16, 24, …, n∙8, … • per ogni blocco di 64 bit, vanno esaminati solo 8 bit; i bit in

posizione 8, 16, 24, 32, 40, 48, 56, 64

• se almeno uno di questi bit vale 1 la chiave è sicuramente errata

• in caso contrario nulla si può dire; la probabilità di errore è pertanto 1 su 256 ossia la probabilità che tutti questi bit valgano 0


– se l’avversario esamina diversi blocchi, ad esempio 10, e verifica che si tratta sempre di ASCII a 7 bit la probabilità che la chiave scelta sia errata si riduce a 1 su 2560

– si noti che gli attuali chip commerciali che implementano DES non si prestano a ricerche esaustive della chiave, sono pensati per cifrare molti dati con una stessa chiave • il caricamento di una chiave è un’operazione lenta se

confrontata con la velocità con la quale viene eseguita la cifratura dei dati

• tuttavia è sempre possibile costruire un chip ottimizzato ad eseguire ricerche esaustive della chiave


• Ovviamente è possibile cifrare più volte e con diverse chiavi lo stesso blocco di dati

– si parla di cifratura multipla (multiple encryption)

• Si ritiene che una cifratura con un triplo DES è 256 volte più difficile da violare

– può considerarsi sicura per il prossimo futuro

DES – Struttura base


– In estrema sintesi la cifratura di DES è come segue

• L’input di 64 bit è sottoposto ad una permutazione iniziale; un semplice mescolamento dei bit

• La chiave da 56 bit viene usata per generare 16 per-round chiavi da 48 bit; una chiave per ciascuno dei 16 round – prendendo 48 differenti sottoinsiemi dei 56 bit della chiave

• Ogni round riceve in input – l’output di 64 bit del round precedente

– la chiave da 48 bit di quel round

• e produce un output di 64 bit


• Dopo il 16-esimo round, le due metà dell’output di 64 bit vengono scambiate e il risultato viene sottoposto ad un’altra permutazione – la permutazione finale, che è l’inverso di quella iniziale

• La decifratura consiste esattamente nell’eseguire la cifratura DES all’indietro

• Per decifrare un blocco è necessario: – applicare la permutazione iniziale; ciò annulla l’effetto

della permutazione finale

– generare le 16 chiavi di round, che andranno usate in ordine inverso (prima K16 l’ultima chiave generata)


– eseguire 16 round esattamente come nella cifratura

• il motivo per cui funziona sarà illustrato quando si spiegherà cosa succede durante un round

– dopo 16 round di decifratura, le due metà dell’output di 64 bit vengono scambiate e il risultato viene sottoposto ad un’altra permutazione

• che annulla la permutazione iniziale

– Per descrivere in dettaglio DES è necessario illustrare

• le permutazioni iniziale e finale,

• come le chiavi di round sono generate, e

• cosa succede durante un round

Permutazioni dei dati

• DES effettua una permutazione iniziale e una permutazione finale dei dati che

– NON migliorano la sua sicurezza!

– forse sono state introdotte per rendere meno efficienti le implementazioni software


• Le permutazioni specificate in DES sono rappresentate nelle due tabelle

58 50 42 34 26 18 10 2

60 52 44 36 28 20 12 4

62 54 46 38 30 22 14 6

64 56 48 40 32 24 16 8

57 49 41 33 25 17 9 1

59 51 43 35 27 19 11 3

61 53 45 37 29 21 13 5

63 55 47 39 31 23 15 7

40 8 48 16 56 24 64 32

39 7 47 15 55 23 63 31

38 6 46 14 54 22 62 30

37 5 45 13 53 21 61 29

36 4 44 12 52 20 60 28

35 3 43 11 51 19 59 27

34 2 42 10 50 18 58 26

33 1 41 9 49 17 57 25

Initial Permutation (IP) Final Permutation (IP-1)


• Le tabelle vanno interpretate nel seguente modo

– i numeri, da 1 a 64, riportati in tabella rappresentano le posizioni dei bit in input alla permutazione

– l’ordine (per righe da sx verso dx) dei numeri nella tabella rappresenta la corrispondente posizione dei bit in output

• ad esempio, la permutazione iniziale sposta il 58-esimo bit in input nel primo bit in output, e

• il 50-esimo bit in input nel secondo bit in output

Permutazione iniziale – input e output

• Non si tratta di una permutazione generata “in modo random” – nel senso che presenta delle regolarità evidenti

b1 b2 b3 b4 b5 b6 b7 b8

b9 b10 b11 b12 b13 b14 b15 b16

b17 b18 b19 b20 b21 b22 b23 b24

b25 b26 b27 b28 b29 b30 b31 b32

b33 b34 b35 b36 b37 b38 b39 b40

b41 b42 b43 b44 b45 b46 b47 b48

b49 b50 b51 b52 b53 b54 b55 b56

b57 b58 b59 b60 b61 b62 b63 b64

b58 b50 b42 b34 b26 b18 b10 b2

b60 b52 b44 b36 b28 b20 b12 b4

b62 b54 b46 b38 b30 b22 b14 b6

b64 b56 b48 b40 b32 b24 b16 b8

b57 b49 b41 b33 b25 b17 b9 b1

b59 b51 b43 b35 b27 b19 b11 b3

b61 b53 b45 b37 b29 b21 b13 b5

b63 b55 b47 b39 b31 b23 b15 b7

input output

Permutazione iniziale – input e output

– l’input è costituito da 8 ottetti • un ottetto è un gruppo di 8 bit corrispondenti ad una

riga della tabella

– l’output è costituito da 8 ottetti • i bit nel primo ottetto (prima riga) in input vengono

diffusi nell’ottavo bit di ogni ottetto (di ogni riga)

• i bit nel secondo ottetto (seconda riga) in input vengono diffusi nel settimo bit di ogni ottetto (di ogni riga)

• i bit nell’i-esimo ottetto vengono diffusi nel (9-i)-esimo bit di ogni ottetto; i bit in posizione pari vanno nei primi quattro ottetti dell’output, mentre quelli in posizioni dispari negli ultimi quattro

Perché permutare?

• Le permutazioni iniziale e finale di DES non contribuiscono alla sicurezza

– si supponga per assurdo che siano fondamentali

• allora chiamando EDS l’algoritmo ottenuto da DES togliendo tali permutazioni

– EDS deve essere più facile da violare di DES

• supponiamo allora che nota una coppia plaintext, ciphertext EDS sia più facilmente violabile; cioè sia più facile calcolare la chiave KEDS

• mostriamo allora che DES risulta violabile con la stessa facilità

Perché permutare?

• infatti, sia m, c una coppia plaintext, ciphertext di DES

• si consideri allora la coppia m’, c’ ove m’ e c’ sono ottenuti applicando la permutazione iniziale ad m e c

• allora, la chiave KEDS che si ottiene violando EDS per la coppia m’, c’ coincide con la chiave KDES di DES per la coppia m, c

EDS IP IP-1

DES

m m’ c’ c

KEDS (= KDES)

Generazione delle chiavi di round

• DES genera

– sedici chiavi di round da 48 bit a partire dalla chiave principale K di 64 bit nominali, di cui solo 56 effettivi

• i bit di parità di K non vengono considerati

• denoteremo con K1, K2, …, K16 le chiavi di round

• il procedimento è il seguente

– viene prima effettuata una permutazione iniziale sui 56 bit effettivi di K

– i 56 bit in output vengono divisi in due metà C0 e D0

• la permutazione è illustrata nelle slide seguenti

Gen. chiavi – Permutazione iniziale

– il valore numerico di un elemento della tabella rappresenta la posizione del bit in input,

– mentre l’ordine nella tabella rappresenta la posizione del bit in output • ad esempio, il bit più a sx nell’output è ottenuto estraendo il

57-esimo bit della chiave K

• i numeri 8, 16, 24, 32, 40, 48, 56, 64 non sono presenti perché corrispondono ai bit di parità della chiave

57 49 41 33 25 17 9

1 58 50 42 34 26 18

10 2 59 51 43 35 27

19 11 3 60 52 44 36

63 55 47 39 31 23 15

7 62 54 46 38 30 22

14 6 61 53 45 37 29

21 13 5 28 20 12 4

C0 D0


b1 b2 b3 b4 b5 b6 b7

b9 b10 b11 b12 b13 b14 b15

b17 b18 b19 b20 b21 b22 b23

b25 b26 b27 b28 b29 b30 b31

b33 b34 b35 b36 b37 b38 b39

b41 b42 b43 b44 b45 b46 b47

b49 b50 b51 b52 b53 b54 b55

b57 b58 b59 b60 b61 b62 b63

b57 b49 b41 b33 b25 b17 b9

b1 b58 b50 b42 b34 b26 b18

b10 b2 b59 b51 b43 b35 b27

b19 b11 b3 b60 b52 b44 b36

b63 b55 b47 b39 b31 b23 b15

b7 b62 b54 b46 b38 b30 b22

b14 b6 b61 b53 b45 b37 b29

b21 b13 b5 b28 b20 b12 b4

input output


• La permutazione “non è random” – nel senso che presenta delle regolarità evidenti

– come nel caso delle permutazioni dei dati anche le permutazioni iniziale e finale dei bit della chiave K NON contribuiscono alla sicurezza!

Generazione chiavi: i-esimo round

• Le sedici chiavi vengono generate in sedici round

– nell’i-esimo round viene generata la chiave di round Ki

generazione di Ki: round i


• i bit delle due metà Ci-1 Di-1 della (i-1)-esima chiave Ki-1 vengono ruotati (traslazione ciclica) a sx – l’entità della traslazione a sx dipende dal round

• nei round 1, 2, 9 e 16 si ha una rotazione a sx di un solo bit; il primo bit diventa l’ultimo bit a dx

• negli altri round si ha una rotazione a sx di due bit

• la permutazione di Ci che produce la metà sx di Ki è illustrata sotto – si noti che i bit in posizione 9, 18, 22, e 25 sono scartati

14 17 11 24 1 5

3 28 15 6 21 10

23 19 12 4 26 8

16 7 27 20 13 2

permutazione per ottenere la metà sx di Ki


• la permutazione di Di-1 ruotato, cioè di Di, che produce la metà dx di Ki è illustrata sotto

– si noti che i bit in posizione 35, 38, 43, e 54 sono scartati; rimangono così 24 bit anziché 28

• ciascuna delle metà di Ki è di 24 bit complessivamente Ki ha una lunghezza di 48 bit

14 17 11 24 1 5

3 28 15 6 21 10

23 19 12 4 26 8

16 7 27 20 13 2

permutazione per ottenere la metà dx di Ki

Un round di DES


n-esimo round di DES

• CIFRATURA (ENCRYPTION)

– i 64 bit in input sono divisi in due metà da 32 bit

• Ln: metà sx dopo l’(n-1)-esimo round

• Rn: metà dx dopo l’(n-1)-esimo round

– l’output di 64 bit del round si ottiene concatenando le due metà

• Ln+1: metà sx dopo l’n-esimo round

• Rn+1: metà dx dopo l’n-esimo round

– Ln+1 è semplicemente Rn


– Rn+1 è ottenuto come segue

• Rn e Kn sono posti in input alla mangler function; la mangler function viene anche detta funzione di Feistel

• l’output della mangler function, mangler(Rn, Kn), è una quantità di 32 bit; si noti che Rn e Kn sono composti da 32 e 48 bit rispettivamente

• l’output mangler(Rn, Kn) viene poi sommato (XOR ) con Ln

• il risultato ottenuto è Rn+1 = mangler(Rn, Kn) Ln


– si noti che ogni round di DES è facilmente invertibile

• noti Ln+1, Rn+1 e Kn è facile ottenere Ln e Rn

• infatti, Rn = Ln+1, ed essendo

• Rn+1 = mangler(Rn, Kn) Ln risulta che

• Rn+1 mangler(Rn, Kn) = Ln (si noti che x y y = x)

• cioè Ln = Rn+1 mangler(Ln+1, Kn)

– la mangler function non è mai usata in senso inverso

• DES è elegantemente progettato da essere invertibile senza richiedere l’invertibilità della mangler function


• DECIFRATURA (DECRYPTION)

– esaminando attentamente la figura,

– si evince che la decifratura è di fatto identica alla cifratura,

– tranne il fatto che le due metà da 32 bit sono invertite

• in altre parole, fornendo Rn+1|Ln+1 in input al round n si ottiene Rn|Ln in uscita

Mangler Function o funzione di Feistel

Rn

Ȓn

Ȓn,7 Ȓn,8

Kn

Kn,1 Kn,2 Kn,7 Kn,8

+

SB2 SB1 SB7 SB8

+

+ +

Ȓn+1

R’n+1

Ȓn,1 Ȓn,2

Ȓn+1,1 Ȓn+1,2 Ȓn+1,7 Ȓn+1,8

Mangler Function o funzione di Feistel

• La mangler function prende in input – i 32 bit di Rn, o R per semplificare – i 48 bit della chiave Kn, o K per semplificare

• e produce un output da 32 bit – che sommato ( XOR) con Ln permette di ottenere Rn+1 (il

prossimo R)

• la prima operazione è l’espansione di R, da 32 bit a 48 bit – R è scomposto in otto pezzi da 4 bit R = {r1, r2, …, r8} – l’i-esimo pezzo ri viene espanso a 6 bit aggiungendo in

testa e in coda rispettivamente l’ultimo bit di ri-1 e il primo bit di ri+1

– r1 e r8 sono considerati adiacenti, cioè r0 = r8 e r9 = r1

Espansione di R (Rn) a 48 bit

R a 32 bit

Ȓ a 48 bit

chunk 1 di R

espanso

chunk 2 di R

espanso

chunk 3 di R

espanso

chunk 4 di R

espanso

chunk 5 di R

espanso

chunk 6 di R

espanso

chunk 7 di R

espanso

chunk 8 di R

espanso

Mangler Function – S-box

– la chiave K (Kn) viene scomposta in otto chunk (pezzi) da 6 bit

– l’i-esimo chunk di R (Rn) espanso viene sommato ( XOR) all’i-esimo chunk di K

– l’output a 6 bit ottenuto viene sottoposto ad una sostituzione S-box che produce un output di 4 bit

• ci sono in tutto otto S-box distinte; l’i-esima S-box elabora la somma dell’i-esimo chunk di K e di R

• ogni S-box ha 64 possibili input e 16 possibili output

• input diversi possono essere mappati nello stesso output

• le S-box sono definite in modo tale che esattamente quattro input distinti sono mappati in ciascun output possibile

Mangler Function – S-box

• ogni S-box può riguardarsi come quattro S-box separate aventi 4 bit sia in input che in output

• i quattro bit in input corrispondono ai bit interni (dal secondo al quinto) dell’input globale, e

• i due bit esterni (primo e sesto) dell’input globale servono a selezionare quale dei quattro output ottenuti rappresenta l’output globale

• Nelle slide seguenti sono illustrate la tabelle che definiscono le otto S-box

Mangler function – Funzione di Fiestel

Tabella di output di S-box 1

• L’output (a 4 bit) di S-box 1, specifica i primi quattro bit dell’output della mangler function – l’outpout y1y2y3y4 è espresso dai quattro bit riportati

nelle varie celle della tabella – l’input x1x2x3x4x5x6 è espresso

• dai quattro bit interni x2x3x4x5 riportati nelle intestazioni delle colonne, e

• dai due bit esterni x1x6 riportati nelle intestazioni di righe

Tabelle di S-box 2, S-box 3 e S-box 4

Tabelle di S-box 5, S-box 6 e S-box 7

Tabella di S-box 8

Permutazione dell’output dell’S-box

• Gli otto output, da 4 bit, delle otto S-box sono riuniti in un unico output a 32 bit che viene sottoposto ad una permutazione – tale permutazione aumenta il livello di sicurezza

perché le sostituzioni fatte in ciascuna S-box in un round di DES vengono diffuse negli input di più S-box nel round seguente • senza tale permutazione, un bit nella parte sx dell’input

influenzerebbe principalmente alcuni bit della parte sx dell’output

• la permutazione è illustrata sotto; il primo bit in output si ottiene da 16-esimo bit in input, e così via

Chiavi deboli e semi-deboli

• Ci sono sedici chiavi DES il cui utilizzo è sconsigliato

– hanno delle proprietà strane

– tuttavia la probabilità di generarne una randomicamente è 16/256

– è anche sconsigliato usare chiavi DES aventi un valore (interpretate come intero) pari a qualche migliaia

• un avversario potrebbe tentare una ricerca esaustiva a partire da 0 incrementando ogni volta di 1


• Le sedici chiavi sospette si ottengono combinando le quattro configurazioni base di C0 e D0

– a) tutti 1 b) tutti 0 c) 1 e 0 alternati d) 0 e 1 alternati

– quattro di queste corrispondono alle chiavi deboli • quelle che combinano le configurazioni a) e b)

– le rimanenti dodici corrispondono alle chiavi semi-deboli

1111 ∙∙∙ 1111 1111 ∙∙∙ 1111

0000 ∙∙∙ 0000 0000 ∙∙∙ 0000

1010 ∙∙∙ 1010 1010 ∙∙∙ 1010

0101 ∙∙∙ 0101 0101 ∙∙∙ 0101

C0 D0

4 combinazioni

4 chiavi deboli 16 combinazioni

16 chiavi sospette


• Due chiave sono inverse se cifrare con una equivale a decifrare con l’altra – E(K1, m) = D(K1

-1, m)

– E(K1-1, m) = D(K1, m)

• Ogni chiave debole coincide con la propria inversa

• L’inversa di una chiave semi-debole è un’altra chiave semi-debole

Cosa c’è di speciale in DES?

• DES è un algoritmo semplice

– ciò induce a pensare che ognuno può sviluppare un algoritmo di cifratura a chiave segreta!

• basta prendere i bit, fare qualche sostituzione, qualche mescolamento, ripetere più volte ed ecco l’algoritmo!

– in realtà ci sono molti misteri da comprendere

• come si è giunti alle definizioni delle S-box?

• è stato provato che invertendo la S-box 3 con la S-box 7 DES è un ordine di grandezza più insicuro per alcuni attacchi specifici

Segretezza del processo di progettazione

• Il processo di progettazione di DES non fu reso pubblico non si sa se alcuni dettagli progettuali/implementativi – sono stati voluti per aumentare la sicurezza, o – sono puramente casuali, o – sono stati apportati per renderlo vulnerabile a particolari

attacchi noti solo ai progettisti

• Si dice che il processo di progettazione di DES fu mantenuto segreto perché si basava su una attenta analisi di molti tipi di attacchi crittografici – DES fu progettato per resistere a molti tipi di attacchi

crittografici – rendere pubblico il processo di progettazione implicava

divulgare anche le varie tipologie di attacchi

ALGORITMO IDEA INTERNATIONAL DATA ENCRYPTION ALGORITHM


International Data Encryption Algorithm (IDEA)

• IDEA, originariamente chiamato IPES (Improved Proposed Encryption Standard), fu pubblicato nel 1991

• Fu progettato per consentire una implementazione software computazionalmente efficiente

• IDEA prende in input blocchi di testo in chiaro da 64 bit e produce in output blocchi di testo cifrato da 64 bit

• La chiave ha una lunghezza di 128 bit

• IDEA per molti aspetti somiglia a DES – opera in più round

– entrambi hanno una complicata mangler function che non è sottoposta al vincolo di invertibilità generalmente richiesto per permettere la decifratura

International Data Encryption Algorithm (IDEA)

– la mangler function viene sempre eseguita nella stessa direzione sia in cifratura che in decifratura

• DES e IDEA hanno entrambi la proprietà che la cifratura e la decifratura sono identiche tranne che per l’espansione della chiave

• in DES, le stesse chiavi sono usate in ordine inverso

• in IDEA, il legame tra le chiavi di cifratura e di decifratura è più complesso

Struttura base di IDEA

Operazioni primitive

• Ogni operazione primitiva in IDEA mappa

– due quantità di 16 bit in input

– in una quantità di 16 bit in output

• mentre ogni S-box di DES mappa una quantità di 6 bit in input in una di 4 bit in output

• IDEA usa tre operazioni, tutte facilmente calcolabili in software, per creare la biiezione che specifica la cifratura

– tutte e tre le operazioni sono invertibili, cosa importante per eseguire IDEA all’indietro (decifratura)


• Le tre operazioni primitive sono – or-esclusivo (XOR ) bit a bit

– un’addizione (+) leggermente modificata (mod 216)

– una moltiplicazione () leggermente modificata (mod (216 + 1))

X = x1x2∙∙∙x16

Y = y1y2∙∙∙y16

Z = z1z2∙∙∙z16

X = x1x2∙∙∙x16

Y = y1y2∙∙∙y16

Z = z1z2∙∙∙z16

X = x1x2∙∙∙x16

Y = y1y2∙∙∙y16

Z = z1z2∙∙∙z16


• la ragione che non consente di utilizzare l’addizione e la moltiplicazione tradizionale è che il risultato è a 16 bit e possono esserci situazioni di overflow dato che anche gli input sono a 16 bit

• l’addizione in IDEA consista semplicemente in una somma binaria in cui si trascura il riporto finale; ciò equivale a dire che si tratta di un’addizione mod 216

• la moltiplicazione in IDEA si ottiene calcolando prima il risultato a 32 bit, e prendendo poi il resto della divisione per 216 + 1; con un po’ di “furbizia” ciò è fattibile in modo efficiente


• la moltiplicazione mod (216 + 1) è invertibile, nel senso che ogni numero x tra 1 e 216 ha un inverso y (cioè un numero tra 1 e 216 tale che la moltiplicazione per y “annulla” l’effetto della moltiplicazione per x: a risulta a ∙ x ∙ y = a), poiché 216 + 1 è un numero primo

• tuttavia c’è una piccola “furbata”, il numero 0, che può essere espresso con 16 bit, non avrebbe un inverso,

• mentre il numero 216, presente nell’insieme delle classi di resto modulo 216 + 1, non è esprimibile con 16 bit,

• entrambi i problemi sono risolti considerando 0 come la codifica di 216

Invertibilità delle operazioni primitive

• Come è possibile invertire le tre operazioni primitive?

– chiaramente non si tratta di un’inversione che permette di risalire ai due operandi a partire dal solo risultato finale!

• se X Y = Z, non è possibile risalire ad X e ad Y a partire dal solo Z,

• tuttavia, nell’esecuzione all’indietro di IDEA saranno noti un operando e il risultato, diciamo Y e Z, e da questi sarà possibile ottenere X


– Si consideri l’operazione generica X op Y = Z e si supponga di conoscere Y e Z,

– allora per ciascuna delle tre operazioni primitive,

– X è ottenibile come segue

• Inversione or-esclusivo (XOR ) bit a bit – se X Y = Z X Y Y = Z Y X = Z Y

• rispetto all’operazione ogni numero è l’inverso di se stesso; Y Y = 0


• Inversione addizione (mod 216) (+) – se X + Y (mod 216) = Z

X + Y + (-Y)(mod 216) = Z + (-Y) (mod 216)

X = Z + (-Y) (mod 216) • rispetto all’operazione + l’inverso di un numero Y è il numero

-Y (mod 216)

• Inversione moltiplicazione (mod 216 + 1) () – se X Y (mod (216 + 1)) = Z

– X Y Y-1(mod (216 + 1)) = Z Y-1(mod (216 + 1))

– X = Z Y-1(mod (216 + 1)) • Y-1(mod (216 + 1)) è ottenibile con il l’algoritmo di Euclide


• L’unica parte di IDEA che non è necessariamente invertibile è la mangler function

• La gestione del progetto di IDEA è stata molto ingegnosa per evitare la necessità di invertire la mangler function

Espansione delle chiavi

• La chiave di 128 bit è espansa in 52 chiavi da 16 bit, K1, K2, …, K52

– l’espansione per la cifratura è diversa da quella per la decifratura

– cifratura e decifratura coinciderebbero se non fosse per le chiavi che differiscono

• sia per l’ordine,

• sia per il valore delle chiavi usate nei round dispari

Espansione della chiave (cifratura)

• La chiave di 128 bit è espansa in 52 chiavi da 16 bit, K1, K2, …, K52 – la procedura è come segue

• le prime otto chiavi K1, K2, …, K8 sono ottenute spezzando la chiave da 128 bit in corrispondenza dei bit in posizione 16∙1, 16∙2, …, 16∙7

• le successive otto chiavi K9, K10, …, K16 sono generate allo stesso modo, ma partendo dal bit in posizione 25 e tornando all’inizio quando si arriva alla fine (scansione ciclica)

• le successive otto chiavi sono generate considerando 25 bit di offset in più e così via finché non si ottengono 52 chiavi


• si noti che in 6 fasi vengono generate 48 chiavi e in 7 fasi 52 nell’ultima fase, la settima, sono generate solo 4 chiavi

• l’ultima fase inizia dal bit in posizione 23 e si estende fino al bit in posizione 86 i bit in posizione da 1 a 22 e da 87 a 128 sono usati una volta in meno rispetto quelli in posizione da 83 a 128


generazione delle chiavi K1, K2, …, K8

generazione delle chiavi K9, K10, …, K16


– la generazione delle 52 chiavi di decifratura sarà illustrata nel seguito

– WARNING!

• nello standard IDEA c’è una piccola stranezza: le chiavi K50 e K51 sono invertite!

• probabilmente c’è stata una svista nella definizione dello standard!

• se si desidera implementare IDEA è necessario, dopo aver generato le 52 chiavi di cifratura, provvedere ad invertire K50 e K51

IDEA – un round

• IDEA esegue 17 round

– i round dispari sono diversi da quelli pari

• in alcuni casi si parla di 8 round; due round vengono considerati come un singolo round

– l’input di ogni round è una quantità X a 64 bit separata in quattro quantità Xa, Xb, Xc, Xd da 16 bit

• cioè X = Xa | Xb | Xc | Xd

– ad ogni round l’input Xa | Xb | Xc | Xd viene combinato con alcune delle 52 chiavi per ottenere in output una versione aggiornata di Xa | Xb | Xc | Xd

• i round dispari usano quattro delle 52 chiavi Ki: Ka, Kb, Kc, Kd

• i round pari usano due delle 52 chiavi Ki: Ke, Kf

IDEA – un round

– Ad esempio • nel round 1, Ka, Kb, Kc, Kd = K1, K2, K3, K4

• nel round 2, Ke, Kf = K5, K6

• nel round 3, Ka, Kb, Kc, Kd = K7, K8, K9, K10

• nel round 4, Ke, Kf = K11, K12

• ∙∙∙

– in un round dispari gli input sono • Xa, Xb, Xc, Xd

• Ka, Kb, Kc, Kd

– in un round pari gli input sono • Xa, Xb, Xc, Xd

• Ke, Kf

Round dispari

• Il round dispari è semplice – Xa Xa Ka

– Xd Xd Kd

– Xc Xb + Kb

– Xb Xc + Kc

Round dispari

• Si osservi che un round dispari è facilmente invertibile – il vecchio Xa si ottiene moltiplicando () il nuovo Xa per

l’inverso moltiplicativo mod (216 + 1) di Ka

– analogamente si procede con Xd

– il vecchio Xb si ottiene sommando al nuovo Xc l’inverso additivo di Kb, cioè sottraendo Kb

– analogamente si procede con Xc

• in fase di decifratura – il round dispari è analogo alla cifratura, tranne il fatto di

dover considerare per ogni chiave il suo inverso matematico (rispetto le relative operazioni) • ciò “annulla” le operazioni fatte nella fase di cifratura

Round pari

• Il round pari è più complicato

– gli input sono Xa, Xb, Xc, Xd e Ke, Kf – prima vengono calcolate due quantità (a 16 bit)

Yin e Zin

– poi viene applicata una funzione, la mangler function, che

• prende in input Yin, Zin, Ke e Kf, e

• produce in output due quantità (a 16 bit) Yout e Zout

– in fine, vengono calcolati

• i nuovi valori di Xa, Xb, Xc, Xd combinando

• i loro vecchi valori con Yout e Zout

Round pari

• In particolare, si hanno le seguenti relazioni – Yin = Xa Xb

– Zin = Xc Xd

– Yout = ((Ke Yin) + Zin) Kf

– Zout = (Ke Yin) + Yout

• i nuovi valori di Xa, Xb, Xc, Xd sono – Xa Xa Yout

– Xb Xb Yout

– Xc Xc Zout

– Xd Xd Zout

Round pari

Inversione del round pari

• l’inversione del round pari è veramente ingegnosa

– il round pari coincide con il suo inverso

– la decifratura di un round pari usa le stesse chiavi e non il loro inverso matematico • nella decifratura dei round dispari si considerava un set

di chiavi ottenuto facendo l’inverso matematico delle chiavi di cifratura

– il round pari prende in input • Xa, Xb, Xc, Xd e

• Ke, Kf

– e produce in output • X’a, X’b, X’c, X’d cioè i nuovi valori di Xa, Xb, Xc, Xd

Inversione del round pari

– risulta che (sarà mostrato dopo)

• se gli input del round pari sono X’a, X’b, X’c, X’d, e

• le chiavi rimangono le stesse,

• l’output è Xa, Xb, Xc, Xd

Xa Xb Xc Xd

X’a X’b X’c X’d

Ke

Kf

round 2n ENCRYPTION

X’a X’b X’c X’d

Xa Xb Xc Xd

round 2n DECRYPTION

Inversione del round pari – prova

• Mostreremo che – inserendo in input al round pari X’a, X’b, X’c, X’d, e

– considerando le stesse chiavi Ke, Kf

– si ottengono in output X’’a, X’’b, X’’c, X’’d tali che • X’’a = Xa X’’b = Xb X’’c = Xc X’’d = Xd

– Prova

• da X’a = Xa Yout e da X’b = Xb Yout

• Y’in = X’a X’b = (Xa Yout) (Xb Yout) = Xa Xb = Yin

• da X’c = Xc Zout e da X’d = Xd Zout

• Z’in = X’c X’d = (Xc Zout) (Xd Zout) = Xc Xd = Zin

Inversione del round pari – prova

– gli input della mangler function sono gli stessi

– Y’out = Yout e Z’out = Zout

– X’’a = X’a Y’out = (Xa Yout) Y’out =

= Xa Yout Yout = Xa

– X’’b = X’b Y’out = (Xb Yout) Y’out =

= Xb Yout Yout = Xb

– X’’c = X’c Z’out = (Xc Zout) Z’out =

= Xc Zout Zout = Xc

– X’’d = X’d Z’out = (Xd Zout) Z’out =

= Xd Zout Zout = Xd

Calcolo chiavi di decifratura

• IDEA è stato progettato in modo tale che lo stesso codice (o hardware) può effettuare sia la cifratura che la decifratura – scegliendo in modo opportuno (diversamente) le 52

chiavi espanse per la cifratura e per la decifratura

– si possono scegliere la chiavi inverse (di decifratura) in modo tale che la procedura di cifratura, così come è, esegue anche la decifratura

– l’idea base è di prendere le inverse (dal punto di vista matematico) delle chiavi di cifratura e usarle in ordine opposto


• Si considerino le 52 chiavi usate in cifratura K1, K2, …, K52

– nei round dispari sono state usate quattro chiavi mentre nei round pari solo due • round 1 K1, K2, K3, K4

• round 3 K7, K8, K9, K10

• ∙∙∙

• round 17 K49, K50, K51, K52

– quindi le prime quattro chiavi da usare nel primo round di decifratura devono essere • K’1 : inverso matematico di K49; trattandosi di una moltiplicazione

() K’1 deve essere l’inverso moltiplicativo di K49 mod (216 + 1) • K’2 : inverso additivo di K50; cioè -K50

• K’3 : inverso additivo di K51 ; cioè -K51

• K’4 : inverso moltiplicativo di K52


– considerando la seguente notazione

• im(Ki): inverso moltiplicativo di Ki mod (216 + 1)

• ia(Ki): inverso additivo di Ki mod 216

– le 52 chiavi di decifratura K’i sono

• round 1: K’1, K’2, K’3, K’4 = im(K49), ia(K50), ia(K51), im(K52)

• round 2: K’5, K’6 = K47, K48


• round 4: K’11, K’12 = K41, K42

• …


Architettura hardware/software

• Da quanto detto, una possibile architettura di un sistema hardware/software per IDEA è la seguente

52 16 bit

input plaintext or ciphertext

output ciphertext or plaintext

ENCRYPTION

KEY EXP

K E/D

K*

128 bit

64 bit 64 bit

E/D true K* = K1, K2, …, K52

E/D false K* = K’1, K’2, …, K’52

Funziona IDEA?

• Si è mostrato che nota la chiave di cifratura la decifratura consente di risalire al testo in chiaro

• Riguardo il livello di sicurezza offerto da IDEA

– non esistono prove formali che stabiliscono in modo chiaro quanto IDEA sia sicuro

– si assume che sia sicuro semplicemente perché ancora nessuno ha reso pubblico un modo per violarlo

– chiaramente, tentare di violare IDEA con un approccio esaustivo richiede attualmente una quantità smisurata di risorse di calcolo/tempo

ALGORITMO AES ADVANCED ENCRYPTION STANDARD


Advanced Encryption Standard (AES)

• AES fu introdotto perché – DES aveva una chiave troppo corta

– 3DES (triplo DES) era troppo lento

– IDEA era protetto da un brevetto, era in parte sospetto e lento

• Il NIST si impegnò a sviluppare un nuovo standard – non si trattava di un problema solo tecnico, ma

– anche di un problema politico • alcuni rami del governo avevano ostacolato il più possibile la

diffusione e l’esportazione della crittografia sicura

• il fatto che il governo appoggiasse NIST era visto con scetticismo; molti non si fidavano

Un po’ di storia

• Il NIST voleva realmente creare un nuovo standard di sicurezza eccellente

– cioè efficiente, flessibile, sicuro e free (non protetto), ma quale poteva essere il modo migliore per farlo?

• da un lato NIST doveva essere parte integrante del processo di progettazione

• poiché si trattava di uno sforzo ingente e sembrava che nessun altro avesse le competenze tecniche e l’energia per compierlo

• dall’altro proporre un cifrario sviluppato, segretamente, dalla NSA non avrebbe funzionato; nessuno si sarebbe fidato, ci potevano essere delle trapdoor

Un po’ di storia

• Nel 1997 il NIST annunciò una gara per la selezione di un nuovo standard di cifratura – destinato a proteggere informazioni governative

sensibili

– la gara era aperta ad ogni persona/gruppo in qualsiasi parte del mondo

– furono specificati i requisiti del cifrario incluso una documentazione che spiegasse le ragioni delle scelte progettuali • per molti anni si tennero delle conferenze per la

presentazione di proposte,

• che venivano sottoposte a cicli di revisione eseguiti da crittografi esperti e motivati

Un po’ di storia

• Dopo molti anni di studio e discussioni, il NIST scelse l’algoritmo Rijndael – proposto da due crittografi belgi Joan Daemen e

Vincet Rijmen

– Rijndael prevede diverse lunghezze per i blocchi e per la chiave • 128, 160, 192, 224, e 256 bit

• la lunghezza di un blocco e quella della chiave possono differire

• Il 26 Novembre 2001, viene emanato AES – una standardizzazione di Rijndael

Un po’ di storia

• Lo standard AES – fissa la lunghezza dei blocchi a 128 bit

– la chiave può essere di 128, di 192 o di 256 bit • si parla di AES-128, AES-192 e AES-256

• Nel seguito si descriverà Rijndael – specificando di volta in volta i parametri di AES

– Rijndael somiglia a DES e a IDEA • ci sono più round che “strapazzano” un blocco di testo

in chiaro per ottenere il corrispondente cifrato, e

• c’è un algoritmo per l’espansione della chiave; a partire dalla chiave segreta genera le chiavi da usare nei vari round

Rijndael/AES – parametri

• Rijndael ha una struttura flessibile grazie all’uso di due parametri indipendenti, e di un terzo parametro derivato dai primi due

– Nb dimensione di un blocco: numero di parole (word) da 32 bit (colonne da 4 ottetti) in un blocco da cifrare

• in AES Nb = 4, un blocco ha lunghezza 128 bit 4 parole da 32 bit; 4 colonne da 4 ottetti

ottetto

Nb


– Nk dimensione della chiave: numero di parole (word) da 32 bit (colonne da 4 ottetti) in una chiave di cifratura

• in AES-128 Nk = 4

• in AES-192 Nk = 6

• in AES-256 Nk = 8

• in Rijndael Nk può essere un qualsiasi intero tra 4 e 8

ottetto

NK


– Nr numero di round: questo parametro dipende da Nb e da Nk

• più lunga è la chiave più round sono necessari per rendere la violazione della cifratura difficile quanto un attacco a forza bruta sulla chiave

• il numero di round deve aumentare all’aumentare della lunghezza di un blocco (e della chiave); ogni bit del testo in chiaro (e della chiave) deve influenzare (in modo complesso) ciascun bit del testo cifrato

• Rijndael specifica che Nr = 6 + max(Nb, Nk)

• in AES-128 Nr = 10

• in AES-192 Nr = 12

• in AES-256 Nr = 14

Array di stato

• Rijndael mantiene un array di stato rettangolare

– ogni elemento dell’array è un ottetto

– complessivamente ci sono Nb colonne da 4 ottetti

• lo stato iniziale è ottenuto popolando l’array, colonna per colonna, mediante le Nb colonne da 4 ottetti che costituiscono il blocco di input

• durante gli Nr round lo stato viene modificato

• il blocco di output dell’algoritmo si ottiene leggendo colonna per colonna lo stato finale

Array di stato

• Prima del round 1, tra i vari round, e dopo il round Nr viene eseguito

– l’or-esclusivo ( XOR) del contenuto dell’array di stato, con

– i prossimi 4∙Nb ottetti della chiave espansa

• gli ottetti della chiave espansa vengono letti per colonna in modo da formare un matrice di Nb colonne da 4 ottetti ciascuna

– i primi Nr – 1 round comprendono una sequenza di operazioni identiche, mentre il round Nr ne omette una

Struttura base di Rijndael

Espansione della chiave

• La chiave segreta di Rijndael è un blocco formato da 4∙Nk ottetti

• L’algoritmo di espansione della chiave

– scandisce la chiave in modo da ottenere Nk colonne da 4 ottetti,

– poi espande la matrice ottenuta introducendo delle colonne (da 4 ottetti) aggiuntive,

– l’espansione si arresta quando si hanno complessivamente (Nr + 1)Nb colonne

• l’esatta quantità di chiavi espanse


– la procedura di espansione usa lo stesso tipo di operazioni primitive usate durante i round

• Numerazioni

– righe, colonne, e chiavi di round sono numerate a partire 0

– i round sono invece numerati a partire da 1


• Rijndael utilizza quattro operazioni primitive

1. or-esclusivo (XOR ) • in cui sono coinvolte le chiavi espanse

2. sostituzione di byte, chiamata S-box

• si tratta di una sostituzione ottetto-per-ottetto (byte-per-byte) definita da una specifica tabella

• per ciascuno dei possibili 256 byte in input viene specificato il corrispondente byte in output tra i 256 possibili

• per la rappresentazione della tabella fa comodo usare la notazione esadecimale; ad esempio FC rappresenta il 252-esimo byte

• la tabella può essere visualizzata come una matrice 1616

Rijndael – Sbox

Esempio il 97-esimo byte è il numero 61HEX in esadecimale,

quindi è mappato nel byte nella riga 6 e colonna 1 che è EFHEX che corrisponde al 239-esimo byte in binario si ha che (1100001)2 = (97)10

è mappato in (11101111)2 = (239)10


3. scorrimento circolare di ottetti (byte) di una riga o di una colonna pari a un qualche numero di celle

4. mescolamento colonne, MixColumn: sostituzione di una colonna di 4 ottetti con un’altra colonna di 4 ottetti • MixColumn può essere implementata con una singola tabella

contenente 256 colonne di 4 ottetti • ciascuno dei 4 ottetti in una colonna di input è usato come

un indice per recuperare una colonna dalla tabella • ogni colonna recuperata dalla tabella è ruotata (scorrimento

verticale circolare dall’alto in basso) verticalmente in modo tale che il suo ottetto in cima sia posto nella stessa riga dell’ottetto di input;

• e le quattro colonne ruotate sono sommate XOR () per produrre la colonna di output

MixColumn – mediante tabella di lookup

4 ottetti di una colonna di input

scorrimento della colonna per allinearla all’ottetto di input “ad”

da cui è stata derivata

4 ottetti di una colonna di output

MixColumn – tabella di lookup

Esempio All’ottetto “2b” corrisponde la colonna di 4 ottetti che si trova all’incrocio della riga “2” e della colonna “b”, cioè la colonna “56” “2b” “28” “7d”


• L’or-esclusivo (XOR ) è chiaramente invertibile – coincide con il suo inverso: X Y Y = X

• L’inversa della S-box si ottiene considerando semplicemente una tabella diversa – cioè la tabella inversa

• L’inversa dello scorrimento circolare di una riga o colonna si ottiene semplicemente eseguendo lo stesso scorrimento, ma in direzione opposta

• L’inversa di MixColumn, detta InvMixColumn, è esattamente come MixColumn, ma con una tabella di lookup diversa

Rijndael – S-box inversa

InvMixColumn – tabella di lookup

Decifratura di Rijndael

• Il cifrario inverso di Rijndael può pertanto implementarsi applicando – le inverse delle operazioni primitive,

– eseguite in sequenza opposta rispetto quella di cifratura

• Tuttavia, si può mostrare che, – grazie alle proprietà matematiche di cui gode Rijndael,

– il cifrario inverso ha una struttura molto simile al cifrario diretto, ma con operazioni invertite, e con le chiavi di round non soltanto in ordine inverso, ma

– con InvMixColumn applicato a tutte tranne la prima e l’ultima colonna


• L’espansione delle chiavi – inizia con la chiave segreta organizzata come Nk

colonne di 4 ottetti, e

– iterativamente genera le prossime Nk colonne della chiave espansa


• Per generare l’i-esimo insieme di Nk colonne • i inizia da 1; lo “0-esimo” insieme è la chiave segreta

– serve soltanto l’(i-1)-esimo insieme di colonne

– la prima colonna (colonna 0) del nuovo insieme si ottiene mediante

• uno scorrimento circolare verticale di una cella dell’ultima colonna dell’(i-1)-esimo insieme, e

• applicando la S-box ad ogni ottetto, e

• sommando in XOR () una costante Ci con l’ottetto 0 (che sta in cima)

Espansione della chiave (Nk ≤ 6)

– le rimanenti colonne sono generate a turno

• sommando in XOR la precedente colonna con,

• la corrispondente colonna del precedente (i-1)-esimo insieme

Valori delle costanti Ci

1 2 4 8 10 20 40 80 1b 36

6c d8 ab 4d 9a 2f 5e bc 63 c6

97 35 6a d4 B3 7d fa ef c5 (91)

i = 1 to 10

i = 11 to 20

i = 21 to 30

Espansione della chiave (Nk > 6)

– c’è un’eccezione nel procedimento di espansione della chiave,

– se Nk > 6, allora è necessario uno step aggiuntivo per generare la colonna 4

• è necessario applicare la S-box ad ogni ottetto

– l’espansione della chiave termina non appena (Nr + 1)Nb colonne di chiavi espanse sono generate

Espansione della chiave – Nk > 6

Rijndael – round

– Ogni round di Rijndael è una sequenza identica di tre operazioni:

1. Ogni ottetto della matrice di stato viene sottoposto alla S-box

2. Scorrimenti circolari • La riga 1 dello stato viene fatta scorrere a sx di una colonna

• La riga 2 dello stato viene fatta scorrere a sx di 2 + Nb/8 colonne (2 se Nb < 8, 3 altrimenti)

• La riga 3 dello stato viene fatta scorrere a sx di 3 + Nb/7 colonne (3 se Nb < 7, 4 altrimenti)

(in AES si semplifica in scorrimento a sx di i colonne della riga i)

3. Ogni colonna dello stato viene sottoposta alla MixColumn; il round Nr omette questa operazione

Rijndael – round invertito

• Essendo ogni operazione invertibile – la decifratura può effettuarsi applicando in ordine

inverso l’inversa (in senso matematico) di ogni operazione, e

– usando le chiavi di round in ordine inverso

• Tuttavia la decifratura può avere la stessa struttura della cifratura – è necessario usare le chiavi di round in ordine

opposto, e – applicare InvMixColumn ad ogni colonna delle chiavi

espanse tranne quelle del round iniziale e finale

Rijndael – round invertito

– Ogni round invertito di Rijndael è una sequenza identica di tre operazioni:

1. Ogni ottetto della matrice di stato viene sottoposto alla S-box

2. Scorrimenti circolari • La riga 1 dello stato viene fatta scorrere a dx di una

colonna

• La riga 2 dello stato viene fatta scorrere a dx di 2 + Nb/8 colonne (2 se Nb < 8, 3 altrimenti)

• La riga 3 dello stato viene fatta scorrere a dx di 3 + Nb/7 colonne (3 se Nb < 7, 4 altrimenti)

(in AES si semplifica in scorrimento a dx di i colonne della riga i)

3. Ogni colonna dello stato viene sottoposta alla InvMixColumn; il round Nr omette questa operazione

CIFRARI A FLUSSO E RC4 Crittografia a Chiave Segreta

Cifrari a blocchi vs cifrari a flusso

• Un cifrario a blocchi elabora un blocco di elementi in ingresso per volta – produce un blocco di uscita per ciascun blocco di

ingresso • il testo in chiaro deve essere preliminarmente suddiviso

in blocchi • il testo cifrato si ottiene combinando i vari blocchi cifrati • DES, IDEA e AES sono esempi di cifrari a blocchi simmetrici

• Un cifrario a flusso elabora continuamente gli elementi in ingresso – produce in uscita un “flusso” di elementi cifrati

• gli elementi cifrati vengono prodotti singolarmente, uno alla volta, man mano che la cifratura procede

Cifrari a blocchi vs cifrari a flusso

• Sebbene i cifrari a blocchi siano molto più comuni, in alcune applicazioni i cifrari a flusso sono più adatti – applicazioni che richiedono la cifratura/decifratura di

un flusso di dati • ad esempio le trasmissioni di stream audio/video

– di seguito sarà esaminato il cifrario a flusso più popolare: RC4

– preliminarmente sarà discussa la struttura generale di un cifrario a flusso

Struttura di un cifrario a flusso

• Un tipico cifrario a flusso cifra il testo in chiaro un byte per volta – sebbene possa essere progettato per agire su unità

più grandi di un byte

pseudo-random stream gener.

pseudo-random stream gener.

K K

plaintext stream

plaintext stream

ciphertext stream


keystream keystream

Struttura di un cifrario a flusso

• La chiave segreta K (di lunghezza finita) è l’ingresso di un generatore pseudo-casuale di bit – che produce un flusso (di lunghezza arbitraria) di

byte apparentemente casuale, chiamato chiave di flusso (keystream)

• la chiave di flusso è un flusso – “impredicibile” se non si conosce la chiave, ma

viene generato in modo deterministico a partire dalla chiave

– non presenta regolarità statistiche

Cifratura

• Il keystream è combinato un byte alla volta con il flusso del testo in chiaro mediante un or-esclusivo (XOR ) bit a bit

– il risultato di questo processo è il flusso cifrato

– ad esempio, se

• pi = 11001100 è l’i-esimo byte del flusso del testo in chiaro, e

• ki = 01101100 è l’i-esimo byte del keystream, allora

• ci = pi ki = 10100000 è l’i-esimo byte del flusso del testo cifrato

Decifratura

• La decifratura richiede l’uso della stessa sequenza pseudo-casuale (keystream)

– combinata un byte alla volta con il testo cifrato mediante or-esclusivo (EX-OR ) bit a bit

– ad esempio, se

• ci = pi ki = 10100000 è l’i-esimo byte del flusso del testo cifrato, e

• ki = 01101100 è l’i-esimo byte del keystream, allora

• pi = ci ki = (pi ki) ki = pi (ki ki) = pi = 11001100 è l’i-esimo byte del flusso del testo in chiaro

Osservazioni

• Più è casuale l’aspetto del keystream, più è randomizzato il testo cifrato – rendendo la crittoanalisi più difficile

• Pertanto il keystream – dovrebbe avere un periodo grande

• la funzione deterministica che genera il keystream, a partire dalla chiave segreta, è per forza di cose periodica

– dovrebbe approssimare il più possibile un flusso casuale • ad esempio, 0 e 1 dovrebbero essere equamente presenti

• riguardando il keystream come una sequenza di byte, tutti i 256 possibili byte dovrebbero apparire “disordinatamente” e con una frequenza uniforme

Osservazioni

• Come nei cifrari a blocchi, è necessario che la chiave sia sufficientemente lunga per proteggersi dagli attacchi a forza bruta

– è preferibile una lunghezza della chiave di almeno 128 bit

Cifrari a flusso vs cifrari a blocchi

• Se un cifrario a flusso è correttamente progettato

– può essere sicuro tanto quanto un cifrario a blocchi

• a parità di lunghezza della chiave segreta

• Il vantaggio principale di un cifrario a flusso è che

– è quasi sempre più veloce, vedi tabella, ed

– è facilmente implementabile

• spesso bastano poche linee di codice, vedi descrizione RC4


• Confronto delle velocità di cifrari simmetrici su un Pentium II

Cifrario Lunghezza della chiave Velocità variabile (Mbps)

DES 56 9

3DES 168 3

RC2 variabile 0,9

RC4 variabile 45


• Il vantaggio di un cifrario a blocchi è che la chiave segreta è riutilizzabile per più comunicazioni

– se due testi in chiaro sono cifrati con la stessa chiave segreta, usando un cifrario a flusso, la crittoanalisi è spesso molto semplice

– se i due flussi di testo cifrato sono sommati in XOR () il flusso risultante è lo XOR dei flussi di testo in chiaro

• se i testi in chiaro sono stringhe testuali, numeri di carta di credito o altri flussi di byte con proprietà note la crittoanalisi può aver successo

Algoritmo RC4

• RC4 è un cifrario a flusso – con dimensione della chiave variabile,

– con funzionamento orientato al byte

– fu progettato nel 1987 da Ron Rivest – RSA Security

• Si basa sull’uso di una permutazione casuale – dagli studi sembra che il periodo del cifrario sia

superire a 10100

– viene usato • negli standard SSL/TLS (Secure Socket Layer/Transport Layer

Security)

• nel protocollo WEP (Wired Equivalent Privacy)

• nel protocollo WPA (WiFi Protected Access)

Algoritmo RC4

• L’algoritmo RC4 è molto semplice da spiegare; basta spiegare come viene generato il keystream

– l’algoritmo mantiene un array di stato monodimensionale S contenente 256 byte

• S[0], S[1], …, S[255] sono i 256 byte

• ogni elemento/byte S[i] rappresenta un numero da 1 a 255

– una chiave di lunghezza variabile da 1 a 256 byte (da 8 a 2048 bit) viene usata per inizializzare il contenuto dell’array di stato

Algoritmo RC4

– S contiene in ogni momento una delle 256! permutazioni dei numeri da 0 a 255

– per la cifratura/decifratura viene generato un byte k selezionando da S uno dei 255 elementi in maniera sistematica

– subito dopo la generazione del byte k, gli elementi di S vengono permutati

– l’algoritmo prosegue alternando le ultime due fasi (generazione di k e permutazione) finché il flusso in input non termina

RC4 – inizializzazione

– gli elementi di S vengono impostati uguali ai valori da 0 a 255 in ordine crescente • S[0] = 0, S[1] = 1, …, S[255] = 255

– un vettore temporaneo T, della stessa lunghezza di S, viene usato per memorizzare temporaneamente la chiave K • se la lunghezza di K è 256 byte K viene trasferita in T

• altrimenti, K viene copiata più volte in T fino a riempirlo

/* Inizializzazione */

for i = 0 to 255 do {

S[i] = i;

T[i] = K[i mod keylen]; // keylen: lunghezza di S

}

RC4 – permutazione iniziale

– successivamente si userà T per produrre la permutazione iniziale • si scandisce S e per ciascun S[i], si scambia S[i] con un

altro elemento di S scelto in modo sistematico in base, tra l’altro, al contenuto di T[i]

– poiché la sola operazione su S è lo scambio, il solo effetto è una permutazione • S contiene ancora tutti i numeri da 0 a 255

/* Permutazione iniziale di S */

j = 0;

for i = 0 to 255 do {

j = (j + S[i] + T[i]) mod 256;

scambia(S[i], S[j]);

}

RC4 – generazione del flusso

• Una volta che S è inizializzato, la chiave segreta K (quindi anche l’array T) non viene più utilizzata – il keystream viene generato facendo una

scansione ciclica di S • ciascun elemento S[i] viene scambiato con un altro byte

di S a secondo di uno schema che dipende dalla configurazione corrente di S

• dopodiché, viene generato un singolo byte k del keystream sempre in base alla configurazione corrente di S

RC4 – generazione del flusso /* Generazione del flusso */

i, j = 0;

while (true) {

i = (i + 1) mod 256;

j = (j + S[i]) mod 256;

scambia(S[i], S[j]);

t = (S[i] + S[j]) mod 256;

k = S[t];

}

Bibliografia




• [Wiki-it] http://it.wikipedia.org/wiki/ • [Wiki-en] http://en.wikipedia.org/wiki/ • [ISECOM] Institute for Security and Open

Methodologies

Modalità Operative dei Cifrari a Blocchi

(Modes of Operation)

Luca Grilli

INTRODUZIONE Modalità Operative dei Cifrari a Blocchi

Introduzione

• Si illustrerà come usare gli algoritmi di crittografia a chiave segreta, DES, IDEA e AES, in applicazioni reali – è stato visto soltanto come usare tali algoritmi per

cifrare blocchi di lunghezza prefissata • 64 bit per DES e IDEA

• 128 bit per AES

– come si procede se è necessario cifrare dei messaggi di lunghezza arbitraria/diversa?

• Si vedrà inoltre come si generano dei MAC (Message Authentication Code) – sfruttando la crittografia a chiave segreta

CIFRARE MESSAGGI DI GRANDI DIMENSIONI


Cifrare messaggi di grandi dimensioni

• Come è possibile cifrare messaggi di dimensioni superiori a 64 bit? – Sono state proposte diverse modalità operative dei

cifrari a blocchi • cioè come utilizzare i cifrari a blocchi nel caso di messaggi di

lunghezza maggiore di quella di un singolo blocco

• le modalità più conosciute e che verranno descritte di seguito sono – Electronic Code Book (ECB)

– Cipher Block Chaining (CBC)

– k-Bit Cipher FeedBack Mode (CFB)

– k-Bit Output FeedBack Mode (OFB)

Cifrare messaggi di grandi dimensioni

• una modalità operativa più recente, che potrebbe essere importante in futuro, è il

– CounTeR Mode (CTR)

– nelle prossime slide, si farà riferimento a cifrari a blocchi con blocchi di 64 bit

• tutte le considerazioni valgono anche nel casi di cifrari con blocchi di dimensione diversa da 64 bit

Electronic Code Book (ECB)

• questa modalità consiste nel fare la cosa più ovvia; corrisponde, in genere, alla soluzione peggiore

– il messaggio viene decomposto in blocchi da 64 bit • inserendo eventualmente dei bit di padding nell’ultimo

blocco al fine di riempirlo

– ciascun blocco da 64 bit viene cifrato con la chiave segreta

– la decifratura, consiste nel decifrare ciascun blocco cifrato, e

– nel ricomporre il messaggio in chiaro a partire dai singoli blocchi decifrati

Electronic Code Book (ECB) ELECTRONIC CODE BOOK ENCRYPTION

ELECTRONIC CODE BOOK DECRYPTION

Problemi di sicurezza in ECB

• La modalità operativa ECB introduce una serie di problemi non presenti nel cifrario a blocchi

– se il messaggio contiene due blocchi di 64 bit identici anche i corrispondenti blocchi cifrati saranno identici

• ciò fornisce delle informazioni aggiuntive sul testo in chiaro che un ascoltatore può sfruttare

• ad esempio, supponiamo che l'ascoltatore sappia che il testo in chiaro contiene l'elenco, ordinato alfabeticamente, degli impiegati e dei relativi salari inviato dall'amministrazione all'ufficio paghe

File con i salari

Cognome Nome Posizione Salario (€)

Bianchi Walter Impiegato 18.000,00

Neri Marcello Top Manager 70.000,00

Rossi Carlo Project Manager 40.000,00

Verdi Dario Tecnico 25.000,00

Viola Saverio Presidente 120.000,00

suddivisione in blocchi


• supponiamo inoltre che ogni riga del file sia lunga esattamente 64 byte (8 blocchi da 8 byte), e

• che i vari blocchi risultino suddivisi in modo tale che alcuni contengono la codifica della cifra decimale più significativa del campo salario; migliaia di dollari/euro

• comparando i testi cifrati, l’ascoltatore oltre a dedurre quanti dipendenti hanno lo stesso salario, può anche dedurre quanti dipendenti hanno uno stipendio nello stesso range (ordine di 10€ dollari)

• se ci sono complessivamente pochi range salariali, l’ascoltatore può dedurre a quale categoria di dipendente corrisponda un dato blocco cifrato


• inoltre, se l’ascoltatore è un impiegato, può sostituire il blocco cifrato di un altro dipendente (un manager) al suo blocco cifrato (dedotto in base all’ordine e alla numerosità della sua classe salariale)

– ECB ha due serie debolezze

• qualcuno analizzando diversi blocchi cifrati potrebbe dedurre (inferire) informazioni sfruttando le ripetizioni di alcuni blocchi cifrati, e/o

• potrebbe riarrangiare/modificare i blocchi cifrati a proprio vantaggio

– per tali ragioni ECB è raramente usato

Cipher Block Chaining (CBC)

• CBC non presenta i problemi di ECB

– a due blocchi in chiaro identici non corrispondono due blocchi cifrati identici

– per comprendere CBC conviene prima considerare il seguente esempio che ne condivide l’idea base

RANDOMIZED ELECTRONIC CODE BOOK ENCRYPTION

CBC – Idea base

– per ogni blocco di testo in chiaro mi viene generato un numero random a 64 bit ri

– mi e ri vengono sommati ( XOR)

– il risultato viene cifrato con la chiave segreta

– i blocchi cifrati ci e i numeri random, in chiaro, ri vengono trasmessi

– per riottenere il testo in chiaro, vengono prima decifrati i blocchi ci con la chiave segreta

– poi i blocchi risultanti vengono sommati ( XOR) con i numeri random ri

CBC – Idea base

– l’esempio appena visto è molto inefficiente

• l’informazione da trasmettere è duplicata; per ogni blocco va trasmesso il corrispondente numero random

– un altro problema è che un avversario può riarrangiare i blocchi in modo da ottenere un effetto predittivo sul testo in chiaro

• ad esempio, se la coppia r2|c2 fosse rimossa il corrispondente blocco in chiaro m2 scomparirebbe, o

• se la coppia r2|c2 fosse scambiata con la coppia r7|c7 m2 e m7 risulterebbero scambiati

CBC – Idea base

• ancora peggio, se l’avversario conosce ciascun mi, può modificare mi in modo predittivo cambiando il corrispondente numero random ri

Modalità operativa CBC

• CBC genera i suoi “propri” numeri random

– usa ci come numero random ri+1

• cioè, usa il precedente blocco cifrato come numero random da sommare (XOR ) al blocco di testo in chiaro successivo

– per evitare che due testi in chiaro inizialmente identici diano luogo a dei blocchi cifrati inizialmente identici

– CBC genera un singolo numero random, detto vettore di inizializzazione (Initialization Vector IV), che viene sommato (XOR ) con il primo blocco di testo in chiaro

• il risultato viene trasmesso dopo la cifratura a chiave segreta


CIPHER BLOCK CHAINING ENCRYPTION

CIPHER BLOCK CHAINING DECRYPTION

Modalità operativa CBC – in formule

• CIFRATURA

– c1 = E(K, (IV m1))

– ci = E(K, (ci-1 mi)) per i > 1

• DECIFRATURA

– m1 = D(K, c1) IV

– mi = D(K, ci) ci-1 per i > 1


– la decifratura è semplice essendo l’or-esclusivo un’operazione che coincide con la propria inversa

– essendo il costo della somma (XOR ) trascurabile rispetto al costo della cifratura a chiave segreta la cifratura con CBC ha le stesse prestazioni della cifratura con ECB

• eccetto il costo delle generazione e trasmissione di IV

– in molti casi la sicurezza di CBC non dipende dalla scelta del vettore di inizializzazione IV

• cioè si possono porre tutte le cifre di IV pari a 0

Utilità del vettore di inizializzazione

– tuttavia, in alcuni casi, l’assenza di IV riduce la sicurezza

• ad esempio, si supponga che il file cifrato contenente i salari dei dipendenti sia trasmesso settimanalmente

• in assenza di IV, un ascoltatore potrebbe verificare se il testo cifrato differisce da quelle della precedente settimana, e

• potrebbe determinare la prima persona il cui salario è cambiato

• un altro esempio è quello di un generale che invia giornalmente delle informazioni segrete dicendo “continue holding your position”


• il testo cifrato sarebbe ogni giorno lo stesso, finché il generale decide di cambiare ordine, inviando il messaggio “start bombing”

• il testo cifrato cambierebbe immediatamente, allertando il nemico


• Un vettore di inizializzazione scelto randomicamente garantisce che

– anche se lo stesso messaggio è inviato ripetutamente il corrispondente testo cifrato risulta ogni volta differente, e

• previene attacchi all’algoritmo di cifratura di tipo testo in chiaro selezionato

• anche quando un avversario può fornire del testo in chiaro al CBC

CBC minaccia 1 – Modifica dei blocchi cifrati

– L’uso di CBC non elimina il problema che qualcuno possa modificare il messaggio in transito • cambia la natura della minaccia

• un avversario non può più vedere ripetizioni di blocchi cifrati, e

• non può più copiare/spostare blocchi cifrati; ad esempio per scambiare il salario di due dipendenti

– un avversario può ancora modificare il testo cifrato in modo predittivo • cosa potrebbe succedere se modificasse un blocco di

testo cifrato, ad esempio cn?


• da mn+1 = D(K, cn+1) cn si evince che una modifica di cn può avere un effetto prevedibile su mn+1

• ad esempio, cambiando il terzo bit di cn cambia il terzo bit di mn+1

• chiaramente essendo anche mn = D(K, cn) cn-1 l’avversario non può prevedere quale possa essere il nuovo valore di mn,

• molto probabilmente la modifica di cn corrompe completamente il blocco in chiaro mn


• ad esempio, supponiamo che un avversario (Trudy) sappia che una data sequenza di blocchi cifrati, del file dei salari, corrispondano alla riga contenente i suoi dati personali

• se Trudy vuole aumentare il suo salario di 10K, e

• se sa che l’ultimo byte di m7 corrisponde alle decine di migliaia nella codifica decimale 00000010,

• per darsi 10K in più deve semplicemente cambiare il bit meno significativo di c6; da m7 = D(K, c7) c6

Tacker Trudy Project Manager 24.122,00

m1 m2 m3 m4 m5 m6 m7 m8


• tuttavia, Trudy non sarà più in grado di predire cosa apparirà nella voce “Posizione”,

• infatti, da m6 = D(K, c6) c5, è impraticabile prevedere l’effetto della modifica di c6 su m6

• se il file decifrato fosse letto da una persona umana, questa potrebbe insospettirsi della presenza di simboli strani nel campo “Posizione”,

• se invece il file decifrato viene elaborato da un programma l’attacco potrebbe non essere rilevato

Tacker Trudy Project Mana?#j$hé*ì 34.122,00

m1 m2 m3 m4 m5 m6 m7 m8


• Ricapitolando

– Trudy è stato in grado di modificare un blocco in modo predittivo

– con l’effetto collaterale di modificare il blocco precedente senza poter prevedere il risultato finale

CBC minaccia 2 – Riarrangiamento blocchi cifrati

• Si supponga che Trudy conosca – il testo in chiaro e, il corrispondente testo cifrato

di qualche messaggio, cioè • m1, m2, ..., mn e

• IV, c1, c2, ..., cn

• conosce anche il blocco decifrato di ciascun ci, da D(K, ci) = ci-1 mi


– da queste informazioni, Trudy • può considerare ciascun ci come un "building block" e

• costruire un flusso cifrato usando ogni combinazione di ci ed essere in grado di calcolare quale sarà il corrispondente testo in chiaro

– a cosa potrebbe servirgli tale flusso cifrato?

– facciamo una piccola digressione • uno dei modi di combattere la minaccia 1 è includere un CRC

(Cyclic Redundancy Check) al testo in chiaro prima di cifrarlo con un CBC

• se Trudy modifica qualche blocco cifrato, il CRC consentirà ad un computer di rilevare prontamente l’alterazione del messaggio


• supponiamo che sia stato scelto un CRC a 32 bit

• c'è 1 possibilità su 232 che il CRC coincida con quello corretto

• supponiamo che a Trudy non interessi quale possa essere il nuovo messaggio di testo in chiaro (che potrebbe essere completamente indecifrabile),

• ma interessi solamente che il nuovo messaggio manomesso sia accettato dal computer ricevente sapendo che viene eseguito un controllo di tipo CRC

• Trudy può provare a costruire molti flussi cifrati combinando in modi diversi i blocchi c1, c2, ..., cn e

• può calcolare il risultante testo in chiaro per ciascuno di essi, e


• può poi testare se il testo in chiaro risultante ha un CRC corretto

• mediamente serviranno 231 tentativi

• Che male potrebbe fare Trudy modificando un messaggio, senza controllarne il contenuto, in modo tale che sia accettato dal computer ricevente?

• a) forse Trudy è soltanto malizioso, e vuole distruggere alcuni dati che vengono caricati attraverso la rete

• b) in realtà, c'è un modo sottile di controllare, seppur in misura ridotta, il contenuto del messaggio modificato


• supponiamo che Trudy sposti blocchi contigui; ad esempio, cn e cn+1 vengono spostati in qualche altro posto

• il blocco originale mn+1 apparirà in un’altra posizione

• se mn+1 contiene il salario del presidente, Trudy potrebbe scambiare i blocchi in modo da cambiarlo con il suo,

• ma poi dovrà modificare molto probabilmente gran parte del messaggio restante per garantire che il CRC risulti invariato


• Per prevenire attacchi di questo tipo,

– basati sul riarrangiamento dei blocchi cifrati,

– tale da preservare il CRC originario

potrebbe essere usato un CRC a 64 bit

– ciò è sicuramente sufficiente se l’attacco al CRC, nell’ambito di un CBC, è di tipo a forza bruta


• Per chi progetta protocolli crittografici sicuri, una modalità di cifratura

– ad un singolo step e che protegge

– sia la confidenzialità

– che l'autenticità di un messaggio

è stata per molti anni una sorta di “Santo Graal“ da ricercare!

Output FeedBack Mode (OFB)

• L’OFB è un cifrario a flusso – la cifratura consiste nel sommare (XOR ) il

messaggio con il keystream (o one-time pad) generato da OFB stesso

– supponiamo che il keystream sia ottenuto generando singoli blocchi di 64 bit alla volta; un possibile modo per generarlo è il seguente • viene prima generato un numero random IV

(Initialization Vector) di 64 bit

• il primo blocco del keystream coincide con IV: b0 = IV

• il secondo blocco b1 si ottiene cifrando b0 con la chiave segreta; in formule b1 = E(K, b0), e così via

OFB – Cifratura

• in generale si ha: bi = E(K, bi-1)

– il one-time pad (keystream) risultante è dato dalla sequenza • OTP = OTP(K, IV) = b0|b1|b2|… |bi|bi+1|…

– la cifratura con OFB consiste nel sommare (XOR ) il messaggio m con OTP • se m ha lunghezza lm bit si considereranno soltanto lm bit di

OTP K IV

OTP gen

OTP = b0|b1|b2|… m c = OTP m

OFB – Decifratura

– il risultato della cifratura c = OTP m viene trasmesso insieme a IV; la lunghezza lc di c coincide con lm

– la decifratura è come segue

• il destinatario riceve IV e conoscendo K calcola lo stesso one-time pad OTP = OTP(K, IV)

• il messaggio m si ottiene sommando (XOR ) il flusso cifrato c con lc bit di OTP

K IV

OTP gen

OTP = b0|b1|b2|… c m = OTP c

OFB – Vantaggi

• Il one-time pad OTP può essere generato in anticipo

– prima che sia noto il messaggio m da cifrare; una volta ottenuto m è necessario soltanto effettuare la somma (XOR ) con il one-time pad

• è eseguibile in modo estremamente veloce

– se qualche bit del testo cifrato dovesse corrompersi, soltanto i corrispondenti bit del testo in chiaro sarebbero corrotti

• diversamente dalla modalità CBC dove se cn fosse corrotto mn sarebbe completamente corrotto e mn+1 sarebbe corrotto in corrispondenza dei medesimi bit di cn

OFB – Vantaggi

– un messaggio m può arrivare a pezzi di lunghezza arbitraria, e

• ogni volta che arriva un pezzo, il corrispondente testo cifrato può essere immediatamente trasmesso

• in CBC invece, se il messaggio arriva un byte alla volta, per la cifratura è comunque necessario attendere che un blocco di 64 bit (o un multiplo intero di 8 byte) sia completo

• ciò può comportare l’attesa di altri 7 byte o

• di aggiungere dei bit di riempimento, cosa che aumenta la quantità di dati da trasmettere

OFB – Svantaggi

– se un avversario conoscesse il testo in chiaro m e quello cifrato c potrebbe modificare il testo in chiaro a piacimento semplicemente

• sommando il testo cifrato con il testo in chiaro noto, e

• sommando il risultato con un qualsiasi messaggio m’ che desidera sostituire ad m

• cioè, l’avversario dovrebbe modificare il testo cifrato nel seguente modo c’ = c m m’

• verificare che decifrando c’ anziché c si ottiene m’ anziché m

k-bit OFB

• In generale la modalità OFB consente di generare flussi di “pezzi” da k bit

– quanto visto prima corrisponde al caso in cui k = 64 bit

k-bit OFB

k-bit OFB

• La modalità k-bit OFB funziona nel seguente modo (si descriverà la versione data in [DES81]):

– l’input I0 al modulo di cifratura DES è inizializzato a IV; cioè I0 = IV

• se IV ha meno di 64 bit, vengono inseriti degli 0 di riempimento a sinistra (cifre più significative)

– il primo pezzo b0 di OTP si ottiene selezionando k bit dall’output O0 = E(K, I0) di DES (una quantità a 64 bit)

• da un punto di vista crittografico non ha importanza come siano scelti tali bit da O0; [DES81] specifica che devono essere i k bit più significativi

k-bit OFB

– l’i-esimo pezzo bi si ottiene selezionando i k bit più significativi dell’output Oi = E(K, Ii) di DES

– ove l’input Ii è stato ottenuto da Ii-1 eseguendo due operazioni:

• una traslazione a sinistra di k bit, e

• un inserimento di bi-1 nei k bit meno significativi di I1 (k bit più a destra)

Cipher FeedBack Mode (CFB)

• La modalità CFB è molto simile a OFB – viene prodotto un one-time pad

• generando, uno alla volta, singoli pezzi di k bit

– che viene sommato (XOR ) con pezzi di k bit del messaggio

k-bit CFB

Cipher FeedBack Mode (CFB)

– in OFB i k bit meno significativi dell’input Ii del modulo di cifratura DES sono i k bit di bi-1

• sono parte dell’output Oi-1 della cifratura DES del blocco precedente

– invece, in CFB i k bit di Ii sono i k bit di testo cifrato del blocco precedente, cioè i k bit di ci-1

• in CFB il one-time pad non può essere generato prima che il messaggio è noto (a differenza di OFB)

– nella modalità a k-bit è ragionevole assegnare a k un valore diverso da 64 bit

• una scelta sensata è k = 8 bit

CFB – Vantaggi

• Con OFB o CBC – se si ha una perdita di caratteri in trasmissione

(testo cifrato) • ad esempio, se nel flusso cifrato c1, c2, c3, …, cn, … si

perde il carattere ck a destinazione si ottiene la sequenza c1, c2, ck-1, ck’, …, cn-1’ ove ck’ = ck+1, ck+1’ = ck+2, … ck+i’ = ck+i+1

– o se extra caratteri sono aggiunti al flusso cifrato • ad esempio, se nel flusso cifrato c1, c2, c3, …, cn, … si

aggiunge il carattere c* dopo di ck-1 a destinazione si ottiene la sequenza c1, c2, ck-1, ck’, …, cn+1’ ove ck’ = c*, ck+1’ = ck, … ck+i’ = ck+i-1

CFB – Vantaggi

– l’intera parte restante della trasmissione risulta indecifrabile

• poiché mi’ = ci’ bi

• e bi = bi(K, IV) cioè bi non dipende dalla sequenza cifrata

– invece, con 8-bit CFB, si ha un effetto risincronizzante

• se un byte ci è perso in trasmissione il corrispondente testo in chiaro mi è perso, e i successivi 8 byte mi+1, …, mi+8 risulteranno indecifrabili, ma dal byte mi+9 in poi il testo in chiaro sarà corretto

CFB – Vantaggi

• ciò perché bi = bi(K, ci-1) cioè bi è derivato dalla sequenza di caratteri cifrati

• discorsi analoghi valgono nel caso dell’aggiunta di un byte al flusso cifrato

– i messaggi cifrati con CFB offrono più protezione di CBC e di OFB rispetto ad eventuali manomissioni

• nel caso di 8-bit CFB un avversario può modificare ogni singolo byte in modo predittivo, ma con l’effetto collaterale di non poter prevedere/controllare i successivi 8 byte

• discorsi simili valgono per 64-bit CFB

CFB – Vantaggi

– a differenza di CBC, non sono possibili attacchi basati sul riarrangiamento di blocchi

• tuttavia, intere sezioni del messaggio possono essere riarrangiate rendendo indecifrabili le parti corrispondenti ai “punti di giuntura”

CFB – Svantaggi

– 8-bit CFB ha lo svantaggio che ogni byte di input richiede un’operazione DES

– inizialmente CFB fu concepito per essere utilizzato con un numero arbitrario k di bit per “pezzo” • con k < dimensione di un blocco completo (64 bit per

DES)

• nella pratica k è pari a 1 byte oppure coincide con la dimensione piena (full-block) dei blocchi del modulo di cifratura

– quando utilizzato in modalità full-block le prestazioni di CFB sono comparabili a quelle di ECB, CBC, e OFB

CFB – Svantaggi

– come OFB consente di cifrare ed inviare ciascun byte del messaggio non appena è noto

– tuttavia, a differenza di OFB non è in grado di anticipare il calcolo del one-time pad

– in fine, è in grado di rilevare delle alterazioni meglio di OFB, ma non bene quanto CBC

CounTeR Mode (CTR)

• CTR è simile a OFM: un one-time pad viene generato e sommato (XOR ) con i dati

• Differisce da OFM perché – non concatena ciascun blocco di one-time-pad con il

precedente, ma – incrementa IV e poi cifra quanto ottenuto per ottenere il

prossimo blocco di one-time pad

CounTerR Mode (CTR)

CTR – Vantaggi

• Il vantaggio principale è che, come OFB,

– il one-time pad può essere pre-calcolato, e

– la cifratura consiste in un semplice XOR

• inoltre, come in CBC,

– la decifratura di un messaggio può iniziare da un qualunque blocco

• non è obbligata ad iniziare dal primo blocco

• CRT è l’ideale in applicazioni che richiedono la cifratura di file/memorie ad accesso casuale (sottoinsiemi di dati prelevati ed ordine non prevedibili)

CTR – Svantaggio

• Come in OFB (e in tutti i cifrari a flusso), nella modalità CTR si ha una perdita di sicurezza se messaggi diversi sono cifrati con la stessa coppia K, IV

– un avversario potrebbe ottenere la somma (XOR ) dei testi in chiaro se somma (XOR ) due testi cifrati ottenuti con la stessa coppia K, IV

GENERARE MESSAGE AUTHENTICATION CODE (MAC)


Generare MAC – Introduzione

• Un sistema di cifratura a chiave segreta può essere usato per generare un MAC cioè una checksum cifrato

– MAC sta per Message Authentication Code

• un sinonimo di MAC è MIC (Message Integrity Code)

• il termine MAC è più popolare; nella PEM (Privacy Enhanced Mail) viene usato il termine MIC

Generare MAC – Introduzione

• Le modalità operative CBC, CFB, OFB, e CTR – offrono una buona protezione della confidenzialità

• un messaggio intercettato è difficilmente decifrabile

– ma non offrono una buona protezione dell’integrità/autenticità di un messaggio

– cioè non proteggono da ascoltatori che lo modificano in modo non rilevabile

• nel seguito useremo i termini integrità e autenticità in

modo intercambiale; se il messaggio è integro non è stato modificato dal momento in cui è stato generato il messaggio è autentico

Residuo CBC

• Un modo standard per assicurare l’autenticità di un messaggio m è

• (cioè per proteggersi da modifiche di m non rilevabili)

– calcolare il CBC di m, ma

– inviare soltanto l’ultimo blocco cifrato (64 bit) e il messaggio m in chiaro

– l’ultimo blocco cifrato è detto residuo CBC

Residuo CBC

– il calcolo del residuo CBC richiede la conoscenza della chiave segreta K

– se un avversario modifica m in m’ resCBC(m’) sarà diverso da resCBC(m) • c’è solo 1 possibilità su 264 che siano uguali

– l’avversario non è in grado di calcolare resCBC(m’) senza conoscere la chiave segreta K

– il destinatario del messaggio • calcola il residuo del messaggio in chiaro ricevuto, e

• verifica che sia uguale al residuo ricevuto

• se i residui coincidono deduce che (con elevata probabilità) il residuo ricevuto è stato calcolato da qualcuno che conosce la chiave segreta il mittente è autentico

Residuo CBC

• In molte applicazioni non è necessario proteggere la confidenzialità, ma solo l’autenticità – in questi casi si può trasmettere il testo in chiaro più il

residuo

• Tuttavia, è assai frequente la necessità di proteggere contemporaneamente confidenzialità e autenticità – se il messaggio m è un singolo blocco, ciò può

ottenersi con una semplice cifratura a chiave segreta

– nel caso di un messaggio multi blocco qual è la trasformazione equivalente?

Assicurare confidenzialità e autenticità

• Ricapitolando, dato un messaggio m – per assicurare la confidenzialità di m basta cifrarlo in

modalità CBC – per assicurare l’autenticità di m basta inviare resCBC(m)

più m in chiaro

• a prima vista la soluzione riportata sotto sembrerebbe assicurare confidenzialità e autenticità

Assicurare confidenzialità e autenticità

• In realtà tale soluzione è chiaramente errata! – consiste nell’inviare

• il messaggio cifrato nella modalità CBC: ECBC(K, IV, m)

• ripetendo soltanto l’ultimo blocco cifrato: resCBC(m)

– chiunque voglia alterare il messaggio deve solo • modificare uno o più blocchi cifrati con CBC e

• inviare il nuovo messaggio ripetendo due volte l’ultimo blocco cifrato

– inviare il residuo CBC in aggiunta al messaggio cifrato con CBC non aumenta la sicurezza

Sorge un dubbio!

• È possibile assicurare confidenzialità e autenticità inviando semplicemente il messaggio cifrato con CBC?

• per autenticità (integrità) intendiamo che un

calcolatore è in grado di rilevare automaticamente se il messaggio è stato alterato

Via il dubbio!

• Usando CBC da solo, non è possibile rilevare in modo automatico eventuali modifiche di un messaggio – ogni stringa di bit, comunque venga generata, viene

decifrata in “qualcosa”, e

– gli ultimi 64 bit di quella stringa sono il suo residuo CBC corretto

– chiunque intercetta il testo cifrato può modificarlo, e

– un computer a destinazione decifrerà il risultato, • che potrebbe essere assolutamente privo di senso,

– senza essere consapevole che quanto ottenuto è di fatto spazzatura

Via il dubbio!

– un utente umano si renderebbe conto se il testo cifrato è stato alterato

• a meno che la modifica non sia stata eseguita da un avversario in modo “pulito”

– ma un computer non è in grado di farlo se non si aggiunge un controllo di integrità

Un altro tentativo

• Un’alternativa potrebbe essere: – calcolare il residuo CBC del messaggio resCBC(m), – allegarlo al testo in chiaro m, e – cifrare con CBC la concatenazione m|resCBC(m)

Domanda: questa soluzione funziona?

Un altro tentativo

• Risposta: neanche questa soluzione funziona!

– c7 = resCBC(m) = E(K, c6 c6) = E(K, 000 … 0)

– cioè il residuo CBC è una stringa ottenuta cifrando con la chiave segreta una stringa di 64 bit a 0

– il residuo CBC non dipende da m

– non può offrire alcune protezione di integrità

Ultimo tentativo

• Supponiamo di – calcolare un checksum non crittografico CRC(m)

(ad esempio, un CRC) del messaggio m e

– di appenderlo alla fine di m, e

– di cifrare con CBC il tutto: m| CRC(m)

Domanda: quest’altra soluzione funziona?

Ultimo tentativo

• Risposta: questa soluzione “quasi” funziona!

– è vulnerabile ad attacchi molto sottili se il CRC è corto

– d’altro canto checksum non crittografici più lunghi sono “sospetti”

Qual è la soluzione sicura?

• Viene considerata una soluzione sicura proteggere

– la confidenzialità di un messaggio m cifrandolo con CBC, e

– l’integrità di m con un residuo CBC

– a patto che vengano usate due chiavi distinte

• protezione confidenzialità: ECBC(K, IV, m)

• protezione integrità: resCBC(K’, IV, m) con K’ K

– chiaramente ciò comporta una notevole perdita di efficienza

Qual è la soluzione sicura?

– il costo computazionale è duplicato rispetto al costo della sola cifratura CBC • sono state proposte tecniche più rapide, ma

generalmente presentano sempre dei “sottili difetti” crittografici

• se tali difetti siano seri o meno dipende dal tipo di applicazione e dall’intelligenza dell’avversario

– alcune di queste tecniche sono • CBC con un Checksum Crittografico Debole

• Cifratura CBC e Residuo CBC con Chiavi Correlate

• CBC con Hash Crittografico

• Offset Codebook Mode (OCB)

CBC con un Checksum Crittografico Debole

• Visto che – l’uso di checksum non crittografici in CBC risulta poco

sicuro, e

– checksum crittografici di qualità sono computazionalmente dispendiosi

• è stato proposto di usare checksum crittografici “deboli” – complessivamente dovrebbe essere una soluzione

sicura • lo sforzo computazionale per violare il checksum debole va

moltiplicato per le limitazioni derivanti dal fatto che è usato in una cifratura CBC

CBC con un Checksum Crittografico Debole

• Sebbene non ci sono ragioni per sostenere che tale schema sia insicuro,

• CBC con checksum crittografici deboli non ha riscosso successo

• si consideri che Kerberos IV usa un checksum

crittografico debole per la protezione d’integrità fuori da uno schema di cifratura e sembra che non sia mai stato violato!

Cifratura CBC e Residuo CBC con Chiavi Correlate

– anziché usare due chiavi completamente indipendenti per la cifratura CBC e per il calcolo del residuo

– un trucco usato in Kerberos V è impiegare una versione modificata della chiave in una delle due operazioni • cambiare un singolo bit dovrebbe essere sufficiente, ma

• Kerberos invece somma (XOR ) la chiave con la costante a 64 bit F0F0F0F0F0F0F0F016

• tale soluzione preserva la parità della chiave e

• mai trasforma una chiave non-debole in una chiave debole

Cifratura CBC e Residuo CBC con Chiavi Correlate

– il fatto di avere una chiave matematicamente correlata all’altra

• in alternativa alla scelta di due numeri random come chiavi

– non introduce particolari debolezze, ma non introduce neanche particolari vantaggi

• in generale, distribuire una coppia di chiavi non è più difficile di distribuirne solo una, e

• il fatto che due chiavi siano matematicamente correlate non riduce il carico computazionale,

• l’unico vantaggio nel derivare una chiave dall’altra lo si ha quando si dispone di un sistema/servizio per la distribuzioni di chiavi singole che non è estendibile al caso di coppie di chiavi

CBC con Hash Crittografico

• Un altro approccio è – concatenare un messaggio m con il suo un hash

crittografico h(m), tipicamente 128 bit, e

– cifrare con CBC il tutto: m|h(m)

• Tale soluzione – è probabilmente sicura

• sebbene non sia stata adeguatamente studiata, visto che gli schemi moderni usano hash cifrati con chiavi

– richiede due fasi crittografiche (come nel caso della cifratura CBC più il residuo CBC con chiavi distinte),

– ma è più efficiente se la funzione di hash è più veloce dell’algoritmo di cifratura

Offset CodeBook Mode (OCB)

• OCB è uno dei molti modi che permette di ottenere cifratura e protezione di integrità effettuando soltanto una singola fase di cifratura – OCB e altre tecniche simili sono molto recenti per

avere un supporto di studi e test,

– spesso sono gravate da license/patenti,

– ma sembra molto probabile che una o più di queste tecniche diventi alla fine il modo standard per ottenere protezione di integrità e di confidenzialità

CIFRATURA MULTIPLA DES Modalità Operative dei Cifrari a Blocchi

Cifratura multipla EDE o 3DES

• In generale, ogni schema di cifratura può essere reso più sicuro ricorrendo alla cifratura multipla.

• Nel caso di DES, è “universalmente” ritenuta sicura la cifratura multipla nota come – EDE: Encrypt-Decrypt-Encrypt (o 3DES, triplo DES)

• c = E(K1, D(K2, E(K1, m))) = (E1 ○ D2 ○ E1)(m) • m = E(K1, D(K2, E(K1, c))) = (E1 ○ D2 ○ E1)(c)

– la cifratura multipla EDE

• è di fatto un meccanismo per incrementare la lunghezza della chiave DES

• sebbene sia stata introdotta per arrivare ad uno standard sicuro basato su DES, in linea di principio è applicabile anche ad altri schemi di cifratura, ed esempio ad IDEA

• è più importante nel caso di DES; la chiave DES è notoriamente considerata troppo corta


• Si è visto che uno schema di crittografia presenta sempre due funzioni – note come cifratura e decifratura

• Tali funzioni sono l’una l’inversa dell’altra – in pratica, ciascuna

• prende in input un blocco di dati m, e

• restituisce il corrispondente blocco offuscato c tale che, applicando a c l’altra funzione si ottiene m

– ha senso applicare • la “funzione di decifratura” D(K, m) al testo in chiaro m per

cifrarlo e

• poi applicare la “funzione di cifratura” E(K, D(K, m)) per decifrare quanto ottenuto riottenendo il testo in chiaro m


– in definitiva ha poco senso chiamare

• E(K, m) “funzione di cifratura”, e

• D(K, m) “funzione di decifratura”

– i ruoli di tali funzioni sono interscambiabili!

• conviene chiamarle semplicemente funzione E( ) e funzione D( )

• tuttavia, spesso si continuerà a chiamarle funzione di cifratura e funzione di decifratura!


• Realizzare una cifratura multipla non è banale

– specie se si desidera anche ottenere un cifrario a flusso a partire da un cifrario a blocchi

• Il metodo standard per usare EDE è il seguente

– vengono usate due chiavi (e non tre): K1 e K2

– ogni blocco di testo in chiaro mi è sottoposto

• prima ad E1( ) cioè viene eseguito E(K1, m)

• poi a D2( ) cioè viene eseguito D(K2, E(K1, m))

• e in fine ancora ad E1( ) cioè viene eseguito E(K1, D(K2, E(K1, m)))


• Quanto ottenuto è di fatto un nuovo schema di cifratura a chiave segreta – un blocco di 64 bit in input è mappato in un altro

blocco di 64 bit in output

– il processo è invertibile se si conoscono le chiavi, altrimenti è di fatto impraticabile risalire dall’output all’input

E( ) E( ) D( ) m c

K1 K2 K1

Decifratura EDE

• La decifratura EDE è semplicemente il processo inverso

D( ) D( ) E( ) c m

K1 K2 K1

EDE con CBC outside

• Per ottenere un cifrario a flusso a partire dal cifrario a blocchi EDE, viene usata la modalità operativa CBC outside – cioè le tre funzioni E1( )-D2( )-E1( ) vengono applicate a ciascun

blocco, – ma il concatenamento CBC viene eseguito soltanto una volta

Alcune domande

– Per quale motivo 3DES e il corrispondente cifrario a flusso sono stati definiti come appena specificato? Si potevano prendere delle decisioni diverse:

1. si è optato per tre cifrature, ma potevano essere due o più; perché proprio tre?

2. perché le tre funzioni sono E( )-D( )-E( ) e non ad esempio E( )-E( )-E( ) o E( )-E( )-D( )?

3. perché il concatenamento CBC viene fatto esternamente (outside) e non internamente (inside)?

EDE con CBC inside

• Cifrario a flusso ottenibile con un concatenamento CBC interno – cioè si considerano una cascata di due concatenamenti CBC

• prima, utilizzando la funzione E1( ), poi utilizzando D2( ) e in fine utilizzando ancora E1( )

Quante cifrature?

• Ovviamente, più volte un blocco è cifrato più elevata è la sua sicurezza – ma ogni cifratura è computazionalmente costosa

– è fondamentale che una schema di cifratura sia efficiente oltre che efficace • l’obiettivo è garantire un livello di sicurezza elevato con il

minimo sforzo computazionale

– proviamo a valutare il rapporto sicurezza / costo computazionale nei seguenti casi • cifratura doppia con la stessa chiave

• cifratura doppia con due chiavi diverse

• cifratura tripla con due chiavi diverse

• cifrare tripla con tre chiavi diverse

Cifratura doppia con una stessa chiave

– Supponiamo di non volere il disagio di leggere in due chiavi

– DOMANDA: Cifrare due volte consecutive con la stessa chiave aumenta la sicurezza?

E( ) E( ) plaintext ciphertext

K K


• RISPOSTA – cifrare due volte con la stessa chiave K risulta non

essere molto più sicuro di eseguire una singola cifratura con K • una ricerca esaustiva nello spazio della chiave richiede

ancora, nel caso peggiore, 256 tentativi

• ogni tentativo ha un costo computazionale duplicato – l’avversario deve eseguire una decifratura doppia

– tuttavia, raddoppiare lo sforzo computazionale non è considerato in generale un aumento significativo della sicurezza

– soprattutto tenendo conto che anche l’efficienza risulta essere dimezzata


• DOMANDA: … e riguardo agli schemi riportati sotto? – si tratta sempre di una cifratura doppia con la stessa chiave

E( ) D( ) plaintext ciphertext

K K

D( ) E( ) plaintext ciphertext

K K

D( ) D( ) plaintext ciphertext

K K

Cifratura doppia con due chiavi

• Se cifrare due volte consecutive, con due chiavi diverse K1 e K2, avesse l’effetto di raddoppiare la chiave (da 56 a 112 bit)

• allora la cifratura doppia sarebbe sufficiente, ma non è così!

• Supponiamo di eseguire una cifratura doppia, con due chiavi K1 e K2, su un singolo blocco da 64 bit – trascuriamo ogni schema di concatenamento e

concentriamoci sui cifrari a blocchi

E( ) E( ) plaintext ciphertext

K1 K2

Cifratura doppia con due chiavi

– in apparenza, sembra che l’uso di due chiavi diverse equivalga a raddoppiare la lunghezza della chiave

• un attacco brute force deve indovinare sia K1 che K2 per ottenere il testo in chiaro da quello cifrato

– tuttavia, esiste un attacco più sofisticato che richiede approssimativamente soltanto un raddoppio del costo computazionale necessario a violare DES (singolo)

• si tratta di un attacco difficilmente praticabile, ma il fatto che esista spinge a ricercare schemi di cifratura più sicuri

• di fatto la cifratura DES con due chiavi non è considerata sicura

Attacco a DES doppio

1. Si assuma che un avversario disponga di qualche coppia plaintext, ciphertext

• m1, c1, m2, c2, m3, c3 dove ci = E(K2, E(K1, mi)) è ottenuto eseguendo una cifratura doppia di mi con K1 e K2

• si desidera trovare le chiavi K1 e K2

2. Costruire prima una tabella A con 256 entry

• ogni entry è una coppia Ki, r = E(Ki, m1)

• ordinare la tabella in base al valore numerico di r

3. Costruire poi una seconda tabella B con 256 entry

• ogni entry è una coppia Ki, r = D(Ki, c1)

• ordinare la tabella in base al valore numerico di r


4. Ricercare nelle due tabelle (ordinate) le entry corrispondenti, cioè con lo stesso valore di r • ad es. KA, r della tabella A e KB, r della tabella B

• ogni corrispondenza fornisce KA come candidato di K1 e KB come candidato di K2

• poiché r = E(KA, m1) e r = D(KB, c1) c1 = E(KB, E(KA, m1))

5. In generale, si otterranno più di una coppia candidata • per ogni coppia candidata va eseguito il test rispetto

m2, c2, se ci sono ancora più coppie candidate va eseguito il test rispetto m3, c3 e così via

• la coppia corretta è quella che passa tutti i test, mentre quelle errate dovranno fallire qualche test


• L’attacco a DES doppio appena descritto è difficilmente praticabile

– dover costruire una tabella di 256 entry è sicuramente scoraggiante

• Tuttavia, l’esistenza di un attacco è una ragione sufficiente per decidere di usare DES triplo

– DES doppio potrebbe essere sufficiente,

– ma DES triplo è più sicuro e non è molto più complesso da realizzare si usa DES triplo

Attacco a DES doppio – Stima dei tentativi

• Quante coppie candidate ci saranno mediamente dopo la prima ricerca nelle due tabelle? – #cc1: numero di coppie candidate ottenute dopo la

prima ricerca – 264 possibili blocchi da 64 bit – 256 entry in ciascuna tabella – Pbt: probabilità che un blocco sia in una tabella – Pbt = 256 / 264 = 1 / 28 – Pc: probabilità che un blocco sia entrambe le tabelle (e

che quindi identifichi una coppia candidata) – Pc = 1/(28 ∙ 28)= 1 / 216

– #cc1 ≈ Pc ∙ numero blocchi = 264 / 216 = 248

Attacco a DES doppio – Stima dei tentativi

– ci sono circa 248 coppie candidate errate

– Pc2: probabilità che una coppia candidata soddisfi anche il secondo test

– Pc2 ≈ 1/264

– Pe2: probabilità di trovare un coppia candidata errata dopo il secondo test

– Pe2 ≈ 248/264

– pertanto, Pe3 ≈ 248/2128 = 1 / 280

– la probabilità di trovare un falso positivo dopo tre test è di fatto nulla • dopo tre test si ottiene un’unica coppia candidata che è

quella corretta

Cifratura tripla con solo due chiavi

• 3DES effettua una cifratura tripla

• Perché 3DES usa solo due chiavi? – molto probabilmente non si ha una maggiore sicurezza

rispetto a DES doppio • K1 è usata due volte

– è ormai opinione comune che usare K1 due volte è sufficientemente sicuro • non è necessario generare, trasmettere e memorizzare una terza

chiave

• 112 bit di chiave mettono al riparo da attacchi di tipo brute force,

• e nessun attacco diverso da quello a forza bruta è noto per EDE

– alcuni sistemi implementano 3DES con tre chiavi indipendenti, ma questo non è lo standard


• Una ragione “esoterica” per l’uso di due sole chiavi è la seguente – in molte applicazioni (es. UNIX Password Hash) una

proprietà importante di un sistema crittografico è che • data una coppia plaintext, ciphertext

• deve essere impraticabile trovare qualche chiave che mappa il testo in chiaro in quello cifrato

• (con blocchi di 64 bit e chiavi di 112 bit ci saranno molte di queste chiavi)

• usando EDE con tre chiavi diverse, è semplice trovare una tripla di chiavi che mappa un dato testo in chiaro in un dato testo cifrato

• però, nel caso in cui K1 = K3 il problema diventa impraticabile (provarlo)


• Perché la chiave K2 è usata in modalità di decifratura, cioè nella funzione di decifratura D( ) di EDE? – tale scelta non serve ad aumentare il livello di

sicurezza; si poteva usare K2 in modalità di cifratura ottenendo uno schema di tipo EEE

– una possibile ragione è che se K1 = K2 EDE equivale ad un semplice DES • quindi è possibile interoperare con un sistema DES

semplice

CBC Outside vs Inside

• Il 3DES comunemente usato nelle applicazioni esegue un concatenamento CBC esterno – ad ogni blocco viene applicata la cifratura tripla,

– e il concatenamento CBC viene fatto una sola volta sui blocchi cifrati

• l’alternativa sarebbe – cifrare completamente il messaggio con K1 e CBC,

– poi decifrare il risultato con K2 e CBC,

– e in fine cifrare di nuovo quanto ottenuto con K1

• Quali sono le implicazioni di queste scelte?


• Si è visto che con CBC è possibile – fare una modifica predittiva sul testo in chiaro mn

• ad esempio invertire il bit x

– invertendo il bit x nel blocco cifrato cn-1

– ciò comporta però l’effetto collaterale di modificare in modo imprevedibile il blocco mn-1

• la possibilità di sfruttare questa debolezza dipende dal tipo di applicazione

• Con CBC esterno, un avversario può ancora sferrare questo tipo di attacco – il fatto che la cifratura è fatta con un triplo DES è del

tutto ininfluente


– un avversario che inverte il bit x di un blocco cifrato cn-1 modificherà completamente e in modo imprevedibile il blocco di testo in chiaro mn-1

– il blocco di testo in chiaro mn avrà il bit x invertito

– e tutti i blocchi di testo in chiaro diversi da mn-1 e mn saranno invariati


• Con CBC interno

– una modifica ad un blocco cifrato cn altera in modo imprevedibile tutti i blocchi di testo in chiaro dal blocco mn fino alla fine del messaggio

– CBC interno è più sicuro di CBC esterno, e forse dovrebbe essere la scelta migliore

– tuttavia, in alcuni casi è preferibile che la modifica di un blocco cifrato non si propaghi completamente nel resto del messaggio


– sarebbe preferibile che lo schema di cifratura sia auto-sincronizzante • dopo un piccolo numero di blocchi corrotti, il testo in chiaro

inizierà ad essere nuovamente decifrato correttamente

– CBC interno presenta delle sottili vulnerabilità se un avversario può esaminare l’output e fornire del testo in chiaro scelto e IV

– un altro vantaggio di CBC interno riguarda l’efficienza • triplicando l’uso di hardware e pipeline per le cifrature si può

ottenere complessivamente una velocità pari a quella di una singola cifratura

• con CBC esterno ciò non è possibile


• Una ragione per la quale CBC esterno è più usato nonostante i suoi svantaggi è che

– la cifratura EDE può considerarsi a tutti gli effetti un nuovo schema di cifratura (a chiave segreta) a blocchi che usa una chiave di 112 bit

• può essere utilizzata con ciascun metodo di concatenamento (OFB, ECB, CFB, CTR e CBC)

Bibliografia

• [DES81] DES Modes of Operation, FIPS PUB 81, National Bureau of Standards, U.S. Department of Commerce, 1981.




• [Wiki-it] http://it.wikipedia.org/wiki/ • [Wiki-en] http://en.wikipedia.org/wiki/ • [ISECOM] Institute for Security and Open Methodologies

Funzioni Crittografiche di Hash

Luca Grilli

INTRODUZIONE Funzioni Crittografiche di Hash

Funzioni di Hash

• Una funzione di hash (o semplicemente hash o message digest) è una funzione unidirezionale (o one-way) – è una funzione perché prende in input un messaggio e

produce un output che dipende dal messaggio • h: {0, 1}* → {0, 1}b

• {0, 1}*: spazio delle stringhe binarie di lunghezza qualsiasi

• {0, 1}b: spazio delle stringhe binarie di lunghezza b bit

– è considerata unidirezionale (one-way) perché è impraticabile capire quale input corrisponda ad un dato output

Funzioni di Hash sicure

• sia h() una funzione di hash

– h() è considerata sicura se presenta le seguenti proprietà

1. resistenza alla preimmagine: fissato un hash ĥ è computazionalmente impraticabile trovare un messaggio m tale che h(m) = ĥ

2. resistenza alle collisioni: è computazionalmente impraticabile trovare due messaggi m1 e m2 aventi lo stesso digest h(m1) = h(m2)

– le proprietà 1. e 2. implicano la seguente

3. resistenza alla seconda preimmagine: dato un messaggio m, è computazionalmente impraticabile trovare un messaggio m’ avente lo stesso digest h(m) = h(m’)

Terminologia

• Si useranno i termini hash e message digest in modo intercambiabile – la funzione di hash del NIST è chiamata SHA-1: Secure

Hash Algorithm

– mentre l’acronimo MD degli algoritmi MD2, MD4 e MD5 sta per Message Digest

• Tutti gli algoritmi di digest/hash basicalmente fanno la stessa cosa – prendono in input un messaggio di lunghezza variabile, e

– restituiscono in output una quantità avente lunghezza prefissata

Sulla casualità (randomicità)

• Dato un messaggio m, il digest h(m) viene calcolato in modo deterministico

• Tuttavia, l’output della funzione di hash dovrebbe apparire il più possibile casuale – dovrebbe essere impossibile, senza applicare la funzione di

hash, predire ogni porzione dell’output

– per ogni sottoinsieme (di posizioni) di bit nel digest h(m) soltanto procedendo in modo esaustivo dovrebbe essere possibile ottenere due messaggi m1 e m2 tali che h(m1) e h(m2) presentno gli stessi bit in quelle posizioni


– una funzione di hash sicura con n bit dovrebbe essere derivabile da una funzione di hash con più di n bit • prendendo un arbitrario sottoinsieme di n bit dal digest più

grande

– chiaramente, ci sono molti messaggi distinti che sono mappati in uno stesso digest h(m) • m ha lunghezza arbitraria, mentre il digest h(m) ha una

lunghezza prefissata, ad esempio 128 bit

• se m ha una lunghezza di 1000 bit e h(m) di 128 bit

• ci sono in media 2872 messaggi che sono mappati in uno stesso digest

• dopo molti tentativi, due messaggi aventi lo stesso digest si trovano sicuramente


• tuttavia, per “molti tentativi” si intende un numero talmente grande che è di fatto impossibile

• considerando una buona funzione di digest a 128 bit, è necessario provare approssimativamente

• 2128 possibili messaggi prima di ottenere un messaggio avente un particolare digest, o

• 264 messaggi prima di trovarne due aventi lo stesso digest (vedi prossime slide); trovare cioè due messaggi che collidono

Esempi di applicazioni

– Un’applicazione delle funzioni di hash crittografiche è il calcolo dell’impronta digitale di un programma o di un documento di cui si desiderano monitorare eventuali modifiche

• se il message digest h(p) del programma p è noto – e se h(p) è memorizzato in modo sicuro (cioè non può essere

modificato da utenti non autorizzati)

• allora nessun utente non autorizzato può modificare p senza essere scoperto

• perché non sarà in grado di trovare un diverso programma p’ tale che h(p’) = h(p)

Probabilità di collisione

– sia h:{0, 1}* → {0, 1}b una funzione di hash

– siano m1, m2, …, mN N messaggi arbitrariamente scelti in {0, 1}*

– DOMANDA: quanto deve valere N per avere una probabilità del 50% che due messaggi mi, mj abbiano lo stesso hash?

Probabilità di collisione – 1a Stima

• una prima stima di N, per difetto, è la seguente

– k = 2b: numero totale di possibili hash

– 1/k: probabilità che una coppia di messaggi collida

– HP: gli eventi considerati sono mutuamente esclusivi • Prob{h(mi) = h(mj) OR h(mp) = h(mq)} =

Prob{h(mi) = h(mj)} + Prob{h(mp) = h(mq)}

• a rigore tale ipotesi non è soddisfatta, molti eventi hanno intersezione non nulla la stima ottenuta della probabilità è per eccesso ciò si traduce in una stima per difetto di N

• (Prob{E1 OR E2} = Prob{E1} + Prob{E2} – Prob{E1 E2})


– si ha una probabilità del 50% se si considerano k/2 coppie

N(N – 1)/2 = k/2

– ipotizzando N >> 1 si ha

N = k1/2 = 2b/2


• una stima più accurata di N è la seguente

– P: probabilità che almeno una coppia di messaggi collida

– P*: probabilità che tutte le coppie di messaggi abbiano digest diversi, quindi P = 1 - P*

– HP: gli eventi considerati sono indipendenti • Prob{h(mi) ≠ h(mj) AND h(mp) ≠ h(mq)} =

Prob{h(mi) ≠ h(mj)} ∙ Prob{h(mp) ≠ h(mq)}

• a rigore tale ipotesi non è soddisfatta, gli eventi non sono del tutto indipendenti la stima ottenuta della probabilità P è per difetto ciò si traduce in una stima per eccesso di N

• (Prob{E1 AND E2} = Prob{E1} ∙ Prob{E2|E1})


– nell’HP di eventi indipendenti si ha

P = 1 – P* = 1 – (1 – 1/k)N(N – 1)/2

– ipotizzando k >> 1 risulta

P 1 – e – N(N – 1)/2k

– ponendo pertanto P ≥ 1/2 si ottiene

e – N(N – 1)/2k ≤ 1/2 = e – ln2


– da cui si ottiene

N(N – 1)/2 ≥ (ln2)k

– ipotizzando N >> 1 si ha

N ≥ (2ln2)1/2 ∙ k1/2 = (2ln2)1/2 ∙ 2b/2


• il valore esatto di N si può ottenere facendo ricorso al paradosso del compleanno

– P: probabilità che almeno una coppia di messaggi collida – P*: probabilità che tutte le coppie di messaggi abbiano digest

diversi, quindi P = 1 - P*

– k = 2b: numero totale di possibili hash • si considerino inoltre le seguenti probabilità

– P2*: probabilità che h(m2) sia diverso da h(m1) – P3*: probabilità che h(m3) sia diverso da h(m2) e da h(m1) – … – Pi*: probabilità che h(mi) sia diverso da h(mj) 1 ≤ j ≤ i – 1 – … – PN*: probabilità che h(mN) sia diverso da h(mj) 1 ≤ j ≤ N – 1


– risulta che

• P* = P2* ∙ P3* ∙∙∙∙ Pi* ∙∙∙∙ PN* =

= (k – 1)/k ∙ (k – 2)/k ∙ ∙ ∙ ∙ (k – N + 1)/k =

= k!/(kN (k – N)!)

N

k

k

N

Nkk

kP

NN

!

)!(

!*

stima esatta di P*


– si osservi che il precedente valore di P* può approssimarsi come

P* e – N(N – 1)/2k

– si ottiene pertanto quanto ottenuto nella 2a stima

P 1 – e – N(N – 1)/2k

Il problema del compleanno

– Considerando un gruppo di N persone, qual è la probabilità che ci siano due persone con lo stesso compleanno (stesso mese e giorno di nascita)?

• basta utilizzare la relazione precedente ove

– N: numero delle persone nel gruppo

– K = 365: numero di giorni in un anno

N

k

k

NP

N

!1

Il problema del compleanno

– al variare di N si ottengono le seguenti probabilità

N P

2 0.0027

3 0.0082

4 0.0163

21 0.4437

22 0.4757

23 0.5073

40 0.8912

41 0.9031

Lunghezza di un message digest

• DOMANDA

– Quanti bit deve avere l’output di una funzione di hash in modo tale che nessuno sia in grado di trovare due messaggi aventi lo stesso digest?

Lunghezza di un message digest

• Se il digest ha b bit, per trovare due messaggi aventi lo stesso digest, è necessario considerare circa 2b/2 messaggi

– 64 bit digest ricerca esaustiva in uno spazio di circa 232 elementi può essere fattibile

– per tale motivo, l’output di una funzione di hash è di almeno 128 bit

• si ritiene che una ricerca in uno spazio di 264 elementi sia impraticabile dato l’attuale stato dell’arte

Importanza resist. alle collisioni

• Per quale ragione è importante che una funzione crittografica di hash sia resistente alle collisioni? – che debba essere resistente alla preimmagine è

scontato, – ma la resistenza alle collisioni è veramente

necessaria?

• Risposta – in alcune circostanze riuscire a trovare due messaggi

con lo stesso digest può comportare dei seri problemi di sicurezza

Resistenza Collisioni – Esempio

– Alice genera un’informazione xA e • incarica Bob di calcolare un messaggio mA • il cui contenuto deve dipendere da xA secondo dei criteri

prestabiliti

– Bob elabora xA, ottiene mA e lo sottopone ad Alice – Alice verifica la correttezza di mA, calcola l’impronta h(mA),

la firma con la sua chiave privata e invia a Trudy il messaggio in chiaro mA e la sua firma (cioè la firma della sua impronta)

– Trudy legge il messaggio mA e sia accerta che proviene da Alice verificando la firma • usando la chiave pubblica di Alice verifica la firma, cioè decifra con

la chiave pubblica la firma e • verifica che quanto ottenuto coincida con h(mA)


Alice Bob Trudy info xA

mA = f(xA)

legge mA

impronta h(mA)

firma h(mA) sA = E(PRA, h(mA)) mA, sA

impronta h(mA)

verifica firma D(PUA, sA) =?= h(mA)

mA

Resistenza Collisioni – Scenario

• Se la funzione di hash non è resistente alle collisioni, Bob potrebbe realizzare questo attacco:

– calcola due messaggi mA e m’A aventi lo stesso hash, tali che

• mA è il messaggio che si aspetta Alice

• m’A è il messaggio con contenuto falsato deciso da Bob

– sottopone ad Alice mA,

– ma quando viene inviato a Trudy lo intercetta e lo sostituisce con m’A

– Trudy verifica la firma e non può rendersi conto dell’inganno


Alice Bob Trudy info xA

calcola mA e m’A tali che h(mA) = h(m’A) mA

legge mA

impronta h(mA)

firma h(mA) sA = E(PRA, h(mA)) mA, sA

sostituisce mA con m’A m’A, sA

impronta h(m’A)

verifica firma D(PUA, sA) =?= h(m’A)

la verifica della firma da esito positivo poiché h(mA) = h(m’A)

1a strategia di attacco (inefficiente)

– per calcolare due messaggi con lo stesso hash, Bob può seguire il seguente approccio a forza bruta:

1. dato xA, calcola prima il messaggio mA come desidarato da Alice;

2. genera un messaggio “falsato” m’A

3. esegue il test h(mA) =?= h(m’A)

4. in caso negativo ritorna al punto 2.

– ma in questo modo sono necessari circa 2b tentativi e non 2b/2

2a strategia di attacco (efficiente)

– supponiamo invece che Bob sia in grado di generare molte coppie mA, m’A tali che: • mA: è un messaggio che Alice approva

• m’A: è un messaggio falsato secondo le intenzioni di Bob

– cioè Bob applica il seguente approccio a forza bruta: 1. dato xA, genera una coppia mA, m’A

2. esegue il test h(mA) =?= h(m’A)

3. in caso negativo ritorna al punto 1.

– per individuare una coppia di messaggi collidenti sono necessari 2b/2 tentativi

Generare coppie mA, m’A

• DOMANDA: Come può Bob generare 2b/2 coppie mA, m’A tali che

mA possa essere letta e approvata da Alice, e

mB possa essere letta da Trudy e non destare sospetti?

Generare coppie mA, m’A

• SOLUZIONE: basta creare due lettere, una per Alice e una per Trudy, in cui

– molte parole (sostantivi, verbi) non sono “fissate”,

– ma possono essere scelte da un insieme di 2 o più elementi

– senza alterare il significato della lettera e senza introdurre errori grammaticali

con un banale programma è semplice generare tutte le possibili varianti delle due lettere

Esempio

• Si supponga che

– xA sia un messaggio che Alice invia a Bob in cui gli chiede di redigere una lettera per richiedere il licenziamento di Fred; la lettera dovrà poi essere inviata a Trudy (capo del personale)

– Bob, amico di Fred, vuole invece inviare a Trudy una lettera in cui si richiede una promozione di Fred!

Schema per generare mA

• I am writing {this memo| } to {demand | request | inform you} that {Fred | Mr. Fred Jones} {must | } be {fired | terminated} {at once | immediately}. As the {July 11 | 11 July} {memo | memorandum} {from | issued by} {personnel | human resources} states, to meet {our | the corporate} {quarterly | third quarter} budget {targets | goals}, {we must eliminate all discretionary spending | all discretionary spending must be eliminated}.

{Despite | Ignoring} that {memo | memorandum | order}, Fred {ordered | purchased} {PostIts | nonessential supplies} in a flagrant disregard for the company's {budgetary crisis | current financial difficulties}.

Schema per generare m’A

• I am writing {this letter | this memo | this memorandum | } to {officially | } commend Fred {Jones | } for his {courage and independent thinking | independent thinking and courage}. {He | Fred} {clearly | } understands {the need | how} to get {the | his} job {done | accomplished} {at all costs | by whatever means necessary}, and {knows | can see} when to ignore bureaucratic {nonsense | impediments}. I {am hereby recommending | hereby recommend} {him | Fred} for {promotion | immediate advancement} and {further | } recommend a {hefty | large} {salary | compensation} increase.

Due lettere mA, m’A

• I am writing to demand that Mr. Fred Jones must be terminated at once. As the July 11 memorandum from human resources states, to meet the corporate quarterly budget targets, all discretionary spending must be eliminated.

Despite that order, Fred ordered nonessential supplies in a flagrant disregard for the company's budgetary crisis.

• I am writing this memorandum to officially commend Fred

Jones for his independent thinking and courage. He understands the need to get his job done by whatever means necessary, and knows when to ignore bureaucratic nonsense. I hereby recommend him for promotion and further recommend a hefty compensation increase.

IMPIEGHI Funzioni Crittografiche di Hash

Impieghi degli Algortmi di Hash

• Disponendo di un segreto condiviso

• un algoritmo di hash “può” sostituire un algoritmo crittografico a chiave segreta in tutte le sue applicazioni

– Autenticazione a Chiave Segreta

– Calcolo di MAC

– Cifratura (e Decifratura)

Autenticazione a Chiave Segreta*

• HP: KAB segreto condiviso tra Alice e Bob

Alice Bob

rA

rA cifrato con KAB

rB

rB cifrato con KAB

* N.B.: lo schema illustrato presenta delle debolezze che possono essere rimosse con opportuni accorgimenti

Autenticazione con Message Digest*

• HP: KAB segreto condiviso tra Alice e Bob

– MD: generico algoritmo di digest

Alice Bob

rA

MD(KAB |rA)

rB

* N.B.: lo schema illustrato presenta delle debolezze che possono essere rimosse con opportuni accorgimenti

MD(KAB |rB)

Generare un MAC usando (solo) Hash

• Ovviamente è necessario disporre di un segreto condiviso KAB

– MD(m) è calcolabile da tutti coloro che conoscono m e l’algoritmo di digest MD

• la soluzione più immediata è considerare MD(KAB|m) quale MAC di m

– tale soluzione teoricamente corretta

– presenta una debolezza derivante da una comune vulnerabilità dei principali algoritmi di digest quali MD4, MD5, SHA-1

Sulla vulnerabilità di MD4, MD5, SHA-1

• MD4, MD5 e SHA-1 seguono il seguente schema generale

– dall’input m si ottiene un messaggio mp avente lunghezza pari ad un multiplo intero di 512 bit

• mediante un opportuno padding che include, tra l’altro, la lunghezza originaria di m

– mp viene decomposto in chunk (pezzi) da 512 bit

• il digest viene ottenuto mediante una procedura iterativa

– il digest all’n-esima iterazione dipende esclusivamente

• dall’n-esimo chunk e

• dal digest ottenuto all’(n – 1)-esima iterazione

– il digest risultante di m è il digest ottenuto all’ultima iterazione


– si assuma che un attaccante, Trudy, intercetti la coppia m, MD(KAB|m) inviata da Alice a Bob

– Trudy, senza conoscere il segreto KAB, può calcolare il MAC MD(KAB|m*)

– ove m* è un qualsiasi messaggio ottenuto concatenando mp con una qualsiasi stringa binaria, cioè

m* = mp|s per ogni s{0, 1}*

– ovviamente Trudy deve conoscere l’algoritmo MD


• DOMANDA: Come si può procedere per evitare tale debolezza?

• Diverse soluzioni, prive di punti deboli, sono state proposte

• HMAC è quella che ha riscosso maggior successo

– nelle prossime slide si esamineranno tali soluzioni, ordinate dalla più semplice a quella più complessa e che offre maggiori garanzie

1a Soluzione – Mettere KAB in coda

• Una semplice soluzione consiste nel posizionare il segreto KAB alla fine del messaggio m e non il viceversa

• cioè il MAC è dato da MD(m|KAB) – e non da MD(KAB|m)

• Tale soluzione è considerata sicura – a patto che l’algoritmo di digest MD sia molto resistente

alle collisioni, – cioè se fossero noti due messaggi m1 e m2 aventi lo stesso

digest MD(m1) = MD(m2) – per la vulnerabilità vista prima risulterebbe MD(m1|K) = MD(m2|K) K

2a Soluzione – Usare metà bit di MD

• Un’altra soluzione è definire il MAC come un opportuno sottoinsieme del digest MD – nel caso di digest a 128 bit

– il MAC di m può ottenersi considerando i 64 bit meno significativi di MD(KAB|m) • un attaccante non può considerare il MAC come il digest

ottenuto all’iterazione corrispondente al chunk che completa mp

• quindi non può calcolare il MAC di un qualunque messaggio m* del tipo m* = mp|s senza conoscere KAB

• precisamente l’attaccante procedendo per tentativi ha 1 chance su 264 di ottenere l’altra metà di MD(KAB|m)

2a Soluzione – Usare metà bit di MD

– si osservi inoltre che considerare solo 64 bit anziché i 128 del digest non comporta in pratica una perdita di sicurezza

– se l’attaccante non conosce KAB l’unica cosa che può fare è generare un MAC random a 64 bit e sperare che sia quello corretto!

3a Soluzione – KAB in testa e in coda

• Altra possibilità è porre il segreto KAB sia in testa che in coda al messaggio m

• cioè il MAC è dato da MD(KAB|m|KAB)

– KAB in testa conferisce la resistenza alle collisioni

• anche nel caso in cui fossero noti, per l’algoritmo di digest MDdue messaggi con lo stesso digest

– KAB in coda rende innocua la vulnerabilità, degli algoritmi MD, esaminata in precedenza

4a Soluzione – HMAC

• HMAC (keyed-Hash Message Authentication Code) segue approssimativamente questo schema generale

• nel seguito sarà illustrato in dettaglio

– concatena il segreto KAB in testa al messaggio

– calcola il digest di tale combinazione

– concatena il segreto KAB in testa a tale digest

– calcola nuovamente il digest di quest’ultima combinazione

• HMAC applica due volte l’algoritmo di digest

Efficienza di HMAC

• HMAC è meno efficiente delle precedenti soluzioni

– deve effettuare due volte il calcolo del digest

• Tuttavia, il secondo digest può essere calcolato rapidamente

– l’input ha lunghezza contenuta: un segreto concatenato ad un digest

Cifratura/Decifratura tramite MD

• DOMANDA

– Come è possibile ottenere un algoritmo di cifratura/decifratura utilizzando un algoritmo di digest?

• un digest ha lunghezza fissa e non è invertibile!

• la decifratura deve essere l’inverso della cifratura!

Cifratura/Decifratura tramite MD

• RISPOSTA

– Si può realizzare un cifrario a flusso, utilizzando un algoritmo MD per generare un keystream (flusso di bit pseudorandom dipendente dalla chiave)

– In altri termini, si può procedere in modo simile a quanto visto per la modalità operativa OFB (Output Feedback Mode)

Generazione del flusso OTP

• Il one-time pad (keystream) è dato dalla sequenza

– OTP = OTP(K, IV) = b0|b1|b2|… |bi|bi+1|…

– dove

• b0 = MD(K, IV)

• b1 = MD(K, b0)

• …

• bi = MD(K, bi-1) K IV

OTP gen

OTP = b0|b1|b2|… m c = OTP m

Generaz. del flusso OTP – Osservazioni

• Valgono tutte le osservazioni viste per OFB

– OTP generabile in anticipo rispetto

• non è richiesta la conoscenza del messaggio

– se un avversario è in grado di indovinare il testo in chiaro (o una sua parte) potrebbe

• sommarlo ( XOR) al testo cifrato e

• aggiungere ( XOR) un qualsiasi messaggio ingannando il destinatario

– tale attacco all’integrità può essere rilevato applicando un controllo di integrità sicuro (MAC),

• tuttavia può anche essere evitato utilizzando una soluzione simile alla modalità operativa CFB (Cipher Feedback Mode)

OTP dipendente dal messaggio

– m = m0 m1 … mi mi+1 … blocchi di testo in chiaro – c = c0 c1 … ci ci+1 … blocchi di testo cifrato

– il one-time pad (keystream) è dato dalla sequenza – OTP = OTP(K, IV) = b0|b1|b2|… |bi|bi+1|… – dove

Testo in chiaro One-Time-Pad Testo cifrato

m0 b0 = MD(K, IV) c0 = m0 b0

m1 b1 = MD(K, c0) c1 = m1 b1

… … …

mi bi = MD(K, ci-1) ci = mi bi

Hash mediante cifratura

– Si è visto che, in linea di principio, un algoritmo di digest può sostituire un algoritmo di cifratura/decifratura a chiave segreta in tutte le sua applicazioni

– Naturalmente, vale anche il viceversa, cioè disponendo di un algoritmo di cifratura a chiave segreta è possibile ottenere un algoritmo di digest

Esempio – UNIX Password Hash

• UNIX usa un algoritmo di cifratura a chiave segreta per calcolare l’hash di una password d’utente – non memorizza le password in chiaro! – in fase di autenticazione, riapplica tale algoritmo alla

password inserita e verifica la corrispondenza con quella memorizzata Fase 1 pwd → Kpwd

a partire dalla password pwd viene calcolata una chiave segreta Kpwd

Fase 2

modified DES

064-bit

Kpwd

c = E(Kpwd, 064-bit)

UNIX Password Hash – Fase 1

• Kpwd si ottiene da pwd

– considerando i primi 8 caratteri di pwd

• i caratteri rimanenti sono ignorati

– la stringa di 56 bit ottenuta viene espansa a 64 bit inserendo i bit di parità per ogni gruppo di 7 bit

• la codifica dei caratteri è ASCII a 7 bit

UNIX Password Hash – Fase 2

– sia s il salt, numero di 12 bit generato in modo random, associato all’utente in esame la cui password è pwd

• h(pwd) si ottiene come segue – si considera una versione modificata di DES che

dipende dal valore del salt s • il valore di s determina quali bit devono essere replicati nella

fase di espansione di R da 32 a 48 bit

– l’algoritmo DES modificato è usato, con la chiave segreta Kpwd, per cifrare la costante 0 (a 64 bit) • UNIX memorizza per ciascun utente la stringa s|h(pwd) nel

file passwd

UNIX Password Hash – Algoritmo

• Ogni volta che una password pwd d’utente viene impostata – un numero random di 12 bit, il salt, viene

generato

– pwd viene convertita in una chiave segreta Kpwd a 64 bit

– l’algoritmo DES modificato, in base al valore di s, viene usato con la chiave Kpwd per cifrare la costante 0 (a 64 bit)

– il risultato e il salt vengono memorizzati nel file passwd

Hash di grandi messaggi

• UNIX password hash è un metodo per calcolare l’hash di messaggi corti (56 bit)

• Come è possibile calcolare l’hash di un messaggio di lunghezza arbitraria utilizzando un algoritmo di cifratura a chiave segreta?

Hash di grandi messaggi – Idea base

• m = m1 m2 m3 …

• mi è usato come chiave segreta nell’i-esimo blocco di cifratura

• l’input della cascata è una costante nota

• l’hash h(m) è l’output della cascata

encrypt

encrypt

constant

key

key

m1

m2

h(m)

Hash di grandi messaggi – Idea base

PROBLEMI

1. Se si desidera individuare un messaggio m avente un dato digest è possibile applicare un attacco simile a quello visto per DES doppio con chiavi distinte

2. h(m) può risultare troppo corto

– in genere la lunghezza di un blocco è di 64 bit 232 tentativi sono sufficienti per trovare due messaggi collidenti

encrypt

encrypt

constant

key

key

m1

m2

h(m)

Algoritmo di Hash migliorato

encrypt

encrypt

constant

key

key

m1

m2

h(m)

• Il problema 1. è risolvibile sommando ( XOR) l’input e l’output di ciascun round

• Riguardo al problema 2., – un hash di lunghezza doppia è

ottenibile calcolando

– un altro hash h’(m) con la stessa tecnica,

– ma partendo da una costante diversa

Bibliografia






Rainbow Tables

Luca Grilli,

Fabrizio Montecchiani

Funzioni di Hash sicure

• Una funzione hash h(∙) – riceve in input un messaggio m di lunghezza arbitraria, e – ritorna un output hm = h(m) di lunghezza prefissata (128 bit)

• Proprietà importanti di una funzione di hash (crittografica)

sicura 1. noto m è facile calcolare hm = h(m) 2. dato h, è difficile calcolare m tale che h = h(m) (one-way o

resistenza alla pre-immagine) 3. dato m, è difficile trovare m’≠ m tale che h(m) = h(m')

(resistenza alla seconda pre-immagine) 4. difficile trovare m, m’ tali che h(m) = h(m') (resistenza alle

collisioni) • le proprietà 3 implica la 2, ma non il contrario • la proprietà 4 implica la 3, ma non il contrario

Attacco Brute-Force

• Sia h:{0, 1}* → {0, 1}b una funzione crittografica di hash – K = 2b: cardinalità dello spazio dei possibili valori di hash

• Supponiamo che l'output distribuito in modo casuale in questo spazio

• Considerando un insieme di n stringhe

• Quanto deve valere n al fine di avere una probabilità > 0.5 che una stringa abbia un valore di hash dato?

n = ln 2 / (ln K – ln(K – 1))

• per K grande è circa n = (ln 2)∙K

Attacco Brute-Force

• Per una funzione hash a 128 bit, è necessario testare (ln 2)∙2128 possibili input (circa 1038) per ottenere una probabilità di 0.5 di ottenere un valore hash specificato

• 1038 microsecondi equivalgono a circa 1024 anni!

Compromesso Tempo-Memoria

• Si può pensare di ridurre il tempo di calcolo aumentando l’occupazione di memoria (o viceversa) – sembrerebbe più efficace effettuare un attacco brute-

force una prima volta,

– memorizzare il risultato in un hash database,

– quindi utilizzare questo database per accelerare il cracking su qualsiasi macchina

• Questo approccio richiederebbe memorie con capacità dell’ordine delle centinaia di Terabyte – limite ancora troppo elevato

Rainbow Tables

• Una rainbow table è una rappresentazione compatta che mira a ridurre le dimensioni di un hash database a una tabella molto più compatta, incrementando leggermente i tempi di calcolo

• Viene calcolato l’hash di tutte le password ma ne viene memorizzata solo una piccola parte

Rainbow Tables

• Siano h(∙) una funzione di hash e P un insieme finito di password

• L’obiettivo è di precalcolare una struttura dati tale che, – dato un qualsiasi output h della funzione hash,

– può individuare la password p in P tale che h(p) = h,

– oppure stabilire che non esiste una tale p in P

• Il modo più semplice per farlo è calcolare h(p) per ogni p in P – memorizzare la tabella richiede Θ(|P|b) bit di spazio,

– dove b è le dimensioni di un output di h(∙),

– proibitivo per grandi P

Funzione di Riduzione

• L'idea è di definire una funzione di riduzione r() che mappa a ritroso i valori di hash in valori di P

– esistono diverse possibili funzioni di riduzione pseudo-random

– una funzione di riduzione non è l’inverso di una funzione di hash!

Funzione di Riduzione

• Alternando

– la funzione di hash con

– la funzione di riduzione,

– possiamo formare catene alternate di password e valori di hash

Generazione

• Per generare una rainbow table: – scegliere un insieme iniziale casuale di password in P

– calcolare per ognuna di esse le catene di lunghezza fissa l

– memorizzare in tabella soltanto • la prima (startpoint) password e

• l’ultima (endpoint) password di ogni catena

• Esempio aaaaaa —h()→ 281DAF40 —r()→ sgfnyd —h()→

920ECF10 —r()→ kiebgt

Lookup e Inversione

• Per invertire un valore hash h* è necessario effettuare

– una prima fase detta di lookup

– una seconda fase detta di inversione

Lookup

1. Calcolare una catena a partire da h, applicando r() e h() alternativamente

2. Se in qualsiasi punto si osserva un valore corrisponde ad uno degli endpoint della tabella, recuperare il corrispondente startpoint

Inversione

1. Utilizzare lo startpoint trovato in fase di lookup per ricreare la catena

2. Se la catena prodotta contiene il valore h* allora il valore immediatamente precedente nella catena è la password p cercata

Esempio

• Hash h* = 920ECF10

• Lookup: calcoliamo la sua catena finché non troviamo un valore in tabella (un endpoint): 920ECF10 —r()→ kiebgt

– kiebgt è contenuto nella tabella con startpoint aaaaaa (vedi esempio

precedente)

• Inversione: ricostruiamo la catena partendo da aaaaaa: aaaaaa —h()→ 281DAF40 —r()→ sgfnyd —h()→ 920ECF10

• La password è sgfnyd

Falso Allarme

• La catena ricostruita non sempre contiene il valore hash h* – Esempio: h* = FB107E70

FB107E70 —r()→ bvtdll —h()→ 0EE80890 —r()→ kiebgt

– FB107E70 non è nella catena di aaaaaa (falso allarme)

• In questo caso, il match viene ignorato e si continua ad estendere la catena di h* in cerca di un altro match

• Se la catena di h* raggiunge la lunghezza l senza match buoni, la password non è mai stata prodotta in una delle catene e pertanto non può essere invertita

Proprietà

• Il contenuto della tabella non dipende dal valore hash da invertire – il contenuto viene creato una sola volta e riutilizzato in

ogni attacco senza alcuna modifica

• Aumentando la lunghezza delle catene si riducono le dimensioni della tabella – aumenta però il tempo richiesto per eseguire le

ricerche (compromesso tempo-memoria)

– nel semplice caso di catene di un elemento, la ricerca è molto veloce, ma la tabella è molto grande (hash database)

Collisioni

• Può accadere che in un qualsiasi punto due catene producano lo stesso valore (collision)

• Le due catene si fondono (merge) nel punto di collisione • di conseguenza la tabella coprirà un minor numero di

password – poiché le catene precedenti non sono memorizzate

completamente, – una collisione è impossibile da individuare in modo efficiente

• La funzione di hash h() genera raramente collisioni (collision-resistant) mentre la funzione di riduzione r() non è altrettanto robusta

Funzioni di Riduzione Multiple

• Per risolvere il problema delle collisioni è possibile utilizzare, – anziché una sola funzione di riduzione r(), – un insieme di funzioni r1()…rk() utilizzate

alternativamente

• In questo modo, perché due catene collidano e si

fondino, devono colpire lo stesso valore nella stessa iterazione – è ancora possibile avere delle collisioni, – ma che non comporteranno la fusione delle catene

Esempio

Lookup

• Poichè il valore hash di interesse può essere trovato in qualsiasi punto della catena, è necessario generare k catene diverse – La prima catena assume che il valore di hash sia nell’ ultima

posizione e applica soltanto rk()

– la seconda catena assume che il valore di hash sia nella penultima posizione e applica in sequenza rk-1(), h() e rk(),

– … – l'ultima catena applica tutte le funzioni di riduzione alternate

con h()

• Questo procedimento comporta che alcune catene possano essere prodotte e valutate inutilmente (false alarm)

Esempio

Debolezze

• La generazione richiede molto tempo

• Possono verificarsi molti false alarm

• Inefficiente con meccanismi di salt

– Lo spazio di ricerca cresce notevolmente superando i limiti di memoria attuali

Approfondimenti

• A Cryptanalitic Time-Memory Trade-Off, Martin E. Hellman

www-ee.stanford.edu/~hellman/publications/36.pdf

• Making a Faster Cryptanalytic Time-Memory Trade-Off, Philippe Oechslin

lasecwww.epfl.ch/~oechslin/publications/crypto03.pdf

http://www-ee.stanford.edu/~hellman/publications/36.pdf








http://lasecwww.epfl.ch/~oechslin/publications/crypto03.pdf

http://lasecwww.epfl.ch/~oechslin/publications/crypto03.pdf

LanManager Hash

UPPERCASE +

NULL PADDING / TRUNCATING

NT Lan Manager Hash

PWD MD4 HASH NT

(16B)

Rainbow Tables e LM Hash

L0pht Heavy Industries

• L0pht Heavy Industries è stato un collettivo di hacker attivo tra il 1992 e il 2000 e situato a Boston

• Durante la sua attività ha rilasciato numerosi avvisi relativi alla sicurezza informatica e prodotto strumenti software ampiamente utilizzati come L0phtCrack, un password cracker per OS Windows

• Il 19 maggio 1998, tutti i sette membri di L0pht (Brian Oblivion, Kingpin, Mudge, Space Rogue, Stefan Von Neumann, John Tan, Weld Pond) diedero una famosa testimonianza davanti al Congresso degli Stati Uniti, asserendo che avrebbero potuto “spegnere” l'intera rete Internet in 30 minuti

• Nel gennaio 2000, L0pht Heavy Industries si è fusa con la startup @stake, completando la lenta transizione da un'organizzazione underground a una società "whitehat" di sicurezza informatica. Symantec ha annunciato l'acquisizione di @stake il 16 settembre 2004, e completato l'operazione l'8 ottobre dello stesso anno

L0phtCrack

• L0phtCrack è un’applicazione per il recupero e il test di password originariamente prodotto da Mudge (L0pht Heavy Industries)

• Utilizza attacchi con dizionario, brute-force, e con rainbow tables

• E uno degli strumenti preferiti dagli hacker, specialmente le vecchie versioni (basso prezzo e alta disponibilità)

• Nel gennaio 2009 L0phtCrack è stato acquisito dagli autori originali Zatko (Mudge), Wysopal e Rioux da Symantec – L0phtCrack 6 è stato annunciato l’11 marzo 2009 alla

conferenza SOURCE Boston Conference

L0phtCrack 6

• Alcune features: – OS target

• Windows XP, Vista Seven (32 e 64 bit) • reti con Windows NT, 2000, XP, Server 2003, Server 2008 (32 e 64

bit) • varianti principali di BSD e Linux con demone SSH

– password scoring • punteggio basato su metrica per valutare rapidamente la qualità

delle password

– metodi per Password Audit • dizionario • hash DB precalcolato • brute force • rainbow tables

www.l0phtcrack.com

L0phtCrack e LM Hash

• La prima versione di l0phtCrack fu utilizzata per crackare l’algoritmo LM Hash

• LM Hash è stato mantenuto da Microsoft fino a Windows Vista per garantire la retrocompatibilità con i vecchi sistemi – Windows mantiene per ogni password sia la versione

ottenuta con LM Hash sia quella ottenuta con NT Hash

– se un attaccante riesce a crackare la versione LM Hash della password (ad esempio tramite rainbow tables) allora può sfruttare questa informazione per crackare anche la versione NTLM Hash


• Il cracking della versione LM Hash fornisce i primi 14 caratteri della password – per password di dimensioni maggiori i restanti

caratteri possono essere trovati per inferenza o con attacco brute-force

• L’algoritmo NT Hash è case-sensistive – una volta crackata la versione LM Hash della

password restano soltanto 2x possibili password, con x pari alla lunghezza della password

– x è un numero minore o uguale a 14 (al più 16384 tentativi)!

NTLM Protocol

• NTLM Protocol: protocollo Microsoft per l’autenticazione su dominio di tipo challenge-response introdotto con l’algoritmo NTLM Hash

NTLM Protocol

• Ogni volta che un utente richiede l’autenticazione su dominio entrambe le versioni della password (LM Hash e NTLM Hash) subiscono il seguente processo:

1. NULL padding fino a 21B

2. divisione dell’hash in 3 parti da 7B

3. ognuna delle 3 parti viene convertita in una chiave DES di 8B aggiungendo 1B di parità

4. con ogni chiave viene criptato un challenge di 8B inviato in chiaro in rete dal server di autenticazione

5. i 3 output ottenuti al passo precedente sono concatenati per formare un output finale di 24B che viene inviato in rete al server per verificare l’autenticazione


• Il meccanismo di challenge-response dovrebbe rendere più difficile il cracking

• In realtà l’ouput contiene informazione sfruttabile da un attaccante – solo 2B dell’hash originale (16B) finiscono nella

terza componente da 7B, il resto sono caratteri NULL noti

– solo l’ottavo byte della prima metà dell’hash originale finisce nella seconda componente da 7B


• Esempio: password di dimensione pari al più a 7 caratteri (scelta molto frequente per utenti non esperti)

– nella versione LM Hash il secondo gruppo da 7B è composto da soli caratteri NULL

– nella versione prodotta dall’NTLM Protocol i primi 8B corrispondono al challenge cifrato con l’LM Hash, non serve decriptare i restanti 16B!

Kerberos

• Microsoft ha adottato Kerberos come protocollo di autenticazione di defualt da Windows 2000 e per i domini Active Directory

• NTLMv2 è ancora utilizzato in diverse seguenti situazioni,

tra cui: – il cliente si autentica a un server che non appartiene a un

dominio – non esiste un dominio Active Directory (modalità

“workgroup"o "peer-to-peer") – nei casi in cui un firewall blocca le porte richieste da Kerberos

Ophcrack

• Ophcrack è un’applicazione open source per il recupero delle password di sistemi operativi Windows

• Si avvale di rainbow tables per crackare gli hash LM ed NTLM

• Sviluppata da Cedric Tissieres e Philippe Oechslin

Ophcrack

Xp Rainbow Tables

• XP free small (380MB) – Success rate: 99.9% – Charset: 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ

• XP free fast (703MB)

– Success rate: 99.9% – Charset: 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ

• XP special (7.5GB) – Success rate: 96% – Charset: 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~

• XP german (7.4GB) – Success rate: 99%

Only for passwords that contains at least one german character (äöüÄÖÜß) – Charset: 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~

äöüÄÖÜß

Vista Rainbow Tables

www.freerainbowtables.com

• L'obiettivo di FreeRainbowTables.com è quello di dimostrare l'insicurezza delle funzioni hash semplici

• DistrRTgen (Distributed Rainbow Table Generator): generazione distribuita di catene – è possibile generare rainbow tables enormi che sono

in grado di rompere password anche molto lunghe

– il client BOINC è disponibile dalla pagina di download del sito

Fonti

• Beautiful Security Leading Security Experts Explain How They Think, Andy Oram, John Viega , O'Reilly Media, 2009

• www.wikipedia.org

• www.l0phtcrack.com

• www.ophcrack.sourceforge.net

• www.freerainbowtables.com

http://www.wikipedia.org/

http://www.l0phtcrack.com/

http://www.ophcrack.sourceforge.net/

http://www.freerainbowtables.com/

Crittografia a Chiave Pubblica Parte I

Luca Grilli

INTRODUZIONE Crittografia a Chiave Pubblica – Parte I

Introduzione

• La crittografia a chiave pubblica si basa su alcuni risultati nell’ambito della teoria dei numeri

• Gli algoritmi di crittografia a chiave pubblica sono molto eterogenei e differiscono profondamente – non soltanto in come alcune funzioni vengono

eseguite, ma spesso in quali funzioni vengono eseguite • tutti gli algoritmi di hash “fanno la stessa cosa” – prendono

un messaggio ed eseguono una trasformazione irreversibile

• tutti gli algoritmi a chiave segreta “fanno la stessa cosa” – prendono un blocco, lo cifrano in modo reversibile e applicano dei metodi di concatenamento dei blocchi per cifrare dei messaggi generici

Introduzione

• Si esamineranno i seguenti schemi di cifratura a chiave pubblica – RSA e ECC, usati per cifrare e per calcolare la firma digitale

– ElGamal e DSS, usati per la firma digitale

– Diffie-Hellman, permette di stabilire un segreto condiviso, ma non fornisce alcun algoritmo che usa effettivamente tale segreto • potrebbe essere usato in congiunzione ad uno schema di cifratura

a chiave segreta

– Sistemi di dimostrazione a conoscenza zero (zero knowledge proof systems), usati soltanto per l’autenticazione

Introduzione

• L’unico aspetto comune a tutti gli algoritmi di crittografia a chiave pubblica è

– la presenza di due quantità correlate

• chiave segreta, chiave pubblica

– associate a ciascuna entità che partecipa ad una comunicazione cifrata

• spesso si usa il termine principal per denotare una siffatta entità, che può essere un calcolatore o una persona

ARITMETICA MODULARE Crittografia a Chiave Pubblica – Parte I

Aritmetica modulare

• La maggior parte degli algoritmi a chiave pubblica si basano sull’aritmetica modulare

• Fissato un interno n > 1, l’aritmetica modulare – considera l’insieme degli interi non negativi minori di

n: {0, 1, 2, …, n – 1}

– effettua operazioni ordinarie come l’addizione e la moltiplicazione, e

– sostituisce il risultato x con il resto r della divisione intera di x per n

– il risultato finale viene detto modulo n o mod n • “x mod n” significa dividi x per n e considera il resto

• qualche volta “mod n” è omesso se è chiaro dal contesto

Addizione modulare – mod 10

• Consideriamo l’addizione mod 10 – siano a e b due numeri minori di 10 – (a + b) mod 10 si ottiene

• effettuando l’addizione ordinaria, e • considerando come risultato finale la cifra meno significativa; cioè

il resto della divisione per 10 + 0 1 2 3 4 5 6 7 8 9

0 0 1 2 3 4 5 6 7 8 9

1 1 2 3 4 5 6 7 8 9 0

2 2 3 4 5 6 7 8 9 0 1

3 3 4 5 6 7 8 9 0 1 2

4 4 5 6 7 8 9 0 1 2 3

5 5 6 7 8 9 0 1 2 3 4

6 6 7 8 9 0 1 2 3 4 5

7 7 8 9 0 1 2 3 4 5 6

8 8 9 0 1 2 3 4 5 6 7

9 9 0 1 2 3 4 5 6 7 8


• Sia m (< 10), un qualche messaggio – l’addizione di una costante k mod 10 può

riguardarsi come una cifratura a chiave segreta • ogni cifra decimale m viene mappata in una diversa

cifra decimale c = (m + k) mod 10 in modo reversibile

• k è la chiave segreta; chiaramente si tratta di un pessimo cifrario (è il cifrario di Cesare)

• la decifratura consiste nel sottrarre k mod 10; cioè va sottratto k e se il risultato è minore di 0, va aggiunto 10

• come nell’aritmetica ordinaria, sottrarre k equivale a sommare -k, cioè l’inverso additivo di k


• un inverso additivo di k è un numero che sommato a k dà 0; formalmente (k + (-k)) = 0 mod 10

• ad esempio, l’inverso additivo di 4 è 6 perché 4 + 6 = 0 nell’aritmetica modulo 10

Moltiplicazione modulare – mod 10

• Si consideri la tabella della moltiplicazione mod 10 – la moltiplicazione mod 10 per una costante k {1, 3, 7, 9}

può riguardarsi come una cifratura a chiave segreta • produce una permutazione dell’input

• la moltiplicazione per ogni altro numero invece non funziona

∙ 0 1 2 3 4 5 6 7 8 9

0 0 0 0 0 0 0 0 0 0 0

1 0 1 2 3 4 5 6 7 8 9

2 0 2 4 6 8 0 2 4 6 8

3 0 3 6 9 2 5 8 1 4 7

4 0 4 8 2 6 0 4 8 2 6

5 0 5 0 5 0 5 0 5 0 5

6 0 6 2 8 4 0 6 2 8 4

7 0 7 4 1 8 5 2 9 6 3

8 0 8 6 4 2 0 8 6 4 2

9 0 9 8 7 6 5 4 3 2 1

Ad esempio, se si prova a cifrare moltiplicando per 5, metà dei numeri sarebbero cambiati in 0 e l’altra metà in 5

ciò comporta una perdita di informazione; la trasformazione non è invertibile

è impossibile decifrare

Moltiplicazione modulare – mod 10

• Pertanto, la moltiplicazione mod 10 può essere usata per cifrare – a condizione che il fattore k sia scelto in modo

opportuno

• La decifratura può essere eseguita, analogamente al caso dell’addizione, moltiplicando per l’inverso moltiplicativo di k – nell’aritmetica ordinaria l’inverso moltiplicativo di k è

1/k in generale 1/k è una quantità frazionaria

– ma nell’aritmetica modulare si considerano solo numeri interi

Inverso moltiplicativo mod n

• L’inverso moltiplicativo di k, scritto k-1, è quel numero che moltiplicato per k dà 1 – (k∙k-1) mod 10 = 1 mod 10

– in generale, (k∙k-1) mod n = 1 mod n

• Si osservi che per un dato n, non tutti i numeri hanno un inverso moltiplicativo mod n – solo i numeri {1, 3, 7, 9} hanno gli inversi moltiplicativi

mod 10 • ad esempio, 7 è un inverso moltiplicativo di 3 la cifratura

può ottenersi moltiplicando per 3 e la decifratura può ottenersi moltiplicando per 7

• 9 è un inverso di se stesso; 1 è un inverso di se stesso


• Si osservi inoltre che – se k ammette un inverso moltiplicativo mod n

esiste un unico inverso moltiplicativo k-1 < n • ad esempio, il numero 7 ammette i seguenti inversi

moltiplicativi mod 10 {3, 13, 23, 33, …, 3 + i∙10, …},

• ma soltanto 3 è l’inverso moltiplicativo strettamente minore di 10

• Ovviamente, la moltiplicazione mod n di per sé non costituisce un cifrario sicuro – ma funziona, nel senso che la moltiplicazione per k

produce un mescolamento dell’input; la decifratura può ottenersi moltiplicando per k-1


• Trovare un inverso moltiplicativo k-1 nella aritmetica mod n, non è affatto banale se n è molto grande – ad esempio, se n è un intero a 100 cifre un approccio a

forza bruta sarebbe impraticabile

• Esiste un modo efficiente per risolvere tale problema, noto come algoritmo di Euclide – dati x ed n (x < n), l’algoritmo di Euclide trova il

numero y < n tale che (x∙y) mod n = 1

– ammesso che un siffatto y esista

Numeri relativamente primi

• DOMANDA – Per quale motivo soltanto i numeri {1, 3, 7, 9} ammettono un

inverso moltiplicativo mod 10? – Quali numeri ammettono un inverso moltiplicativo mod 10?

• RISPOSTA: sono tutti e soli i numeri (minori di 10) relativamente primi con 10

• Due numeri sono relativamente primi se l’unico fattore comune è 1

equivalentemente, • Due numeri interi a e b sono relativamente primi se

MCD(a, b) = 1 – MCD Massimo Comun Divisore, o – GCD Greatest Common Divisor

Funzione totiente ϕ di Eulero

– in generale, nell’aritmetica mod n, tutti gli interi (positivi) x relativamente primi con n ammettono un inverso moltiplicativo x-1

– se n è un numero primo tutti gli interi positivi x < n ammettono un inverso moltiplicativo (mod n) x-1

• Dato un intero n > 1

• Si definisce funzione ϕ di Eulero, o funzione totiente, la funzione che associa ad n il numero ϕ(n) degli interi positivi i ≤ n e relativamente primi con n – cioè ϕ(n) = |{0 < i ≤ n: MCD(i, n) = 1}|

– per convenzione ϕ(0) = 0

Security token

Funzione totiente ϕ di Eulero

• Se n è primo tutti gli interi {1, 2, …, n – 1} sono relativamente primi con n ϕ(n) = n – 1

• DOMANDA: Se n = p∙q, ove p e q sono due numeri primi maggiori di 1, quanto vale ϕ(n)?

• RISPOSTA: – ϕ(n) = |N<n – (Mp Mq)| =

= |N<n| – |Mp| – |Mq| + |Mp Mq|

– dove • N<n = {1, 2, …, n – 1, n}

• Mp = {p∙1, p∙2, …, p∙(q – 1), p∙q} N<n

• Mq = {1∙q, 2∙q, …, (p – 1)∙q, p∙q} N<n

• Mp Mq = {p∙q}

– ϕ(n) = p∙q – q – p + 1 = p(q – 1) – q + 1 = (p – 1)(q – 1)

Esponenziazione modulare

• L’esponenziazione modulare, o elevamento a potenza modulare, è simile a quella ordinaria – si esegue l’esponenziazione ordinaria e si considera il resto

della divisione per n • ad esempio, 46 = 6 mod 10 perché 46 = 4096 e 4096 = 6 mod 10

xy 0 1 2 3 4 5 6 7 8 9 10 11 12

0 0 0 0 0 0 0 0 0 0 0 0 0

1 1 1 1 1 1 1 1 1 1 1 1 1 1

2 1 2 4 8 6 2 4 8 6 2 4 8 6

3 1 3 9 7 1 3 9 7 1 3 9 7 1

4 1 4 6 4 6 4 6 4 6 4 6 4 6

5 1 5 5 5 5 5 5 5 5 5 5 5 5

6 1 6 6 6 6 6 6 6 6 6 6 6 6

7 1 7 9 3 1 7 9 3 1 7 9 3 1

8 1 8 4 2 6 8 4 2 6 8 4 2 6

9 1 9 1 9 1 9 1 9 1 9 1 9 1

si osservi che nell’esponenziazione modulare xy mod n è diverso da xy+n mod n ad esempio, 31 = 3 mod 10, ma 311 = 7 mod 10 (311 = 177147)

Esponenziazione modulare – mod 10

• Dalla precedente tabella, che illustra l’esponenziazione mod 10, si osserva che – l’esponenziazione per 3 (quarta colonna) può

considerarsi una cifratura • determina un mescolamento dell’input

– l’esponenziazione per 2 invece no • alcuni input scompaiono non è iniettiva

– quando l’esponenziazione è iniettiva, la decifratura può ottenersi ricorrendo al logaritmo discreto (inverso dell’esponenziazione) • come nel caso della moltiplicazione, nell’esponenziazione

modulare non tutti i numeri ammettono un logaritmo discreto


• Esaminando la tabella di esponenziazione mod 10 si nota un periodicità – per ogni i > 0, le colonne i e i + 4 coincidono, cioè

– per ogni i > 0, xi mod 10 = xi + 4 mod 10

• In effetti, si può dimostrare il seguente risultato

• Sia n > 1 un intero privo di quadrati (square free), allora per ogni y > 0,

xy mod n = x(y + ϕ(n)) mod n – un intero è privo di quadrati se non compaiono fattori

al quadrato nella sua scomposizione in fattori primi


• ad esempio, 10 è privo di quadrati essendo 10 = 21 ∙ 51

• un numero primo è sempre privo di quadrati

– nel caso n = 10, i numeri relativamente primi a 10 sono {1, 3, 7, 9} ϕ(n) = 4

• Dalla precedente relazione risulta che

– se y = 1 mod ϕ(n)

– xy mod n = x mod n

– quest’ultimo risultato è sfruttato dall’algoritmo RSA

RSA Crittografia a Chiave Pubblica – Parte I

RSA – Introduzione

• RSA è un algoritmo di cifratura (a blocchi) a chiave pubblica – il nome deriva degli inventori Rivest, Shamir e

Adleman

– la lunghezza della chiave è variabile • ciò consente di ottenere il giusto compromesso

sicurezza/efficienza

• solitamente si considerano chiavi di lunghezza 512 bit

– anche la lunghezza dei blocchi è variabile • un blocco di testo in chiaro deve avere una lunghezza

inferiore a quella della chiave

• un blocco di testo cifrato è lungo come la chiave

RSA – Introduzione

• RSA è computazionalmente molto più lento degli algoritmi a chiave segreta più popolari come DES e IDEA

– difficilmente viene usato per cifrare messaggi lunghi

– generalmente viene usato per cifrare una chiave segreta K, il messaggio viene poi cifrato con K usando un algoritmo a chiave segreta

Algoritmo RSA

• L’algoritmo RSA può essere impiegato – sia per cifrare/decifrare messaggi

– sia per la firma digitale di messaggi

• In entrambi i casi è necessario disporre della coppia – chiave pubblica, chiave privata = PU, PR

• tale coppia deve essere generata in modo opportuno

• Nelle prossime slide si esaminerà la 1. generazione di una coppia PU, PR

2. cifratura/decifratura RSA

3. firma digitale RSA

Generazione di PU, PR

1. Scegliere due numeri primi grandi p e q (circa 256 bit ciascuno); porre n = p ∙ q – è fondamentale che p e q rimangano segreti

– si noti che fattorizzare n è impraticabile

2. Scegliere un numero e che sia relativamente primo rispetto a ϕ(n) = (p – 1)(q – 1)

3. La chiave pubblica è PU = e, n

4. Calcolare l’inverso moltiplicativo d di e mod ϕ(n) – cioè d è tale che (d∙e) mod ϕ(n) = 1

5. La chiave privata è PR = d, n

Cifratura/decifratura RSA

– Sia PU = e, n la chiave pubblica del destinatario del messaggio cifrato e sia PR = d, n la sua chiave privata

– Sia m (< n) un messaggio da cifrare

• CIFRATURA: il mittente, chiunque sia, usando la chiave pubblica PU del destinatario calcola il testo cifrato

c = me mod n

• DECIFRATURA: il destinatario usando la propria chiave privata PR decifra c nel seguente modo

m = cd mod n

Firma digitale RSA

– Sia PR = d, n la chiave privata del firmatario del messaggio e sia PU = e, n la sua chiave pubblica

– Sia m (< n) un messaggio o un piccolo blocco di dati che è funzione del messaggio

• FIRMA: il firmatario usando la propria chiave privata PR calcola la firma digitale s

s = md mod n

• VERIFICA: chiunque desidera verificare l’autenticità della firma, usando la chiave pubblica PU del firmatario verifica che

m = se mod n

Alcune domande

• Di seguito si risponderà alle seguenti domande

– Perché RSA funziona?

• Decifrando un messaggio cifrato si ottiene il messaggio in chiaro?

– Perché RSA è sicuro?

• Dati e ed n, perché non è possibile risalire a d?

– Le operazioni di cifratura, decifratura, firma, e verifica della firma sono tutte sufficientemente efficienti da essere realizzabili nella pratica?

– Come è possibile ottenere numeri primi grandi?

Perché RSA funziona

• Mostriamo che – se c = E(PU, m) m = D(PR, c) = D(PR, E(PU, m))

• si sfrutteranno le seguenti proprietà – se m < n m mod n = m

– (xa mod n)b mod n = (xa)b mod n = xab mod n

– (e ∙ d) mod ϕ(n) = 1

• PROVA – c = E(PU, m) = me mod n

– m = D(PR, c) = cd mod n = (me mod n)d mod n = (me)d mod n = med mod n = m(1 mod ϕ(n)) mod n = m mod n = m

• la prova di correttezza della verifica della firma è analoga

Perché RSA è sicuro?

• Non esistono prove formali di sicurezza

– ci si affida al Fundamental Tenet of Cryptogtaphy

• molte persone intelligenti hanno tentato di violarlo, ma hanno fallito

– la sicurezza di RSA risiede nel fatto che fattorizzare interi molto grandi è impraticabile

• se esistesse un metodo veloce per fattorizzare interi molto grandi, allora nota la chiave pubblica PU = e, n si potrebbe ottenere la chiave privata PR = d, n

• infatti, identificando i numeri primi p e q tali che n = p ∙ q

• si ottiene facilmente ϕ(n) = (p – 1)(q – 1) e quindi si può calcolare d come l’inverso moltiplicativo di e modulo ϕ(n)


– tuttavia non si possono escludere altri metodi di violazione di RSA che non richiedono la fattorizzazione

– sebbene RSA è ritenuto sicuro, per chiavi di almeno 256 bit, è possibile utilizzarlo in modo improprio! • si supponga che Carol spedisca un messaggio ad Alice

contenente il nome del suo fidanzato segreto

• Bob geloso, sa del messaggio di Carol ad Alice e sa che il fidanzato è uno dei 15 ragazzi del corso di Sicurezza Informatica

• Bob non può decifrare il messaggio,

• ma può cifrare il nome di ogni ragazzo del corso di Sicurezza Informatica con la chiave pubblica di Alice e

• verificare quale di questi coincide con il messaggio inviato da Carol


• DOMANDA: assumendo che Bob intercetti il messaggio di Carol, è possibile impedirgli di ottenere informazioni?


• Nel seguito si discuterà come usare RSA in modo appropriato – per il momento una possibile risposta alla

precedente domanda è la seguente

• RISPOSTA – Carol può concatenare il nome del suo fidanzato

con un numero random molto grande, diciamo a 64 bit

– Bob anziché 15 tentativi deve fare 15 ∙ 264 tentativi!

Efficienza delle operazioni di RSA

• In base al tipo di impiego, RSA svolge le seguenti operazioni molto frequentemente (ad ogni sessione di lavoro) – cifratura, – decifratura, – generazione di una firma digitale e – verifica di una firma digitale – è necessario pertanto che tali operazioni siano svolte

nel modo più efficiente possibile

• Invece, l’operazione di generazione delle chiavi viene eseguita meno frequentemente – si può tollerare una minore efficienza

Esponenziazione di grandi numeri

• Le operazioni di cifratura, decifratura, firma e verifica della firma richiedono tutte di dover – considerare un intero molto grande, – elevarlo ad un esponente (intero) molto grande, e – trovare il resto della divisione intera per un numero molto

grande

• Considerando la dimensione dei numeri interi per i quali RSA è ritenuto sicuro tali operazioni risulterebbero proibitive se eseguite nel modo più ovvio – le prossime slide illustrano come è possibile aumentare la

velocità dei calcoli

Esempio – calcolo di 12354 mod 678

– assumendo di disporre di un software per la gestione dell’aritmetica a precisione multipla

• La soluzione più ovvia è – moltiplicare 54 volte 123 per se stesso

• ottenendo un prodotto enorme (circa 100 cifre decimali)

– e poi dividere per 678 per ottenere il resto • un computer potrebbe farlo con facilità

• Tuttavia, per essere sicuro RSA richiede che i numeri siano di 150 cifre! – elevare un numero di 150 cifre ad un esponente anch’esso di

150 cifre è computazionalmente impraticabile • un calcolo di questo tipo esaurirebbe le capacità di tutti i computer

esistenti per un tempo superiore al tempo di vita previsto dell’universo

• Per fortuna esiste un metodo molto più efficiente


• Per evitare di ottenere numeri enormi – conviene effettuare una riduzione modulare di ogni

prodotto intermedio; si noti che valgono le seguenti • (a ∙ b) mod n = ((a mod n ) ∙ (b mod n )) mod n

• (a ∙ b) mod n = (a ∙ (b mod n )) mod n

– si può procedere nel seguente modo • 1232 = 123 ∙ 123 = 15129 = 213 mod 678

• 1233 = 123 ∙ 213 = 26199 = 435 mod 678

• 1234 = 123 ∙ 435 = 53505 = 621 mod 678

• …

• 12353 = 123 ∙ 567 = 69741 = 585 mod 678

• 12354 = 123 ∙ 585 = 71955 = 87 mod 678


– è necessario effettuare 54 moltiplicazioni e 54 divisioni di piccoli (< 678) numeri interi

– è ancora una soluzione impraticabile

• considerata la dimensione degli esponenti usati in RSA

– tuttavia, esiste un metodo per migliorare ulteriormente l’efficienza

• si supponga per semplicità che l’esponente sia una potenza di 2, ad esempio 32 = 25

• la potenza a32 può essere ottenuta calcolando 5 potenze al quadrato in cascata

• a32 = ((((a2 mod n)2 mod n)2 mod n)2 mod n)2 mod n


– nel caso generale in cui l’esponente non è una potenza di 2, ad esempio 54, si può tener conto delle seguenti osservazioni • noto ax a2x è ottenibile da ax come segue

a2x = (ax)2 mod n = (ax mod n)2 mod n

• mentre a2x+1 è ottenibile da a2x come segue

a2x+1 = ((a2x) ∙ a) mod n = ((a2x mod n) ∙ a) mod n

– inoltre, la rappresentazione binaria di 54 (110110)2 fornisce • la corretta sequenza di potenze al quadrato e di

moltiplicazioni (per la base 123)

• da effettuare in cascata per ottenere 12354

12354 – cascata di pot. e molt.

1 ( )2 ∙b ( )2 ( )2 ( )2 ∙b ∙b ( )2

0

87 mod 678

1 1 0 1 1 0 codifica binaria di 54

( )2

∙b

LEGENDA

eleva al quadrato la base ed effettua la riduzione modulare

moltiplica per la base 123 ed effettua la riduzione modulare

INPUT OUTPUT

∙2 +1 ∙2 ∙2 ∙2 +1 +1 ∙2 ∙2 +1

( )2 ∙b

54


– in definitiva, per effettuare l’esponenziazione di una base ad un esponente

• si parte da un valore iniziale tmp = 1, e

• si scandisce l’esponente, bit a bit, dal bit più significativo a quello meno significativo

• per ciascun bit considerato si eleva al quadrato il valore corrente di tmp

• se il bit è 1 si moltiplica anche per la base

• chiaramente, dopo ogni operazione si esegue la riduzione modulare


– con la tecnica appena illustrata il calcolo di 12354 richiede di fatto 8 moltiplicazioni e 8 divisioni, ma soprattutto

– il numero di moltiplicazioni e divisioni cresce linearmente con il numero di bit dell’esponente e non con il suo valore

• e = 2Nb – 1 ove Nb = numero bit dell’esponente

– con questa tecnica RSA è sufficientemente efficiente da poter essere usato

Generazione delle chiavi RSA

• La generazione delle chiavi RSA è un’operazione poco frequente – in gran parte delle applicazioni della tecnologia a chiave

pubblica deve essere eseguita soltanto una volta • ad esempio quando un impiegato viene assunto

– non è richiesta la stessa efficienza delle altre operazioni RSA; deve comunque essere garantita un’efficienza “ragionevole”

• Per generare una coppia di chiavi PU, PR è necessario – trovare due numeri primi p e q molto grandi, e

– trovare due interi d ed e con le proprietà precedentemente descritte

Trovare due numeri primi grandi p e q

– esistono infiniti numeri primi; tali numeri tendono però a diradarsi sempre più al crescere di n

• estraendo n a caso Pr{n è primo} ≈ 1 / ln n

• Pr{n è primo} ≈ 1 / Nb ove Nb denota il numero di bit di n

• la densità dei numeri primi è inversamente proporzionale alla loro lunghezza in bit (o in cifre decimali)

• per un numero n a dieci cifre decimali (dimensione usata in RSA) c’è una possibilità su 230 di essere primo


• Pertanto p e q sono generati con la seguente strategia 1. estrai un numero dispari molto grande

2. verifica se è primo, in caso negativo ritenta

– mediamente sono necessari 230 tentativi per trovare un numero primo

• tale strategia è praticabile solo se si dispone di un test di primalità efficiente

• Come è possibile testare se un intero n è primo? – un metodo banale consiste nel dividere n per tutti gli

interi ≤ n1/2 e verificare che non ci sono divisori > 1, ma ciò richiederebbe diverse vite dell’universo!


• prima del 2002 non esisteva un test di primalità polinomiale

• nel 2002 è stato pubblicato il test di primalità deterministico AKS

– RSA usa un test di primalità probabilistico

• non si può affermare con certezza che l’esito del test è corretto

• tuttavia, la probabilità di errore può essere resa arbitrariamente piccola aumentando il tempo di test

• il test si basa sul teorema di Fermat che fornisce una condizione necessaria affinché un intero n sia primo

• se n è primo per ogni intero a risulta an – 1 = 1 mod n

• non vale però il viceversa, esistono degli interi a per i quali l’uguaglianza è verificata anche se n è non primo

Test di primalità probabilistico

• Dato un intero n, un possibile test di primalità è il seguente – 1) scegliere un intero a < n

– 2) calcolare an-1 mod n

– 3a) se il risultato è diverso da 1 n è certamente non primo

– 3b) se il risultato è 1 n potrebbe essere primo, ma potrebbe anche non esserlo • è stato dimostrato che se n è un intero random di circa

cento cifre decimali la probabilità di un falso positivo è di circa 10-13


– si osservi che un errore nel test di primalità può rendere • impossibile la decifratura RSA di un messaggio

• più facile l’identificazione della chiave privata

– se una probabilità di errore pari a 10-13 non è ritenuta sufficiente si possono effettuare più test con diversi valori di a • Pr{falso positivo dopo k test} = (10-13)k

• la probabilità di errore può essere resa arbitrariamente piccola, ma non sempre la vita è così semplice!

• ci possono essere dei casi veramente sfortunati non rilevabili dal test, ciò accade se n è un numero di Carmichael


• un numero n è un numero di Carmichael se è non primo e se per ogni a < n risulta an-1 = 1 mod n

• i numeri di Carmichael sono sufficientemente rari che è estremamente improbabile estrarli a caso

• tuttavia, a fronte di un piccolo costo computazionale aggiuntivo

• è possibile migliorare il test di primalità precedente introducendo altri controlli che permettono di rilevare con maggior probabilità se n è non primo

• un test molto efficace è il test di primalità di Miller e Rabin

Test di primalità di Miller e Rabin

• Sfrutta un ulteriore CN di primalità: – se n è primo le uniche radici quadrate modulo

n di 1 sono 1 e -1 (si noti che -1 = n – 1 mod n) • cioè, se a è un intero tale che a2 mod n = 1

• deve essere a = 1 oppure a = -1

• in caso contrario si desume che n è non primo

– tali controlli sulle radici quadrate vengono eseguiti nei risultati intermedi necessari al calcolo di an-1 mod n per il test precedente • a tale scopo viene sempre espresso n – 1 come 2bc ove

c è un numero dispari

• il test precedente diventa a^(2bc) mod n = 1


– il test sulle radici quadrate mod n di 1 permette di aumentare notevolmente la capacità di individuare dei falsi positivi

• se n è non primo (anche se è un numero di Carmichael) almeno ¾ di tutti i possibili valori di a permettono di rilevarlo

• l’esecuzione del test con diversi valori di a permette di ridurre a piacere la probabilità di errore; anche nel caso in cui n è un numero di Carmichael


1. Sia n un numero dispari.

2. Testare se n è divisibile per qualche numero primo piccolo. In caso affermativo tornare al punto 1. (tale step non è strettamente

necessario, ma vale la pena eseguirlo perché può rilevare un numero non primo con buona probabilità)

3. Ripetere i seguenti step arrestandosi quando si prova che n è non primo oppure dopo un numero di volte ritenute sufficienti a considerare n primo con elevata probabilità.

3.1 Scegliere randomicamente un numero a.

3.2 Calcolare ac mod n (dove c è il numero dispari tale che n – 1 = 2bc) eseguendo una sequenza di potenze al quadrato e/o moltiplicazioni per la base a.


Ad ogni elevamento al quadrato controllare se il risultato è 1. Se sì, controllare se il numero elevato al quadrato (cioè la radice quadrata mod n di 1) era pari a 1; in caso negativo, n è non primo.

3.3 Se ac mod n è pari a 1, n supera il test di primalità per questo valore di a.

3.4 Altrimenti, ac mod n ≠ 1, al più b – 1 volte, sostituisci il risultato con il suo quadrato e verifica se si ottiene 1. Se si ottiene 1, n è non primo (perché il precedente risultato è una radice quadrata di 1 diversa da 1). Se si ottiene -1, n supera il test di primalità per questo valore di a.


Se sono state eseguite b – 1 potenze al quadrato, n è non primo (perché a(n – 1)/2 è diverso da 1)

Calcolo di d ed e

• Gli interi d ed e sono definiti nel seguente modo

– e è un qualunque numero relativamente primo rispetto all’intero ϕ(n) = (p – 1)(q – 1)

– d è l’intero tale che (e ∙ d) mod ϕ(n) = 1

– noto e, d si calcola con l’algoritmo di Euclide

Calcolo di d ed e

– esistono due possibili strategie per il calcolo di e

1. Una volta ottenuti p e q • scegliere e randomicamente e

• testare se e e (p – 1)(q – 1) sono relativamente primi

• in caso negativo, selezionare un altro valore per e

2. Non selezionare prima p e q, invece • scegliere prima e

• poi selezionare p e q in modo tale che (p – 1) e (q – 1) sono relativamente primi rispetto ad e

• nelle slide seguenti si illustrerà per quale motivo la strategia 2. è conveniente e come è possibile attuarla

Come scegliere e

• La sicurezza di RSA non diminuisce (per quanto ad oggi noto) se e è sempre scelto allo stesso modo – si noti che d continua ad essere imprevedibile se p e q

non sono noti • d oltre a dipendere da e dipende anche da p e da q

– se e è un intero piccolo o facile da calcolare le operazioni di cifratura e di verifica della firma diventano più efficienti • cioè le operazioni che richiedono l’uso della chiave pubblica

PU = e, n sono più veloci, mentre

• risulta invariata l’efficienza delle operazioni che richiedono la chiave privata PR = d, n

Come scegliere e

• chiaramente, diversamente da e, non si può assegnare a d un valore piccolo

• sebbene ciò renderebbe molto più veloci le operazioni che usano la chiave privata PR, la sicurezza di RSA verrebbe meno; un avversario potrebbe identificare PR con una semplice ricerca!

• Generalmente si assegna ad e uno dei seguenti valori

e = 3

e = 65537

Perché e = 3?

• La scelta e = 3 è quella che assegna ad e il più piccolo valore possibile

– 2 non va bene perché non è relativamente primo con (p – 1)(q – 1) che è un numero pari

– 3 può funzionare

• il calcolo di m3 mod n richiede soltanto due moltiplicazioni un esponente pubblico pari a 3 massimizza le prestazioni

• per quanto ad oggi noto, la sicurezza di RSA non è indebolita se vengono messi in essere degli opportuni accorgimenti pratici

• nelle prossime slide si esaminerà quali rischi si corrono se e = 3 e come sia possibile far fronte a tali rischi

e = 3 – vulnerabilità/patch

• La scelta di e = 3 comporta le seguente vulnerabilità – se il messaggio m da cifrare rappresenta un intero

piccolo, in particolare se m è inferiore alla radice cubica ordinaria di n: m < n1/3

– c = me mod n = m3 mod n = m3

– un avversario può decifrare c senza conoscere la chiave privata; semplicemente estraendo la radice cubica ordinaria di c: m = c1/3

– tale vulnerabilità può essere rimossa eseguendo un padding random del messaggio tale che m3 > n • ciò garantisce che m3 viene sempre ridotto mod n


• Un’altra vulnerabilità si ha se – uno stesso messaggio m viene inviato cifrato – a tre o più destinatari aventi un esponente pubblico e

= 3 – il messaggio in chiaro m può essere decifrato

conoscendo soltanto • i tre messaggi cifrati c1, c2 e c3 e • le tre chiavi pubbliche 3, n1 , 3, n2 e 3, n3

• PROVA – si supponga che un avversario intercetti tre cifrature

dello stesso messaggio m – c1 = m3 mod n1 c2 = m3 mod n2 c3 = m3 mod n3


– conoscendo anche le tre chiavi pubbliche dei destinatari 3, n1 , 3, n2 e 3, n3

– e utilizzando il teorema cinese del resto, l’avversario può calcolare m3 mod n1 n2 n3

– essendo m < ni per i = 1, 2, 3 m3 < n1 n2 n3

– m3 mod n1 n2 n3 = m3

– l’avversario può risalire ad m estraendo una radice cubica ordinaria

– anche questa vulnerabilità può essere rimossa mediante un padding random • in pratica si evita che uno stesso messaggio cifrato venga

inviato a più destinatari


– Si osservi che nelle applicazioni pratiche di RSA, • il messaggio m è generalmente una chiave di un

algoritmo di cifratura a chiave segreta e

• in ogni caso m è molto più piccolo di n

• è sempre possibile aggiungere dei bit di riempimento (padding) in modo tale che il messaggio risultante presenti delle caratteristiche desiderate

• se per ogni destinatario il padding scelto è random la precedente vulnerabilità viene rimossa

• la vulnerabilità può essere rimossa anche usando come padding gli identificatori univoci (ID) dei destinatari

Come scegliere p e q se e = 3

• Essendo e = 3, – come è possibile selezionare p e q garantendo che

e e ϕ(n) siano relativamente primi?

– è necessario garantire che (p – 1) e (q – 1) siano relativamente primi rispetto a 3

– ciò può ottenersi • scegliendo p tale che p mod 3 = 2, e

• scegliendo q tale che q mod 3 = 2

• (p – 1) mod 3 = 1 (p – 1) non è divisibile per 3

• (q – 1) mod 3 = 1 (q – 1) non è divisibile per 3

Come scegliere p e q se e = 3

– essendo p e q due interi dispari

• p = 2kp + 1

• q = 2kq + 1

– per imporre anche che risulti

• p mod 3 = 2

• q mod 3 = 2

– si può porre

• p = (2kp + 1)∙3 + 2 = 6kp + 5

• q = (2kq + 1)∙3 + 2 = 6kq + 5

– dopodiché può essere effettuato il test di primalità

Perché e = 65537?

• La scelta di e = 65537 • (in opposizione ad altri interi della stessa dimensione)

– deriva dal fatto che 65537 = 216 + 1 ed è primo

– (65537)2 = 10000000000000001

– l’esponenziazione richiede 17 moltiplicazioni

• è più lenta del caso e = 3, ma

• è molto più veloce del caso in cui e è scelto in modo randomico; mediamente sono richieste 768 moltiplicazioni nel caso di 512 bit

– non presenta le vulnerabilità viste nel caso e = 3

e = 65537 introduce vulnerabilità?

• La scelta di e = 65537 rimuove o riduce quasi del tutto le vulnerabilità viste nel caso e = 3

– la prima vulnerabilità con 3 si ha se m3 < n

– nel caso e = 65537

• a meno che n non sia molto più lungo di 512 bit

– non ci sono molti valori di m tali che m65537 < n

– quindi l’estrazione della 65537-esima radice ordinaria di m non costituisce una vulnerabilità seria

e = 65537 – vantaggi/svantaggi

– la seconda vulnerabilità con 3 si ha se uno stesso messaggio m cifrato è inviato a 3 destinatari

– nel caso e = 65537 la stesso tipo di vulnerabilità si ha quando m viene inviato a 65537 destinatari! • non si può dire certo che si tratti i un messaggio segreto!

– in fine, la scelta di fissare a priori e = 3 ha richiesto di scegliere n in modo tale che ϕ(n) e 3 fossero relativamente primi

– nel caso e = 65537 conviene • generare p e q come se e non fosse prefissato, e

• rigettare ogni valore di p o q che è uguale a 1 mod 65537

• tale evento si verifica con una probabilità molto piccola (2-16)

Vulnerabilità “arcane” di RSA

• Nel caso della firma digitale risulta che

– per ogni numero x < n

– x è la firma digitale del messaggio mx = xe mod n

• infatti, mxd mod n = (xe mod n)d mod n = xed mod n =

• = x(1 mod ϕ(n)) mod n = x mod n = x

– è banale falsificare la firma di qualcuno se il messaggio m da firmare non interessa

– la difficoltà sta nel falsificare la firma di uno specifico messaggio

Vulnerabilità “arcane” di RSA

– generalmente, ciò che viene firmato (messaggio + padding) ha una struttura sufficientemente vincolata

• vengono inseriti dei bit di riempimento organizzati in pattern regolari

• la probabilità che un numero random costituisca un messaggio (padding incluso) valido è trascurabile; cioè è estremamente improbabile che un numero random contenga i pattern regolari di bit

• tuttavia, visto che i numeri in RSA sono molto grandi un avversario ha a disposizione molti tentativi

• i pattern di riempimento vanno scelti in modo opportuno

Smooth Numbers

– Intuitivamente, uno smooth number è un numero scomponibile nel prodotto di (molti) numeri primi “ragionevolmente piccoli”

• non conviene usare una definizione assoluta; un numero è piccolo o grande in base alle capacità di calcolo dell’avversario

• esempio, il numero 6056820 è “più smooth” del numero 6567587, poiché

• 6056820 = 22 ∙ 32 ∙ 5 ∙ 7 ∙ 11 ∙ 19 ∙ 23

• 6567587 = 13 ∙ 557 ∙ 907

Vulnerabilità smooth number

• Si tratta di una vulnerabilità di RSA prevalentemente teorica – nella pratica è difficilmente realizzabile

• richiederebbe un’immensa capacità di calcolo, la raccolta di un numero enorme di messaggi firmati e molta fortuna (per l’avversario)

– IDEA BASE • dalle firme s1 e s2 dei messaggi m1 ed m2,

• è possibile calcolare le firme dei messaggi m1 ∙ m2, m1 / m2, m1

j, m2k, e m1

j ∙ m2k

• ad esempio, conoscendo la firma s1 = m1d mod n è possibile

ottenere la firma di m12 senza conoscere d (chiave privata)

• infatti, (m12)d mod n = (m1

d)2 mod n = (m1d mod n)2 mod n


• la firma di m12 è pari a s1

2 mod n

– se un avversario riesce a collezionare molti messaggi firmati, può ottenere la firma di ogni messaggio m esprimibile come prodotto e/o divisione di messaggi della collezione • in particolare, se ottiene le firme di due messaggi m1 e

m2 tali che il rapporto m1 / m2 = p dove p è un numero primo

• può calcolare la firma di p

– se è abbastanza fortunato da raccogliere molte coppie di questo tipo • può calcolare la firma di molti numeri primi


• può falsificare la firma di ogni messaggio dato dal prodotto di ogni sottoinsieme di tali numeri primi ciascuno elevato ad una qualunque potenza

– con abbastanza coppie, può falsificare la firma di ogni messaggio rappresentato da uno smooth number

– generalmente, ciò che si firma con RSA è un digest messaggio con padding m* = pad(h(m))

• al digest del messaggio m vengono aggiunti, in modo opportuno, dei bit di riempimento (padding) ottenendo m*

• se i bit di riempimento sono degli zeri, anziché essere random è più probabile che m* sia uno smooth number


• invece, è estremamente improbabile che un numero random mod n sia smooth

– con un padding a sinistra di soli zeri

• l’intero da firmare mp = h(m) rimane piccolo

• il padding non riduce la probabilità che mp sia smooth

– con un padding a destra di soli zeri

• mp = h(m) ∙ 2k è un intero molto più grande, ma è divisibile per una potenza di due

• di nuovo, il padding non riduce la probabilità che mp sia smooth


– con un padding a destra random

• l’intero da firmare mp è estremamente improbabile che sia smooth

– tuttavia, si espone RSA alla minaccia nota come il problema della radice cubica

Problema della radice cubica

• Si assuma che si è optato per padding a destra random

– per ridurre la probabilità che le firme prodotte siano smooth

– si ha in seguente inconveniente se l’esponente pubblico e = 3

• un attaccante può virtualmente falsificare la firma di un qualsiasi messaggio

Problema della radice cubica

– supponiamo che un attaccante, Carol, voglia falsificare la firma di un qualche messaggio m avente digest hm allora

– Carol applica un padding a destra, di hm, considerando bit a zero ottenendo pm = hm00…00

– poi calcola la radice cubica ordinaria e la arrotonda all’intero più vicino r = round(pm

1/3)

– r è la firma falsificata di m

• infatti, re = r3 = pm ossia hm con un padding a destra che è apparentemente casuale

PUBLIC-KEY CRYPTOGRAPHY STANDARD (PKCS)

Crittografia a Chiave Pubblica – Parte I

PKCS

• PKCS sta per Public-Key Cryprography Stanbdard

– Standard di Crittografia a Chiave Pubblica

– si è visto che ogni applicazione di RSA, cifratura, decifratura e firma, può essere soggetta a diversi tipi di attacchi

• che possono essere sventati con opportune contromisure,

• basate sulla scelta di un’opportuna codifica/formato (quindi padding) del messaggio da cifrare/firmare

PKCS: impieghi

esistono 15 standard PKCS per le diverse situazioni in cui la cifratura a chiave pubblica viene utilizzata

– nelle prossime slides si esaminerà solo PKCS #1

• Tale standard stabilisce le codifiche per

– la chiave pubblica RSA

– la chiave privata RSA

– la firma RSA

– la cifratura RSA di messaggi corti (ossia chiavi segrete)

– la firma RSA di messaggi corti (tipicamente digest)

PKCS #1: minacce considerate

• Lo standard PKCS #1 è stato concepito per fronteggiare le seguenti minacce:

– cifratura di messaggi prevedibili

– smooth number per le firme

– destinatari multipli di uno stesso messaggio quando e = 3

– cifratura di messaggi di lunghezza inferiore ad un terzo della lunghezza di n quando e = 3

– firma di messaggi dove l’informazione è posta nei bit più significativi ed e = 3

PKCS #1: Cifratura

• PKCS #1 definisce uno standard, tra l’altro, per la formattazione di un messaggio da cifrare con RSA

– in genere, RSA non viene usato per cifrare messaggi ordinari,

– ma per cifrare delle chiavi segrete

• per questioni di efficienza conviene usare la cifratura a chiave segreta per dati ordinari

– lo standard prevede il seguente formato per l’input m

0 2 0 almeno otto ottetti random non nulli data

PKCS #1: Cifratura

– i dati effettivi da cifrare, generalmente una chiave segreta, sono più corti del modulo (cioè di n, che generalmente ha una lunghezza di 512 bit) • KDES ha una lunghezza di 64 bit

• K3DES ha una lunghezza di 128 bit

– il 1° ottetto è 0 (cioè otto bit nulli) • ciò garantisce che m < n; se fosse m > n la decifratura

produrrebbe m mod n m

– il 2° ottetto è 2, definisce il tipo di formato • il valore 1 stabilisce che m viene firmato

• il valore 2 stabilisce che m viene cifrato

0 2 0 almeno otto ottetti

random non nulli data

PKCS #1: Cifratura

– seguono poi almeno otto ottetti di padding non nulli scelti in modo randomico e indipendente l’uno dall’altro

• l’ottetto 0 (nullo) va scartato perché viene usato come separatore del padding dalla parte dati

0 2 0 almeno otto ottetti random non nulli data

PKCS #1: protezione minacce cifratura

– vediamo come le scelte del formato standard per la cifratura permettono di sventare le minacce precedentemente esaminate

• Cifratura di messaggi prevedibili – con almeno otto ottetti (64 bit) di padding random

– anche se un attaccante è in grado di prevedere i dati effettivi da cifrare • ad esempio i dati potrebbero appartenere ad un insieme con

“pochi” elementi noti all’attaccante

• l’attaccante potrebbe cifrare ciascun dato e verificare se quanto ottenuto coincide con il testo cifrato

– l’attaccante dovrebbe anche indovinare il padding • cioè una sequenza di almeno 64 bit random


• Spedizione di uno stesso messaggio cifrato a più di tre destinatari

– nell’ipotesi e = 3

– anche se i dati dati da cifrare sono esattamente gli stessi per tutti i destinatari,

– la scelta del padding random garantisce che,

– in input all’algoritmo di cifratura sono forniti, con elevatissima probabilità, dei messaggi distinti


• Cifratura di messaggi di lunghezza inferiore ad un terzo della lunghezza di n

– nell’ipotesi e = 3

– essendo il secondo ottetto non nullo, (è pari a 2),

– il messaggio ottenuto m ha sicuramente una lunghezza superiore ad un terzo della lunghezza del modulo n

PKCS #1: firma digitale

• PKCS #1 definisce anche uno standard per la formattazione di un messaggio da firmare con RSA

– in genere, i dati da firmare consistono in un digest di un messaggio, tipicamente 128 bit

– analogamente alla cifratura è necessario applicare un padding

– lo standard prevede il seguente formato per l’input m

0 1 0 almeno otto ottetti di ff16 tipo-di-digest e digest

il tipo-di-digest viene specificato con una notazione ASN.1

PKCS #1: protezione minacce firma

– il 1° ottetto pari 0 m < n

– il 2° ottetto è 1, e specifica il tipo di formato PKCS

• in questo caso, una quantità da firmare

– il padding con almeno otto ottetti pari a ff16 (otto bit a 1) rende la quantità da firmare molto grande

– è altamente improbabile che sia uno smooth number


• Domanda: perché viene anche incluso il tipo di algoritmo di digest utilizzato? – espresso nella notazione ASN.1

• Risposta: il tipo di digest è incluso per due motivi 1. viene standardizzato come comunicare all’altra

parte l’algoritmo di digest utilizzato

2. serve a prevenire una minaccia “oscura”


– la minaccia “oscura” è la seguente

– una funzione di hash, ad esempio MD4, potrebbe essere debole • qualcuno potrebbe essere in grado di generare un

messaggio con un particolare digest MD4

• si supponga, che nel firmare un messaggio m venga usato MD5, ma non sia incluso l’algoritmo di digest usato

• un avversario potrebbe allora generare un messaggio m’ tale che MD4(m’) = MD5(m)

• ed usare la firma corrispondente ad m per m’

– includere il tipo di algoritmo di digest

– il rischio di falsificazione che si corre dipende solo dalla robustezza di tale algoritmo

APPENDICE Crittografia a Chiave Pubblica

Teoremi di Eulero e di Fermat

• Teorema di Eulero: per ogni intero a relativamente primo ad n si ha

aϕ(n) = 1 mod n

– nel caso in cui n è primo ϕ(n) = n – 1 il teorema assume una forma più semplice e un altro nome

• Teorema di Fermat: se p è primo e 0 < a < p

ap – 1 = 1 mod p

Bibliografia






Crittografia a Chiave Pubblica Parte II

Luca Grilli

DIFFIE-HELLMAN Crittografia a Chiave Pubblica – Parte II

Diffie-Hellman – Introduzione

– Diffie-Helmann è il primo sistema a chiave pubblica utilizzato • è meno generale di RSA; non serve né a cifrare/decifrare né

a firmare messaggi

• La sua applicazione è il cosiddetto scambio delle chiavi Diffie-Hellman – permettere a due entità di accordarsi su un segreto

(chiave) condiviso,

– senza rivelarlo, e

– scambiandosi messaggi in chiaro su una rete pubblica insicura • intercettando tutti i messaggi scambiati non si è in grado di

risalire al segreto condiviso


– il segreto condiviso non viene generato da una delle due entità dialoganti, diciamo Alice e Bob • né Alice né Bob generano autonomamente il segreto

– ma è il risultato dello scambio dei messaggi

– in particolare, dopo essersi scambiati complessivamente due messaggi (in chiaro) • che tutto il “mondo” più conoscere

– Alice e Bob conosceranno il segreto condiviso KAB

– KAB viene poi usato per proteggere la confidenzialità con tecniche di cifratura convenzionali


– Diffie-Hellman è realmente usato per stabilire una chiave segreta condivisa in alcune applicazioni

• ad esempio, nell’ambito della cifratura dei dati inviati in una LAN

– si osservi comunque che Diffie-Hellman non incorpora alcuna forma di autenticazione

• senza un’autenticazione preliminare si rischia di condividere il segreto con un impostore

Diffie-Hellman – Algoritmo

• PRECONDIZIONE

– le due parti dialoganti, Alice e Bob, devono condividere due numeri p e g, dove

– p: numero primo grande

– g: radice primitiva di p

• p e g possono essere noti in anticipo,

• possono essere resi di dominio pubblico in una repository accessibile sia da Alice che da Bob, oppure

• possono essere generati dall’iniziatore della comunicazione, diciamo Alice, e trasmessi a Bob nel messaggio che gli invierà

Diffie-Hellman – Fase 0

– la Fase 0, viene eseguita dall’iniziatore della comunicazione qualora i numeri p e g non siano pubblici

0A) Generazione dei numeri p e g – Alice genera (o estrae da un suo archivio) una coppia

di numeri p e g tali che • p è un numero primo grande

• g è un radice primitiva di p

• p e g possono essere subito inviati a Bob oppure

• possono essere trasmessi nella fase 3A)

Diffie-Hellman – Fase 1A e 1B

1A) Generazione del segreto privato sA

– Alice genera un numero random sA di 512-bit tale che sA < p • sA non è la chiave condivisa • sA non sarà mai trasmesso a Bob

1B) Generazione del segreto privato sB

– analogamente Bob genera un numero random sB di 512-bit tale che sB < p • sB non è la chiave condivisa • sB non sarà mai trasmesso ad Alice

• N.B.: in generale la fase 1B) non avviene dopo la 1A) e prima della

2A); la tempistica sarà illustrata nel seguito • tuttavia le singole fasi A e le singole fasi B rispettano l’ordine con

cui sono descritte

Diffie-Hellman – Fase 2A e 2B

2A) Calcolo del valore pubblico TA = gsA mod p

– Alice calcola TA che poi sarà inviato a Bob

• TA può essere rivelato a tutto il mondo senza inficiare la sicurezza dell’algoritmo

2B) Calcolo del valore pubblico TB = gsB mod p

– analogamente Bob calcola TB che poi sarà inviato ad Alice

• TB può essere rivelato a tutto il mondo senza inficiare la sicurezza dell’algoritmo

Diffie-Hellman – Fasi 3A, 4A e 3B, 4B

3A) Alice invia TA a Bob

3B) Bob invia TB ad Alice

4A) Calcolo della chiave segreta KAB

– Alice utilizzando TB ricevuto da Bob calcola

KAB = TBsA mod p

4B) Calcolo della chiave segreta KBA

– Bob utilizzando TA ricevuto da Alice calcola

KBA = TAsB mod p

è facile provare che KAB = KBA

KAB = KBA

KAB = TBsA mod p = (gsB mod p)sA mod p =

= gsBsA mod p = gsAsB mod p =

= (gsA mod p)sB mod p = TAsB mod p = KBA

– Sicurezza: noti p, g, TA e TB è possibile calcolare sA, sB oppure gsAsB? • al momento non sono note tecniche per calcolare gsAsB

in un tempo ragionevole, anche conoscendo gsA e gsB

• ottenere sA da gsA calcolare il logaritmo discreto

dlogg gsA ove dlogg: Z Zp

• ma il calcolo di logaritmi discreti non è fattibile in tempi ragionevoli

Diffie-Hellman – Schema

Alice Bob p noto in anticipo g noto in anticipo

genera sA < p

calcola TA = gsA mod p TA

genera sB < p

calcola TB = gsB mod p

calcola KBA = TAsB mod p

calcola KAB = TBsA mod p

TB

Diffie-Hellman: autenticità principal

– Diffie-Hellman non fornisce alcuna forma di autenticazione • Alice non può essere certa che TB sia stato inviato da Bob e non da

un impostore

• Bob non può essere certo che TA sia stato inviato da Alice e non da un impostore

– è possibile che un impostore, Mr. X, intercetti e modifichi i messaggi facendo credere a Bob di comunicare con Alice e viceversa • Alice e Bob non hanno modo di rendersi conto dell’attacco in atto

– un attacco attivo di questo tipo è noto come Man-in-the-Middle Attack • talvolta si usa anche il termine Bucket Brigade Attack

Man-in-the-Middle Attack

Alice Bob

p noto in anticipo g noto in anticipo

sA < p

TA = gsA mod p TA

KBX = TXsB mod p

Mr. X

sX < p

TX = gsX mod p

sB < p

TB = gsB mod p

TX

KXB = TBsX mod p

TB

TX

KXA = TAsX mod p

KAX = TXsA mod p

Man-in-the-Middle Attack

• Alice pensa che KAX sia la chiave segreta KAB che condivide con Bob

• Bob pensa che KBX sia la chiave segreta KBA che condivide con Alice

• Mr. X ha due chiavi segrete – KXA per comunicare con Alice – KXB per comunicare con Bob

• DOMANDA – Assumendo che la chiave segreta condivisa serva per cifrare i

successivi messaggi tra Alice e Bob, – è possibile agire sul contenuto di tali messaggi per verificare se

c’è stato o meno un attacco Man-in-the-Middle, ovvero per autenticare i due principal?

?Autenticazione via password?

– Ipotesi: Alice e Bob si sono preliminarmente accordate su una coppia di password: • pwdA: password che Alice invia a Bob

• pwdB: password che Bob invia ad Alice

– si consideri allora la seguente procedura di autenticazione,

– dove KAB è la chiave segreta condivisa ottenuta con Diffie-Hellman

Alic

e

Bo

b

E(KAB, “I’m Alice”||pwdA)

E(KAB, “Hi Alice, I’m Bob”||pwdB)

scambio chiavi Diffie-Hellman

?Autenticazione via password?

• DOMANDE

– Il precedente schema di autenticazione può permettere ad Alice e Bob di autenticarsi e di verificare pertanto se è in atto un attacco Man-in-the-Middle?

Autenticazione via password è NON sicura

• RISPOSTA

– NO. Se è in atto un attacco Man-in-the-Middle la precedente procedura di autenticazione via password non è sicura.

• Mr. X può decifrare tutte i messaggi che riceve da Alice con KAX, cifrarli con KXB e inviarli a Bob.

• Viceversa, può decifrare tutte i messaggi che riceve da Bob con KXB, cifrarli con KAX e inviarli ad Alice.

Autenticazione via password è NON sicura A

lice

Bo

b

TA TX


TX TB


KAX chiave segreta condivisa

KXB chiave segreta condivisa

E(KAX, “I’m Alice”||pwdA)

Mr.

X

E(KXB, “I’m Alice”||pwdA)

E(KXB, “Hi Alice, I’m Bob”||pwdB) E(KAX, “Hi Alice, I’m Bob”||pwdB)

… alcune proposte

– Includendo nei messaggi cifrati, che Alice e Bob si scambiano, la chiave condivisa KAB, l’autenticazione diventa sicura?

– Includendo invece il timestamp dell’ora corrente?

– Includendo entrambi?

– Se invece fossero incluse delle domande personali del tipo • “Che film abbiamo visto la prima volta che ci siamo

incontrati a Parigi?”

Autenticazione a chiave segreta insicura se …

Alic

e

Bo

b

TA TX


TX TB


KAX chiave segreta condivisa

KXB chiave segreta condivisa

E(KAX, “I’m Alice”||pwdA||KAX||t0)

Mr.

X

E(KXB, “Hi Alice, I’m Bob”||pwdB||KXB||t2)

E(KXB, “I’m Alice”||pwdA||KXB||t1)

E(KAX, “Hi Alice, I’m Bob”||pwdB||KAX||t3)

se l’autenticazione sfrutta la chiave segreta condivisa KAB, ottenuta con Diffie-Hellman, non è sicura rispetto ad attacchi Man-in-the-Middle

Diffie-Hellman – Sicurezza

• Usando soltanto Diffie-Hellman non è possibile verificare se è in atto un attacco Man-in-the-Middle

– i principal non possono autenticarsi reciprocamente

• Diffie-Hellman è sicuro soltanto nel caso di attacchi passivi

– un intruso intercetta i messaggi, ma non li modifica

Attacco Man-in-the-Middle – Difese

– Per difendersi da attacchi attivi sono attuabili due strategie generali

• Diffie-Hellman con Numeri Pubblici

• Scambio Diffie-Hellman Autenticato

Diffie-Hellman con Numeri Pubblici

• Un possibile modo per sventare attacchi attivi è evitare che p, g, sA, sB, TA e TB vengano generati/calcolati ad ogni scambio

– p, g, TA e TB potrebbero essere resi pubblici in una repository fidata

– p, g saranno uguali per tutti gli utenti

– ogni utente U pubblica il proprio valore TU, mantenendo privato il segreto sU

Diffie-Hellman con Numeri Pubblici

• ne consegue che,

– se un avversario non è in grado di accedere alla repository e di modificare i valori pubblici, allora Diffie-Hellman diventa sicuro anche nel caso di attacchi attivi

• inoltre

– non è più necessario lo scambio dei valori TA e TB

– consultando la repository ogni utente A può ottenere la chiave KAB che condividerebbe con l’utente B

Scambio Diffie-Hellman Autenticato

– Se Alice e Bob conoscono un qualche tipo di informazione che permette loro di autenticarsi reciprocamente • una chiave segreta condivisa KAB; da non confondere con la chiave

concordata con Diffie-Hellman KAB

• la propria coppia chiave privata, chiave pubblica e la chiave pubblica dell’altro

– Possono usare tale(i) informazione(i) per provare che sono realmente loro, e non un impostore, coloro che generano i valori di Diffie-Hellman g, p, TA e TB • tale prova può avvenire sia contestualmente che dopo lo scambio

Diffie-Hellman esaminato in precedenza

– in tal caso si parla di scambio Diffie-Hellman autenticato


– alcune possibili soluzioni sono:

• Autenticazione contestuale allo scambio Diffie-Hellman – Cifrare lo scambio Diffie-Hellman con la chiave segreta KAB

– Cifrare il valore Diffie-Hellman con la chiave pubblica dell’altro interlocutore

– Firmare il valore Diffie-Hellman con la propria chiave privata

• Autenticazione successiva allo scambio Diffie-Hellman – Dopo lo scambio Diffie-Hellman, trasmettere un hash della

chiave concordata KAB, del proprio nome e della chiave segreta KAB

– Dopo lo scambio Diffie-Hellman, trasmettere un hash del valore Diffie-Hellman trasmesso e della chiave segreta KAB


• Notazione adottata – KAB: chiave segreta condivisa tra Alice e Bob prima di effettuare lo scambio Diffie-Hellman

– KAB: chiave concordata con Diffie-Hellman

– KAB{msg}: cifratura di msg con la chiave segreta KAB, cioè E(KAB, msg)

– {msg}Bob: cifratura di msg con la chiave pubblica di Bob, cioè E(PUBob, msg)

– [msg]Bob: firma di msg con la chiave privata di Bob, cioè E(PRBob, msg)

KAB{scambio Diffie-Hellman}

• Scambio Diffie-Hellman cifrato con la chiave segreta KAB

Alic

e

Bo

b

KAB{“I’m Alice”, p, g, TA}

KAB = TBsA mod p = TA

sB mod p = KBA

KAB{“Hi Alice, I’m Bob”, TB}

{ T }OtherPublicKey

• Cifratura del valore pubblico Diffie-Hellman T, con la chiave pubblica dell’altro interlocutore

Alic

e

Bo

b

“I’m Alice”, p, g, {TA}Bob


sB mod p = KAB

“Hi Alice, I’m Bob”, {TB}Alice

[ T ]MyPrivateKey

• Cifratura del valore pubblico Diffie-Hellman T, con la chiave propria chiave privata

Alic

e

Bo

b

“I’m Alice”, p, g, [TA]Alice


sB mod p = KBA

“Hi Alice, I’m Bob”, [TB]Bob

dopo scambio … hash(KAB, name, KAB)

• Dopo lo scambio Diffie-Hellman, trasmettere un hash della chiave concordata KAB, del proprio nome e della chiave segreta KAB

Alic

e

Bo

b

“I’m Alice”, h(KAB, “Alice”, KAB)


sB mod p = KBA

“Hi Alice, I’m Bob”, h(KAB, “Bob”, KAB)

g, p, TA TB

dopo scambio … hash(T, KAB)

• Dopo lo scambio Diffie-Hellman, trasmettere un hash del valore Diffie-Hellman trasmesso e della chiave segreta KAB

Alic

e

Bo

b

“I’m Alice”, h(TA, KAB)


sB mod p = KBA

“Hi Alice, I’m Bob”, h(TB, KAB)

g, p, TA TB

Diffie-Hellman – altro svantaggio

– Oltre alla mancanza di autenticazione, Diffie-Hellman classico presenta anche il seguente svantaggio

• La comunicazione cifrata, con la chiave concordata, può avvenire soltanto dopo l’esecuzione di uno scambio attivo

– Alice non può inviare un messaggio cifrato a Bob prima di ricevere TB

Chiavi pubbliche/private D-H

• Tale problema può essere ovviato introducendo le chiavi pubbliche Diffie-Hellman

– Una chiave pubblica D-H è una tripla p, g, T dove T = gs mod p

– Ovviamente s è la corrispondente chiave privata

– Le chiavi pubbliche vanno custodite in un luogo fidato e accessibile da tutti in modo sicuro

– La chiave pubblica di Bob è pB, gB, TB


• Esercizio

– Utilizzando le chiavi pubbliche D-H, illustrare una procedura che consenta ad Alice di inviare un messaggio cifrato a Bob, con la chiave concordata KAB, anche se Bob risulta essere inattivo.

• cioè Alice deve essere in grado di cifrare senza dover attendere alcuna risposta da Bob,

• Bob, una volta attivo, dovrà poter calcolare KAB e decifrare il messaggio


Alice Bob chiave pubblica di Bob

pB, gB, TB

genera sA < pB

calcola TA* = gB

sA mod pB

calcola KAB = TBsA mod pB

cifra msg E(KAB, msg)

calcola KBA = (TA*)sB mod pB

decifra E(KAB, msg) msg = D(KBA, E(KAB, msg))

Bob inattivo

SOLUZIONE

TA*, E(KAB, msg)

ELGAMAL SIGNATURE Crittografia a Chiave Pubblica – Parte II

Introduzione

– la firma digitale ElGamal sfrutta opportunamente le chiavi pubbliche e private Diffie-Hellman

– ogni individuo deve avere una coppia PU, PR durevole nel tempo • la chiave pubblica PU è la tripla p, g, T • la chiave privata PR corrispondente è il numero s tale che T = gs mod p

– la firma di un messaggio m richiede la generazione di una coppia PUm, PRm per il messaggio stesso

– il calcolo della firma richiede l’uso di una funzione di hash sicura

– la verifica della firma consiste nel verificare l’uguaglianza di due particolari espressioni

Parametri

• h(): una funzione di hash resistente alle collisioni

• p: un numero primo grande

– tale da rendere infattibile il calcolo del logaritmo discreto

• g < p: una radice primitiva di p

– tali parametri possono essere condivisi tra tutti gli utenti

Fase 0 – Generazione delle chiavi

• Tale fase va eseguita soltanto una volta dal firmatario – non va eseguita ogni volta che si firma un messaggio

• Scegliere randomicamente un intero s, da non divulgare, tale che 1 < s < p – 1

• Calcolare T = gs mod p

• La chiave pubblica PU del firmatario è la tripla p, g, T

• La chiave privata PR del firmatario è s

Fase 1 – Firma di un messaggio

– per firmare un messaggio m il firmatario esegue i seguenti passi

• Calcola una coppia PUm, PRm per m – sceglie randomicamente un intero sm

• tale che 0 < sm < p – 1 e gcd(sm, p – 1) = 1

– calcola Tm = gsm mod p; PUm, PRm = p, g, Tm, sm

• Calcola il digest dm = h(m||Tm)

• Calcola la quantità Xm = (sm + dms) mod (p – 1) che è la firma del messaggio – talvolta si dice che la firma di m è la coppia Tm, Xm

• Il messaggio m è trasmesso insieme a Tm e Xm

Fase 2 – Verifica della firma

– il destinatario di m e della firma Tm, Xm verifica la firma come segue

• Verifica preliminarmente che – 0 < Tm < p e che – 0 < Xm < p – 1

• Calcola il digest dm = h(m||Tm) • Verifica la validità della seguente uguaglianza gXm mod p = TmT dm mod p

– la firma è accettata solo se tutte le precedenti verifiche sono superate, altrimenti la firma è rigettata

Correttezza

– L’algoritmo è corretto nel senso che la firma generata sarà sempre accettata dal verificatore

– Prova

• si osservi che φ(p) = p – 1 è la funzione totiente di p

gXm mod p = g(sm + dms) mod φ(p) mod p =

= gsm + dms mod p =

= ((gsm mod p) (gdms mod p)) mod p =

= (Tm (gs mod p)dm) mod p =

= TmT dm mod p

Sicurezza

• Un avversario può forgiare una firma – calcolando la chiave privata s del firmatario, o

– individuando dei messaggi collidenti della funzione di hash h()

• entrambi i problemi sono ritenuti difficili

• Si può inoltre verificare (anche empiricamente) che – se il messaggio m viene modificato, dopo essere stato

firmato, con elevatissima probabilità la verifica della firma fallisce

– nessuno è in grado di produrre una firma valida senza conoscere la chiave privata s

DIGITAL SIGNATURE STANDARD (DSS)

Crittografia a Chiave Pubblica – Parte II

DSS – Introduzione

• Il National Institute of Standards and Technology (NIST) nel 1991 – ha proposto un algoritmo per la firma digitale basato su

ElGamal

– l’algoritmo è noto come DSA: Digital Signature Algorithm

– le differenze tra DSA e ElGamal riguardano prevalentemente le prestazioni • anziché eseguire tutti i calcoli mod p; ove p è un numero primo di

512 bit

• alcuni sono eseguiti mod q; ove q è un numero primo di 160 bit che divide p – 1

• esponenti di 160 bit anziché di 512 rendono il calcolo della firma tre volte più veloce


– tuttavia, alcune scelte fatte rendono DSS meno efficiente di quanto poteva essere • in particolare, un’operazione d’inversione deve essere

eseguita da entrambe le parti; dal firmatario e da chi verifica la firma

• si poteva optare per una soluzione più facile e al tempo stesso (complessivamente) più efficiente, in cui l’inversione deve essere eseguita solo dal firmatario

• invece DSS, permette al firmatario di pre-calcolare il suo inverso prima ancora di avere il messaggio,

• a scapito di richiedere anche a chi verifica la firma di calcolare un inverso


– DOMANDA: perché si è deciso di favorire il firmatario a discapito di chi deve verificare la firma? • per ogni firma c’è almeno una verifica, altrimenti non ci sarebbe la

necessità di firmare!

– RISPOSTA: tale decisione può rendere più efficiente l’autenticazione fatta tramite smart card (applicazioni in cui DSS è usata) • una smart card è dotata di un processore molto lento

• il log in di un utente si basa sulla firma e verifica della firma

• l’inversione è l’operazione computazionalmente più dispendiosa una smart card impiegherebbe alcuni minuti per eseguirla

• conviene pertanto “alleggerire” il costo computazionale della firma digitale sul lato smart card; anche se ciò comporta un processo di verifica più dispendioso, ma ciò è tollerabile dato che la verifica viene eseguita da calcolatori molto veloci

Algoritmo DSS – Generazioni chiavi

0.1 Genera p e q (che saranno pubblici); q è un numero primo di 160 bit, p è un numero primo di 512 bit tale che p = kq + 1

0.2 Genera un numero g (che sarà pubblico), tale che gq = 1 mod p

0.3 Scegli una coppia chiave pubblica/privata a lungo termine PU, PR = T, S; ove S < q è un numero random e T = gS mod p

1.0 Scegli una coppia chiave pubblica/privata associata al messaggio PUm, PRm = Tm, Sm; generando un numero random Sm e ponendo Tm = ((gSm mod p) mod q).

1.1 Calcola l’inverso Sm-1 mod q ciò permette di guadagnare tempo

evitando di eseguire l’inversione in fase di firma.

Algoritmo DSS – Firma del messaggio m

2.0 Calcola un message digest dm del messaggio. Il NIST raccomanda di usare la funzione di hash SHS in congiunzione con DSS. SHS calcola un hash di 160 bit che per pura casualità coincide con la lunghezza di q. 160 bit sono una scelta adeguata perché garantiscono la sicurezza dell’hash e sono un multiplo intero di 32 più semplice la memorizzazione in sistemi con word di 32 bit. DSS può essere usato con ogni funzione di hash, sebbene l’uso di hash con più di 160 bit non comporta un aumento di sicurezza

2.1 Calcola la firma Xm =Sm-1(dm + STm) mod q

2.2 Trasmetti la seguente terna di informazioni m, Tm, Xm: il messaggio m il valore pubblico associato al messaggio Tm

la firma Xm Le informazioni associate alla chiave pubblica, cioè T, p, q e g, sono già note e non è necessario trasmetterle con il messaggio.

Algoritmo DSS – Verifica della firma

3.0 Calcola l’inverso mod q della firma Xm-1

3.1 Calcola il digest del messaggio dm

3.2 Calcola xm = dm ∙ Xm-1 mod q

3.3 Calcola ym = Tm ∙ Xm-1 mod q

3.4 Calcola zm = (gxm ∙ Tym mod p) mod q

3.5 Se zm = Tm la firma è autentica

DSS – Prova di correttezza

– Per provare che la procedura di verifica è corretta è necessario mostrare che

• zm coincide con Tm

• se le quantità m, Tm, Xm e T, p, q, g non sono alterate

– PROVA

• innanzi tutto, essendo gq = 1 mod p

• esponente e si ha che ge mod q mod p = ge mod p – infatti, ge mod p = gre + keq mod p = (gre ∙ gkeq) mod p =

– = (gre mod p) ∙ (gkeq mod p) = (ge mod q mod p) ∙ (gq mod p) ke =

– = (ge mod q mod p) ∙ 1 ke = ge mod q mod p

• sia vm = (dm + STm)-1 mod q allora

DSS – Prova di correttezza

• Xm-1 = [Sm

-1(dm + STm) mod q]-1 = [Sm(dm + STm)-1 mod q]

• Xm-1 = Smvm mod q da cui sostituendo risulta

• xm = dm ∙ Xm-1 mod q = dmSmvm mod q

• ym = Tm ∙ Xm-1 mod q = TmSmvm mod q quindi

• zm = (gxm ∙ Tym mod p) mod q =

• = (gdmSmvm mod q ∙ gSTmSmvm mod q mod p) mod q =

• = (gdmSmvm ∙ gSTmSmvm mod p) mod q =

• = (g(dm + STm)Smvm mod p) mod q = (gSm mod p) mod q = Tm

Generazione di p e q - osservazioni

• La generazione dei numeri primi

– p (512 bit) e q (160 bit) tali che p = kq + 1

– è computazionalmente molto dispendiosa

• ma non deve essere eseguita molto frequentemente

– p e q essendo pubblici potrebbero essere

• definiti una volta per tutte (per lo meno p) ed

• inseriti nello standard

– tutti potrebbero usare lo stesso p, con alcuni accorgimenti di sicurezza

Generazione di p e q - osservazioni

– tuttavia la questione è molto controversa!

• si dice che è possibile per qualcuno generare un p in modo tale che questi possa violare le operazioni crittografiche fatte con quel p e che nessuno sia in grado di accorgersi di tale violazione

• un particolare valore di p definito nello standard non è ben accetto

• inoltre, se esiste un unico p, è vero che si ha una maggiore efficienza (non è necessario generare nuovi p e q),

• ma gli attacchi all’algoritmo sarebbero più semplici in quanto dovrebbero funzionare solo per quel valore di p

Requisiti di Sicurezza

• Per sicurezza si intende che valgono le seguenti proprietà

– Firmare qualcosa non divulga la chiave privata S

– Nessuno dovrebbe essere in grado di generare una firma per un dato messaggio senza conoscere S

– Nessuno dovrebbe essere in grado di generare un messaggio avente una data firma

– Nessuno dovrebbe essere in grado di modificare un messaggio firmato in modo tale che la firma resti valida

DSS – Sicurezza

• Domanda – DSS soddisfa tutti i requisiti di sicurezza?

• Risposta – non esistono delle vere e proprie prove formali, ci sia

affida al Fundamental Tenet of Cryptography

– inoltre, DSS ha la “benedizione” della NSA, ove lavorano probabilmente i migliori crittografi del mondo

– tuttavia, c’è chi sostiene che NSA mai proporrà un algoritmo che non è in grado di violare!

Sulla scelta del numero segreto Sm

– Sia DSS che ElGamal richiedono che il firmatario generi un unico numero segreto Sm

• Usando uno stesso Sm per firmare due messaggi distinti si esporrebbe la chiave privata S del firmatario

• Similmente, se Sm fosse prevedibile o facilmente indovinabile, si esporrebbe S

• Domande – D1) Perché la chiave privata S del firmatario risulta essere

esposta una volta noto Sm? – D2) Perché S risulta essere esposta quando due messaggi

vengono firmati usando lo stesso Sm?


• Risposta 1 (caso DSS) – essendo Xm =Sm

-1(dm + STm) mod q la firma di m

– ove Xm, dm, Tm, q sono note (almeno a chi verifica la firma)

– se anche Sm fosse noto

– S si otterrebbe calcolando il primo membro della seguente uguaglianza

(XmSm – dm)Tm-1 mod q = S mod q

– conoscendo S diventa banale forgiare una firma DSS


• Risposta 2 (caso DSS) – siano m e m* due messaggi firmati con lo stesso Sm;

cioè Sm = Sm* Sm-1 = Sm*

-1 e Tm = Tm* Xm = Sm

-1(dm + STm) mod q Xm* = Sm

-1(dm* + STm) mod q (Xm – Xm*) = Sm

-1(dm + STm – dm* – STm) mod q (dm – dm*) mod q = (Xm – Xm*)Sm mod q (Xm – Xm*)-1(dm – dm*) mod q = Sm mod q


– pertanto calcolando (Xm – Xm*)-1(dm – dm*) mod q

– si otterrebbe Sm

– e da Sm si otterrebbe S (vedi Risposta 1)

• Ne consegue che è fondamentale scegliere Sm in modo tale che sia unico e al tempo stesso non prevedibile/indovinabile

Numeri segreti unici e non prevedibili

– Ci sono diversi modi per generare un numero segreto unico e non prevedibile/indovinabile

– Usare numeri veramente casuali

• ciò richiede un hardware speciale

• “it's difficult enough to make hardware predictable, but it's even harder to make it predictably unpredictable”

– Usare un generatore di numeri pseudo-random per applicazioni crittografiche; Cryptographically Secure Pseudo-Random Number Generator (CSPRNG)

• necessaria memoria non-volatile per salvare lo stato

Numeri segreti unici e non prevedibili

– Usare un hash crittografico di una combinazione del messaggio con la chiave privata del firmatario

• è necessario conoscere il messaggio,

• non possono essere eseguite operazioni in anticipo,

• si perde il vantaggio in efficienza di ElGamal e DSS rispetto RSA

ZERO KNOWLEDGE PROOF SYSTEMS

Crittografia a Chiave Pubblica – Parte II

Concetti base

• La dimostrazione della conoscenza di un segreto è alla base di molte tecniche di autenticazione

– nelle tecniche di autenticazione a chiave segreta il segreto è appunto la chiave condivisa tra i due principal

– nei protocolli a chiave pubblica il segreto è noto solo ad un principal

– il quale deve dimostrare all’altro che detiene il segreto

– senza fornire delle informazioni che possano consentire ad un impostore di eseguire la prova

Dimostrazione a conoscenza zero

– nell’ambito dei sistemi a chiave pubblica

• Una dimostrazione è a conoscenza zero (Zero Knowledge Proof ZKP) se

1) permette di provare la conoscenza di un segreto

• che deve essere associato alla chiave pubblica

2) senza fornire delle informazioni che permettano ad un impostore di eseguire la prova (in seguito)

• 2.1) la prova non deve rivelare il segreto,

• 2.2) la prova non deve rivelare eventuali informazioni che pur non essendo il segreto consentano comunque ad un impostore di effettuare la prova

Concetti base

• Le dimostrazioni a conoscenza zero sono impiegate nei protocolli/sistemi di autenticazione

– i cosiddetti Zero Knowledge Proof Systems (ZKPS)

– RSA è un esempio di ZKPS

• è possibile provare la conoscenza di un segreto associato alla chiave pubblica; si pensi alla firma di una sfida

• senza rivelare la chiave privata o altre informazioni che permettano ad un impostore di impersonare il proprietario della chiave privata

– tuttavia, esistono ZKPS molto più efficienti di RSA anche se non permettono di cifrare e/o di firmare

ZKP – La storia di Peggy e Victor

• [Wiki-en, Wiki-it] In una dimostrazione a conoscenza zero sono sempre coinvolte due parti – il dimostratore Peggy: l’entità che

dimostra di possedere il segreto, e

– il verificatore Victor: l’entità che verifica la correttezza della prova

• Storia di Peggy e Victor • Peggy conosce la parola segreta per aprire

la porta magica di una caverna, che si richiude automaticamente

• la caverna ha la forma di un cerchio, con l'entrata su un lato e la porta magica che blocca l'altro lato


• Victor dice che la pagherà per il segreto, ma non fino a quando sarà sicuro che lei lo conosca veramente

• Peggy dice che gli dirà il segreto, ma non prima di ricevere i soldi

• Pianificano quindi uno schema con il quale Peggy può provare di conoscere la parola senza dichiararla a Victor

• Prima, Victor aspetta fuori dalla caverna mentre Peggy entra

• Etichettiamo il sentiero sinistro e quello destro partendo dall'entrata con A e B

• Peggy sceglie a caso uno dei due sentieri


• Quindi, Victor entra nella caverna e grida il nome del sentiero che Peggy dovrà utilizzare per ritornare indietro, fra A e B, preso a caso

• Se si ipotizza che lei conosca veramente la parola magica, è facile: apre la porta, se necessario, e ritorna attraverso il sentiero desiderato

• È da notare che Victor non conosce il sentiero per il quale Peggy è entrata


– Comunque, supponiamo che Peggy non conosca la parola • allora, sarebbe in grado di tornare attraverso il sentiero chiamato

se Victor avesse scelto il nome dello stesso sentiero per cui lei era entrata

• poiché Victor ha scelto A o B a caso, avrebbe il 50% di probabilità di indovinare correttamente

• se i due ripetessero questo trucco molte volte, diciamo venti volte una dopo l'altra,

• l'opportunità per Peggy di anticipare correttamente tutte le richieste di Victor diventerebbe statisticamente molto piccola (in virtù della probabilità di eventi indipendenti)

– Perciò, se Peggy appare in modo “affidabile” all'uscita chiamata da Victor, questo può concludere che molto probabilmente conosca davvero la parola segreta

Autenticazione a conoscenza zero

• Uno schema di autenticazione a conoscenza zero (Zero Knowledge Authenication Scheme ZKAS) consiste in un’autenticazione che sfrutta una ZKP – non si tratta di una tecnica deterministica, ma

probabilistica • anche RSA in fondo è probabilistica

– deve poter essere resa arbitrariamente piccola la probabilità che • un dimostratore onesto fornisca una prova errata

• un verificatore onesto fornisca una verifica errata quando il dimostratore è onesto

• un dimostratore disonesto fornisca una prova corretta

ZKAS – Requisiti

• Uno schema di autenticazione a conoscenza zero deve soddisfare i seguenti requisiti

a) ad ogni entità è associato un segreto privato s e una chiave pubblica ks, cioè una coppia s, ks • ovviamente, Ks non deve esporre s

b) l’autenticazione consiste nel provare la conoscenza del segreto s

c) la prova deve essere a conoscenza zero • le informazioni addotte dal dimostratore non devono

poter essere riutilizzate con successo (in seguito) da un impostore la prova non consente di rivelare s

ZKAS – Requisiti

d) chi non conosce il segreto s non deve poter eseguire la prova con successo

e) chi non conosce il segreto s deve poter verificare la correttezza della prova utilizzando la chiave pubblica ks dell’entità che si sta autenticando

• senza la chiave pubblica non deve essere possibile verificare la correttezza della prova

Impiego di problemi difficili

• I requisiti a), b), c), d), e) suggeriscono di realizzare uno ZKAS partendo da un problema matematico P ritenuto difficile

– un problema classificato come NP-Hard è ideale

– un problema per il quale non è noto un algoritmo polinomiale, ma non ancora classificato NP-Hard può andare ma …

• in futuro qualcuno potrebbe trovare un algoritmo polinomiale!


– sia P il problema difficile che si vuole usare per realizzare un ZKAS

– indicheremo con • X: lo spazio delle istanze (input) di P

• Y: lo spazio delle soluzioni (output)

• xX: una particolare istanza di P

• yxY: una soluzione di P relativa all’istanza x

• algP: un algoritmo che risolve P, cioè un algoritmo in grado di calcolare la soluzione yx associata ad una qualunque istanza x

algP x yx


• i requisiti a), b), c), d), e) pongono un certo insieme di vincoli sulla scelta del problema P

d) chi non conosce il segreto deve risolvere il problema P nella sua forma generale

b) il problema si deve semplificare notevolmente per chi conosce il segreto

• il segreto deve influenzare le istanze del problema

• chi conosce il segreto non deve risolvere la versione generale del problema, ma una sua restrizione

• tale restrizione deve essere risolvibile in tempo polinomiale (meglio se in tempo costante o in tempo lineare)


e) la prova (probabilistica) consiste nel fornire delle coppie x, y dove

• x: è un’istanza di P dipendente dal segreto s

• cioè x = x(s) (x(s) non è nota al verificatore perché non conosce il segreto s)

• yx : è la soluzione di P per l’input x

il verificatore usando la chiave pubblica ks del dimostratore deve poter verificare, con elevata probabilità, che yx è veramente la soluzione corrispondente a x


– se tutti i requisiti sono soddisfatti tranne il requisito c), per soddisfare quest’ultimo basta procedere nel seguente modo

• il dimostratore deve prevedere due versioni del problema; la versione PA e la versione PB

• yxA sarà la soluzione di PA per l’input x

• yxB sarà la soluzione di PB per l’input x

• inoltre, ottenere yxA da yx

B e viceversa, deve continuare ad essere un problema difficile

• (N.B.: non è necessario che entrambe le soluzioni siano verificabili con la chiave pubblica ks; una delle due, diciamo yx

B, può anche essere verificata senza l’uso di ks)


• a questo punto, il protocollo può modificarsi come segue

– il dimostratore anziché fornire direttamente delle coppie x1, yx1, x2, yx2, …, xN, yxN

– fornisce prima una sequenza di istanze x1, x2, …, xN

– poi, il verificatore, attribuisce in modo random ad ogni istanza xi una di due etichette

• ad esempio 0 o 1 (oppure A e B)

– per ciascun input xi, il dimostratore fornisce la soluzione di • PA se xi era etichettato con 0 • PB se xi era etichettato con 1


– il dimostratore può comunque fornire un numero adeguato di coppie xi, yxi

A i = 1, …, N • basta che N sia sufficientemente grande

– al contempo, il verificatore ha una scarsa probabilità di impersonare il dimostratore riciclando vecchi input xi • poiché per ogni istanza xi ha il 50% di probabilità di conoscere la

relativa soluzione yxiA

• e il 50% di probabilità di conoscere yxiB

• mai dispone di entrambe le soluzioni

• al crescere di N la probabilità di rispondere correttamente a tutte le istanze tende a zero

• ovviamente, si assume che lo spazio delle istanze X sia enorme

• e che sia estremamente improbabile che una stessa istanza capiti in due sequenze qualsiasi

ZKAS schema generale

I’m Peggy, x1, x2, x3, …, xN-1, xN

Hi Peggy, here is my selection x1, A, x2, B, x3, B,… xN-1, A, xN, A

y1A y2

B y3B … yN-1

A yNA

Pegg

y

Vic

tor

Problema di isomorfismo di grafi

• [KPS02] propone una ZKAS che sfrutta il problema di isomorfismo di grafi (Graph Isomorphism Problem GIP)

– Due grafi con lo stesso numero di vertici sono isomorfi se è possibile rinominare i vertici di uno con i nomi dell’altro ottenendo quest’ultimo

• più formalmente

– Due grafi G1 = (V1, E1) e G2 = (V2, E2), con lo stesso numero di vertici, sono isomorfi se esiste una biiezione f : V1 V2 tale che (u, v)E1 se e solo se (f(u), f(v))E2

Esempio – Due grafi isomorfi

a

b

c

d

g

h

i

j

1 2

3 4

5 6

7 8

f(a) 1

f(b) 6

f(c) 8

f(d) 3

f(g) 5

f(h) 2

f(i) 4

f(j) 7

G1 G2 f

ZKAS con P ottenuto da GIP

• Si osservi che ad oggi

– non è noto un algoritmo polinomiale per risolvere GIP; tuttavia non esiste una prova che GIP sia NP-hard

– dati due grafi isomorfi G1 e G2, calcolare la biiezione f tra i loro vertici non è praticabile in un tempo ragionevole

– viene pertanto illustrato come usare GIP per realizzare un ZKAS


– il dimostratore, Peggy, genera un grafo GA molto grande (diciamo di 500)

– rinominando in modo casuale i vertici di GA ottiene un grafo GB isomorfo per costruzione a GA

– Peggy, pertanto conosce la biiezione f che trasforma GA in GB

– f è il segreto s di Peggy, cioè la sua chiave privata

• nessun altro può calcolarla in un tempo ragionevole

– la chiave pubblica ks di Peggy è la coppia di grafi GA, GB


– per provare a Victor che lei è realmente Peggy,

– rinominando in modo casuale i vertici di GA (o di GB) genera un nuovo insieme di grafi G1, G2, …, GK isomorfi a GA e pertanto anche a GB

– invia G1, G2, …, GK a Victor

– poi Peggy, chiede a Victor di specificare per ciascun Gi se desidera ottenere la biiezione rispetto a GA oppure quella rispetto a GB

• è fondamentale che Victor non ottenga entrambe le biiezioni per ciascun Gi


– Peggy per ciascun grafo Gi invia a Victor la biiezione con GA o con GB coerentemente con la scelta di Victor per quel grafo

I’m Peggy, G1, G2, G3, …, Gk-1, Gk

Hi Peggy, here is my selection G1, GA, G2, GB, G3, GB,… Gk-1, GA, Gk, GA

f1A f2B f3B … fk-1A fkA

Pegg

y

Vic

tor


– se un impostore cercasse di impersonare Peggy intercettando e memorizzando tutte le informazioni trasmesse

– avrebbe il 50% di probabilità di rispondere correttamente ad ogni istanza

– se k è sufficientemente elevato, k = 30, avrebbe una probabilità pari a 1/230 di impersonare con successo Peggy


– si osservi che il protocollo appena illustrato è realmente/completamente a conoscenza zero

– nel senso che terminata l’autenticazione Victor oltre alla chiave pubblica conosce un insieme di grafi isomorfi o GA o a GB e il relativo mapping

• tali grafi non gli consentono di impersonare Peggy

• un insieme analogo di grafi lo potrebbe benissimo generare da se

ZKAS basato su GIP è inefficiente

– Sfortunatamente, lo schema di autenticazione a conoscenza zero appena illustrato, che sfrutta l’isomorfismo di grafi, è troppo inefficiente per essere usato nella pratica!

• si osservi inoltre che nel 2009 Dharwadker e Tevet hanno fornito un algoritmo polinomiale per il problema GIP,

• ma non è stato pubblicato su alcuna rivista scientifica degna di nota

• viene di fatto ignorato dalla comunità scientifica!

ZKAS basato su GIP è inefficiente

– Nelle prossime slide, si illustrerà un protocollo di autenticazione, estremamente efficiente, che sfrutta un problema difficile nell’ambito dell’aritmetica modulare

• a rigore tale schema di autenticazione non è completamente a conoscenza zero, anche se nella pratica può considerarsi tale

– Tale protocollo è stato pubblicato da Fiat-Shamir nel 1987

Problema della radice quadrata modulare

– n = p∙q: numero intero dispari

– p, q: numeri primi

– m < n: un intero assegnato (avente una radice quadrata ordinaria non intera)

– trovare un numero intero s tale che s2 mod n = m è un problema difficile almeno quanto fattorizzare un numero intero

– s è la radice quadrata modulo n (Modular Square Root MSR)

ZKAS basato su MSR – Fiat-Shamir

• Generazioni delle chiavi

– Peggy calcola la chiave pubblica n, v

• n = pq è il prodotto di due primi grandi, come in RSA

• v è un numero di cui Peggy conosce la radice quadrata modulare,

• ottenere v è semplice, basta scegliere un numero random s e porre v = s2 mod n

– s è la chiave privata di Peggy da non rivelare

• Peggy può dimenticare i fattori p e q

– n, v va divulgata a tutto il mondo


• Autenticazione

– Peggy sceglie k numeri random r1, r2, …, rk

– Per ogni ri invia a Victor ri2 mod n

– Victor attribuisce a ciascun ri2 un’etichetta che

vale o 1 o 0 e comunica tale etichettatura a Peggy

– Peggy invia a Victor sri mod n per ciascun ri2

etichettato con 1, e ri mod n per ciascun ri2

etichettato con 0

– Victor eleva al quadrato ciascun numero della risposta di Peggy


– e verifica che tale quadrato valga

– vri2 mod n se il corrispondente ri

2 aveva etichetta 1, oppure

– ri2 mod n se il corrispondente ri

2 aveva etichetta 0

I’m Peggy, r12, r2

2, r32, …, rk-1

2, rk2

Hi Peggy, here is my selection r1

2, 1, r22, 0, r3

2, 1,…, rk-12, 0, rk

2, 1

sr1 mod n, r2 mod n, sr3 mod n, …, rk-1 mod n, srk mod n

Pegg

y

Vic

tor


– Supponiamo che Fred voglia impersonare Peggy

– allora egli è in grado di rispondere in modo corretto agli ri

2 che Victor etichetta con 0

– ma non è in grado di rispondere agli ri2 etichettati

con 1

– DOMANDA: Per quale ragione è necessario che Victor etichetti con 0, ed in modo casuale, alcuni ri

2?


– RISPOSTA

– In assenza di etichette 0, il protocollo si semplificherebbe

– Peggy si limiterebbe ad inviare delle coppie

ri2, sri mod n

– tuttavia non si avrebbe più un protocollo a conoscenza zero

• Fred potrebbe infatti usare una precedente sequenza inviata di Peggy ed impersonarla con successo


– l’etichettatura scelta in modo casuale da Victor implica che Fred ha una probabilità del 50% di rispondere in modo corretto ad ogni ri

2

• Fred potrebbe generarsi autonomamente gli ri, ma in tal caso non saprebbe rispondere agli ri

2 con etichetta 1

• oppure potrebbe usare un insieme di ri2 etichettati in

passato con 1 in una precedente autenticazione,

• ma allora non conoscerebbe i corrispondenti ri e non saprebbe rispondere nel caso in cui l’etichetta è 0

– se k è sufficientemente grande la probabilità che Fred impersoni correttamente Peggy tende a 0


– ZKAS basato su MSR è molto più efficiente di RSA

– assumendo k = 30 • Peggy deve effettuare 45 operazioni modulari (30

quadrati più una media di 15 moltiplicazioni per s)

• Victor deve effettuare lo stesso numero di operazioni di Peggy

– usando RSA Peggy deve eseguire una esponenziazione modulare • che consiste in una media di 768 moltiplicazioni

modulari

– mentre Victor se la cava con 3 moltiplicazioni nel caso in cui e = 3

ZERO KNOWLEDGE SIGNATURES Crittografia a Chiave Pubblica – Parte II

Zero Knowledge Signature

• Ogni ZKPS può essere trasformato in uno schema di firma a chiave pubblica

– per lo meno da un punto di vista teorico

• nella pratica, le prestazioni in termini di consumo di banda e di CPU escludono tale soluzione

• In un qualsiasi sistema a conoscenza zero

– Peggy ha un segreto che usa per trasmettere “qualcosa” a Victor

– ed è in grado di rispondere ad ogni domanda posta da Victor inerente quel “qualcosa” trasmesso

– le domande di Victor possono essere di due tipi

Zero Knowledge Signature

– un impostore può rispondere in modo corretto soltanto alle domande di uno solo dei due tipi

• ad ogni domanda ha il 50% di probabilità di rispondere correttamente

• per rispondere correttamente a tutte e k le domande ha una probabilità di (1/2)k

– in generale, Victor invia a Peggy una sfida, ovvero una stringa binaria che codifica il tipo di domanda a cui Peggy dovrà rispondere

– si tratta pertanto di uno schema interattivo

Zero Knowledge Signature – Idea Base

• Uno schema di firma è non interattivo – non esiste alcun Victor che invia a Peggy una sfida

– lo schema è unidirezionale, Peggy ha un messaggio m che desidera firmare

– l’idea è quella di sostituire la sfida di Victor con il digest di qualcosa dipendente dal messaggio • Peggy non potrà predire l’output del digest,

• ma conoscendo il segreto sarà in grado di rispondere ad ogni domanda; cosa che non può fare un impostore

– inoltre Victor deve poter verificare la firma con la chiave pubblica di Peggy

Zero Knowledge Signature – Fiat-Shamir

• segue uno schema di firma derivato da Fiat-Shamir

– Peggy sceglie k numeri random r1, r2, …, rk

• k deve coincidere con il numero di bit dell’algoritmo di digest utilizzato, es. k = 128 bit nel caso di MD5

– Concatena il messaggio m con i valori ri2 mod n e

calcola il digest di quanto ottenuto, cioè

h(m||r12 mod n||r2

2 mod n||…||r1282 mod n)

– I bit del digest vengono usati come surrogato di Victor

– La firma di m consiste nei k valori ri2 mod n più le

relative k risposte di Peggy

Zero Knowledge Signature – Fiat-Shamir

• Si noti che la firma di un messaggio, a differenza dell’autenticazione, può calcolarsi anche off-line

– un impostore ha più tempo per selezionare un insieme opportuno di ri per i quali è in grado di calcolare la radice quadrata mod n di vri

2

– tuttavia, usando algoritmi di digest con almeno 64 bit tale rischio è scongiurato

Bibliografia






Sistemi di Autenticazione Introduzione

Luca Grilli

Premessa

• Per autenticazione si intende il processo che permette di verificare in modo affidabile l’identità di qualcuno (o di qualcosa)

– esistono svariate forme di autenticazione

– una persona può essere riconosciuta

• dall’aspetto fisico o dalla voce

• da una guardia che confronta il viso con la foto nel badge

• nel caso degli acquisti on-line, dalle informazioni associate alla carta di credito

• nel seguito si esamineranno le varie forme di autenticazione

Possibili scenari

• Le varie forme di autenticazione possono essere classificate in base – al tipo (persona o computer) di entità coinvolte

• autenticazione computer/computer

• autenticazione persona/computer

• autenticazione persona/persona (non ci interessa)

– alle informazioni e al modo in cui l’autenticazione avviene • autenticazione basata su password

• autenticazione basata sull’indirizzo

• autenticazione crittografica

AUTENTICAZIONE BASATA SU PASSWORD

Sistemi di autenticazione – Introduzione

Autenticazione basata su password

• Nel caso di autenticazione basata su password

– l’identità equivale alla conoscenza della password

– chi si deve autenticare invia la propria password, in chiaro, all’entità autenticante

– la quale è in grado di verificare se la password inviata esiste e corrisponde all’utente da cui è stata inviata

I’m Alice, the password is fiddlesticks

Alic

e

Bo

b

Ovviamente, le intercettazioni costituiscono la minaccia principale

Un chiarimento

– un’autenticazione che richiede l’inserimento di un password non è detto che ricada nella categoria autenticazione basata su password

– se infatti le informazioni inviate risultano cifrate, (magari con una chiave derivata dalla password)

– allora si parlerà di autenticazione crittografica

Osservazioni

• Domanda – Visto che l’autenticazione crittografica è molto più

sicura, per quale ragione si usa l’autenticazione basata su password?

• Risposta – per consentire ad una persona di effettuare il log-in in

una workstation è difficile considerare protocolli di autenticazione non basati su password • una persona ha difficoltà a memorizzare delle chiavi segrete;

cioè delle stringhe di 64 bit

• sebbene, siano ormai disponibili dei gadget che permetterebbero di risolvere tale problema

Osservazioni

– sfortunatamente, anche nel caso di autenticazioni computer/computer si ricorre talvolta a protocolli basati su password

• perché ad esempio inizialmente il protocollo era di tipo uomo/macchina, ma poi si è evoluto in computer/computer

• altre volte i progettisti ritengono (forse a ragione) che l’uso di protocolli crittografici sia costoso in termini di risorse di elaborazione e di tempo di sviluppo e implementazione

• altre volte la crittografia è evitata a causa di questioni legali

Altre criticità

– si consideri il seguente scenario • un utente ha un account presso una workstation

• inoltre ha la necessità di accedere, previo inserimento di username e pwd, ad uno svariato numero di risorse in rete distribuite su server distinti

• per evitare la scomodità di inserire username e pwd ogni volta che deve accedere ad una risorse di rete

• sarebbe comodo che la workstation lo facesse in modo automatico al suo posto,

• cioè le credenziali con cui l’utente si è autenticato presso la workstation, possano venire inviate in modo automatico da quest’ultima ai vari server,

Altre criticità

• ma ciò comporta che deve essere usato lo stesso username e pwd presso ogni server

– Come è possibile avere la stessa password su molti sistemi diversi?

– Si potrebbe assegnare ad ogni sistema la stessa password in modo indipendente,

– ma se poi sorge la necessità di modificarne una, come è possibile garantire la sincronizzazione?

Attacchi alle password – Off-line vs On-line

• Gli attacchi alle password possono essere di tipo on-line o off-line

– in un attacco on-line si tenta di indovinare la password semplicemente inviandola al sistema autenticante

– per contrastarli, si può limitare il numero di tentativi

• ad esempio, gli sportelli bancomat ATM ritirano la tessera dopo tre inserimenti errati della password

• in alternativa il sistema potrebbe diventare sempre più lento all’aumentare dei tentativi e/o

• potrebbe insospettirsi e inviare una notifica ad un operatore di sicurezza


– invece, in un attacco off-line un avversario può catturare una quantità X derivata dalla password (ad esempio l’hash) con una tecnica nota

– e poi,

• prendendosi il tempo che vuole ed usando tutta la potenza di calcolo e di memoria di cui dispone

– scegliere password candidata p,

– convertirla nel modo noto in Xp

– e verificare se Xp = X

– ripetendo tale procedura se l’uguaglianza non sussiste


• Un attacco off-line è detto anche dictionary attack perché le password candidate vengono prese da un dizionario

– se un avversario può sferrare un attacco off-line, allora è necessario aumentare la grandezza dello spazio cui appartiene il segreto

Memorizzare info. per autenticazione

– Un server può autenticare un utente solo se ha accesso alle corrispondenti informazioni di autenticazione • hash delle password, codice identificativo, ecc..

• Molteplici sono i modi per gestire e memorizzare tali informazioni 1. Sono individualmente configurate in ogni server

• le info. dell’utente Alice sono configurate in modo indipendente in ogni server cui Alice ha accesso

2. Sono memorizzate in un Authentication Storage Node (ASN) che offre il servizio di repository • un server che deve autenticare Alice può richiederle

all’ASN poi può eseguire da se l’autenticazione


1. Sono gestite in un Authentication Facilitator Node (AFN) che offre il servizio di autenticazione

• un server che deve autenticare Alice, rigira le informazioni ricevute da Alice all’AFN il quale esegue l’autenticazione rispondendo Yes o No al server richiedente

– ovviamente, nei casi 2. e 3. è necessario che il server autentichi a sua volta l’ASN o l’AFN

• altrimenti qualcuno potrebbe spacciarsi per l’ASN/AFN e fornire informazioni di autenticazione false


• Riguardo al dove memorizzare tali informazioni di autenticazione – evitare database con password in chiaro

– qualcuno, Trudy, potrebbe catturare il database • violando il nodo (server) che lo ospita, o

• accedendo ad un backup

– nel caso 1. Trudy potrebbe impersonare tutti gli utenti di quel server • se un utente usa la stessa password su più server allora

potrebbe essere impersonato anche in questi

– nei casi 2. e 3., Trudy potrebbe impersonare tutti gli utenti di tutti i server dell’ASN/AFN


• Esiste chiaramente un trade-off: – la strategia 1. è più costosa, essendo distribuita,

ma il rischio è più confinato

– le strategie 2. e 3. sono meno costose, essendo centralizzate, ma sono più rischiose

• Anziché memorizzare le password in chiaro una possibilità è memorizzare l’hash – scegliendo in modo accurato la password si è

protetti anche da attacchi di tipo dictionary


• In alternativa, il database potrebbe memorizzare password cifrate (non in chiaro)

– non c’è il rischio di dictionary attack

– un intruso dovrebbe ottenere una chiave segreta “robusta”, cioè di elevata qualità

• non derivata con una tecnica nota da una password d’utente

– sembra pertanto che memorizzare password cifrate sia sempre la soluzione più sicura

– in pratica, è una scelta abbastanza giusta per la memorizzazione dei backup del database in supporti di memorizzazione esterni al server


– ma non lo è nel caso in cui si voglia proteggere il database in esercizio • se il nodo del database viene violato da Trudy,

• non dovrebbe essere difficile per Trudy ottenere la chiave di cifratura che in genere è memorizzata nell’hard disk del server

• in una posizione accessibile ad utenti con privilegi (ma gli intrusi quasi sempre riescono ad ottenere i privilegi)

• se la chiave non fosse nell’hard disk sarebbe peggio!

• vorrebbe dire che l’amministratore di sistema inserisce a mano la chiave segreta (128 it) ad ogni reboot … quindi la chiave sarà molto probabilmente salvata sul suo PC

– naturalmente è possibile combinare entrambe le tecniche cifrando il database con gli hash delle password • ottenendo i benefici di entrambe

AUTENTICAZIONE BASATA SULL’INDIRIZZO


Autenticazione basata sull’indirizzo

• Si ha un’autenticazione basata sull’indirizzo se l’identità della sorgente può essere inferita esaminando l’indirizzo di rete dal quale arrivano i pacchetti – l’idea base è che ciascun computer C memorizzi delle

informazioni che specificano gli account utenti, di altri computer, accreditati ad accedere a C • ad esempio, se l’utente Smith del calcolatore residente al

nodo N ha il permesso di accedere al computer C

• ed eseguire richieste quale il log-in e comandi come

• copy <source-file> <destination-file>

• se C deduce che una richiesta arriva dal nodo N e da parte di Smith, allora C onorerà tale richiesta


• L’autenticazione basata sull’indirizzo è sicura rispetto alle intercettazioni, ma è sottoposta alle seguenti minacce

– a) se qualcuno, diciamo Trudy, ottiene i privilegi su un nodo FOO

• oltre a poter accedere alle risorse di tutti gli utenti di FOO,

• può anche accedere alle risorse di rete di ogni utente con un account su FOO

– b) se Trudy può impersonare gli indirizzi di rete dei nodi, può accedere a tutte le risorse di rete di tutti gli utenti che hanno un account su qualcuno di tali nodi


– Dipendentemente dall’ambiente (tipo di rete, sistema operativo e configurazione), l’autenticazione basata sull’indirizzo può essere più o meno sicura rispetto ad inviare password in chiaro

– E’ chiaramente più conveniente ed è il meccanismo di autenticazione scelto in molti sistemi distribuiti

PROTOCOLLI DI AUTENTICAZIONE CRITTOGRAFICI


Protocolli di autenticazione crittografici

– I protocolli di autenticazione crittografici possono essere molto più sicuri sia di quelli basati su password (in chiaro) sia di quelli basati sull’indirizzo

• In un protocollo di autenticazione crittografico Alice prova la sua identità eseguendo delle operazioni crittografiche su quantità fornite da Bob

• Le operazioni crittografiche eseguite da Alice dipendono da un’informazione segreta nota solo ad Alice o al più anche a Bob

– I protocolli di autenticazione crittografici saranno ampiamente esaminati nel seguito

PASSWORD COME CHIAVI CRITTOGRAFICHE


Password come chiavi crittografiche

– Le chiavi crittografiche, in particolare quelle dei sistemi a chiave pubblica, sono costituite da sequenza binarie casuali molto lunghe

– una persona non è pertanto in grado di ricordare delle chiavi crittografiche

– ma è in grado di ricordare una password

– spesso è quindi conveniente disporre di tecniche per derivare delle chiavi crittografiche a partire da password • tecniche che trasformano una stringa di testo memorizzabile

da una persona in una chiave crittografica

Password Chiave DES

• Sia pwd una stringa di testo

• Calcola il digest hpwd = h(pwd)

• La chiave DES si ottiene selezionando 56 bit dal risultato hpwd

– è chiaramente molto più complicato e

computazionalmente costoso convertire una password in una chiave privata RSA

– dato che una chiave RSA deve godere di particolari proprietà aritmetiche

Password PU, PR – Jeff Schiller

• Jeff Schiller ha proposto un possibile modo per ottenere una coppia di chiavi RSA da una password in un tempo “plausibile”

– Convertire la password in un seme per un generatore di numeri casuali

– Usare tale generatore per generare i numeri primi grandi dai quali si ottengono la chiave pubblica e privata

– Si noti che eseguendo due volte la generazione delle chiavi RSA si ottengono le medesime chiavi

– Ovviamente nella pratica tale tecnica è computazionalmente inefficiente


– la generazione delle chiavi RSA richiede infatti di eseguire molti tentativi primi di ottenere un numero primo grande

– un trucco per accelerare i tempi è il seguente

– una volta trovata la prima coppia di chiavi, si contano il numero di tentativi effettuati per la generazione dei numeri primi p e di q • #tp, #tq = tentativi per p, tentativi per q

– si chiede all’utente di memorizzare oltre alla password anche tale coppia #tp, #tq

– l’esecuzioni successive dell’algoritmo possono rigenerare p e q in un sol colpo


• nel caso di autenticazione su una workstation si può anche pensare che la coppia #tp, #tq sia memorizzata nella workstation stessa

• non ha infatti alcun valore per chi non conosce la password d’utente a cui è associata

– tuttavia tecniche di questo tipo non sono usate perché rimangono comunque computazionalmente inefficienti

Chiave privata cifrata con la password

– La soluzione comunemente adottata per evitare la memorizzazione di una chiave privata PR è

– cifrare PR con una chiave segreta ottenuta dalla password: E(PR, Kpwd)

– e memorizzare E(PR, Kpwd) in una repository accessibile dalla workstation dell’utente

• specificando le credenziale dell’utente per la workstation stessa

– in modo tale che, la workstation dell’utente, diciamo Alice, possa in modo trasparente ad Alice recuperare prima Kpwd e poi decifrare la chiave privata

INTERCETTAZIONI E VIOLAZIONI DEL SERVER AUTENTICANTE


Scenario in esame

– si consideri un utente, Alice, che deve autenticarsi presso un server remoto Bob

• per poter fruire dei servizi resi dal server Bob

• L’autenticazione deve garantire che nessuno sia in grado di impersonare Alice

– anche se riesce ad intercettare i messaggi scambiati tra Alice e Bob, e/o

– riesce a violare il server Bob e ad accedere in modo non autorizzato al database contenente le informazioni per l’autenticazione

Requisiti di sicurezza

• consideriamo pertanto i seguenti requisiti d sicurezza

– R1) protezione rispetto eventuali intercettazioni delle informazioni trasmesse

• se un avversario intercetta tali informazioni non deve poter impersonare Alice

– R2) protezione rispetto eventuali violazioni del server e/o accessi in lettura non autorizzati al suo database

• se un intruso viola il server Bob e riesce ad accedere al database non deve poter impersonare gli utenti di Bob

Osservazioni/Domande

• Ovviamente, i requisiti R1) e R2) impongono l’adozione di una autenticazione crittografica

• Domande

– Come si può procedere?

– Conviene usare la password?

– Conviene usare tecniche crittografiche a chiave pubblica o a chiave segreta?

Uso di pwdAlice + PUBob

• Proviamo a combinare l’uso della password con tecniche crittografiche a chiave pubblica – la password di Alice è cifrata con la chiave pubblica di

Bob

– nel database del server Bob la password non è memorizzata in chiaro, ma viene memorizzato il suo digest

I’m Alice, {fiddlesticks}Bob

Alic

e

Bo

b

h(fiddlesticks)

PUBob PRBob


• La precedente soluzione soddisfa i requisiti R1 ed R2? – R1 non è soddisfatto

• un impostore potrebbe riusare il messaggio inviato da Alice ed impersonarla

• inoltre si potrebbe ottenere la password con un attacco dictionary se non viene applicato lo standard #PKCS1

– R2 è parzialmente soddisfatto • violando il server Bob si potrebbe ricavare la chiave privata PRBob

• se la password non è robusta un attacco off-line di tipo dictionary potrebbe ricavarla

I’m Alice, {fiddlesticks}Bob

Alic

e

Bo

b

h(fiddlesticks)

Domanda: è possibile modificare questo schema di autenticazione?

PUBob PRBob


• Si considerino le seguenti modifiche ove – random: numero random

• tale numero è implicito nello standard #PKCS1; se si segue tale standard può omettersi

– timestamp: intero che codifica l’ora attuale – salt: numero random unico associato ad ogni utente – f(): una qualche funzione deterministica; può anche

essere omessa

I’m Alice, {fiddlesticks||random||timestamp}Bob

Alic

e

Bo

b

h(f(salt||fiddlesticks))

PUBob PRBob


– ora R1 è abbastanza rispettato

• la quantità random permette di sventare attacchi di tipo dictionary sulle password cifrate con PUBob

• il timestamp non consente di riciclare messaggi “scaduti”; però, messaggi molto recenti potrebbero ancora essere riciclati

– invece R2 è ancora parzialmente soddisfatto

• violando il server Bob si potrebbe ricavare la chiave privata PRBob

• la presenza del salt rende più difficile l’attacco di tipo dictionary sugli hash memorizzati nel database

• anche se l’intruso potrebbe individuare il salt!?

… senza crittografia asimmetrica?

• Domanda

– Cosa succede se non fosse possibile ricorrere alla cifratura a chiave pubblica?

– Si assuma che Alice e Bob condividano un segreto SAB

– da cui sia possibile ottenere, con una procedura conosciuta, una password KAB

Uso di pwdAlice + segreto condiviso

– R1 continua ad essere soddisfatto abbastanza bene

– R2 non è soddisfatto: una violazione del server Bob permetterebbe di ottenere il segreto condiviso SAB

• il segreto condiviso SAB in genere non sarà protetto bene quanto la chiave privata di Bob PUBob

• la chiave privata PUBob è unica ed è associata al server Bob, può essere protetta in luoghi e modi particolarmente sicuri

• ad esempio potrebbe non essere salvata nell’hard disk, ma in una memoria non volatile speciale

Alic

e

Bo

b

h(f(salt||fiddlesticks))

SAB SAB I’m Alice, KAB{fiddlesticks||random||timestamp}Bob

Uso di password in chiaro

– utilizzando password in chiaro

– R1 non è soddisfatto

– R2 è soddisfatto abbastanza bene

I’m Alice, fiddlestikcs

Alic

e

Bo

b

h(f(salt||fiddlestikcs))

Chiavi crittografiche vs Password

– Nell’ipotesi che Alice (o il suo client) disponga di un qualche tipo di chiave crittografica

• PRAlice: una chiave privata, o

• KAB: una chiave segreta condivisa con Bob, non derivata da password

– E’ possibile migliorare i precedenti schemi di autenticazione?

– Conviene ancora usare tecniche a chiave pubblica o sono preferibili tecniche a chiave segreta?

Uso di PRAlice

• La seguente soluzione, – che non fa uso di password, – ma sfrutta le proprietà della firma digitale – soddisfa entrambi i requisiti R1 e R2

conosce PUAlice

I’m Alice

[R]Alice

R firmato con la chiave privata di Alice

R

Alic

e

Bo

b

Uso di KAB non derivata da pwd

• Tale soluzione invece,

– che non fa uso di password e

– sfrutta una chiave segreta condivisa KAB tra Alice e Bob

– soddisfa R1, ma non soddisfa R2; violando il server Bob si otterrebbe il segreto KAB

conosce KAB

I’m Alice

X(R, KAB)

X() è una qualche funzione crittografica X(∙) = h((∙), KAB) oppure X(∙) = KAB{∙}

R

Alic

e

Bo

b

Riassumendo

• Se si desidera soddisfare a pieno i requisiti R1 e R2 – conviene evitare l’uso di password

– ed è necessario ricorrere alla crittografia a chiave pubblica

– senza la crittografia a chiave pubblica diventa molto complicato, se non impossibile, soddisfare contemporaneamente R1 e R2,

– mentre è facile soddisfare o solo R1 o solo R2

INTERMEDIARI FIDATI Sistemi di autenticazione – Introduzione

Distribuzione delle chiavi segrete

• si assuma che la sicurezza di una rete si basi sulla tecnologia a chiave segreta

– se la rete ha n nodi, e

– ogni computer c deve poter autenticare ogni altro nodo

– c deve memorizzare n – 1 chiavi • una per ogni altro sistema della rete

– se un nuovo nodo viene aggiunto alla rete

– dovrebbero essere generate n nuove chiavi • per avere una chiave segreta condivisa con tutti gli n nodi

pre-esistenti

Distribuzione delle chiavi segrete

– sarebbe pertanto necessario distribuire tali n chiavi in modo sicuro a tutti gli altri nodi della rete

– tale strategia di gestione delle chiavi può aver senso solo per reti molto piccole!

β

γ

δ

ζ

ε

η

θ

α

Centri di distribuzione delle chiavi

– Un centro di distribuzione delle chiavi, Key Distribution Center (KDC), agevola la gestione/distribuzione delle chiavi segrete

– conosce le chiavi di tutti i nodi

– se un nuovo nodo si aggiunge alla rete, sola una chiave segreta, condivisa tra quel nodo e il KDC, deve essere generata

Comunicazione tra due nodi del KDC

β

γ

δ

ζ

ε

η

θ

α KDC

KαKDC chiave segreta condivisa tra il nodo α e il KDC KβKDC chiave segreta condivisa tra il nodo β e il KDC


• Se un nodo α deve comunicare con un nodo β

– α comunica con il KDC in modo sicuro, e • usando la loro chiave segreta condivisa KαKDC

– gli chiede di inviargli una chiave per comunicare con β

– il KDC autentica α, sceglie un numero random Rαβ da usare come chiave segreta condivisa tra α e β

– cifra Rαβ con la chiave segreta KKDCβ che condivide con β, e


– trasmette a β Rαβ cifrata insieme alle istruzioni che β deve usare per comunicare con α • in genere, il KDC non trasmette direttamente Rαβ cifrato a β,

ma lo invia ad α che poi lo inoltrerà a β

– il messaggio cifrato per β che il KDC invia ad α, e che α dovrà inoltrare a β è detto ticket

– oltre a contenere Rαβ il ticket contiene altre informazioni utili • data di scadenza, nome del nodo α, ecc.

KDC – Vantaggi

• I KDC semplificano la distribuzione delle chiavi – quando un nuovo utente deve essere aggiunto alla rete, o

– quando si sospetta che una chiave d’utente sia stata compromessa

• c’è un singolo punto della rete, il KDC, la cui configurazione deve essere aggiornata

• l’alternativa al KDC è installare le informazioni di un utente in ciascun server ove potrebbe accedere

KDC – Svantaggi

• L’uso dei KDC comporta però i seguenti svantaggi

– contiene tutte le informazioni per impersonare un utente ad un qualsiasi altro utente se compromesso tutte le risorse di rete risultano vulnerabili

– un KDC è un “single point of failure”, in caso di guasto nessuno può iniziare una comunicazione con uovi utenti • le chiavi precedentemente distribuite continuano a

funzionare

KDC – Svantaggi

– è possibile avere più KDC (KDC multipli) con lo stesso database di chiavi, ma ciò comporta

• una maggior complessità di gestione,

• costi extra per le macchine e per la replicazione dei protocolli, e

• maggiori vulnerabilità, è necessario proteggere più target da eventuali attacchi

– un KDC può costituire un collo di bottiglia

• in questa caso, avere più di un KDC può alleviare tale problema

Autorità di certificazione

– La distribuzione delle chiavi è più facile con la crittografia a chiave pubblica

• ogni nodo deve custodire soltanto la propria chiave privata

• tutte le chiavi pubbliche possono essere accessibili in un unico punto

– ma anche in questo caso continuano ad esserci dei problemi

• chi garantisce che le chiavi pubbliche disponibili in un dato punto siano corrette

• un intruso, Trudy, potrebbe sovrascrivere la chiave pubblica di Alice con la propria, riuscendo così ad impersonare Alice


– per evitare la falsificazione delle chiavi pubbliche si ricorre alle Autorità di Certificazione

– Una Autorità di Certificazione, Certification Authority CA, è un intermediario fidato che genera i certificati,

– cioè dei messaggi firmati dalla CA contenenti il nome, la chiave pubblica ed altre informazioni di uno specifico nodo

– tutti i nodi dovranno essere pre-configurati con la chiave pubblica della CA, in modo tale da poter verificare la sua firma sui certificati rilasciati • si tratta dell’unica chiave pubblica che devono conoscere a priori

Contenuto di un certificato

• Un certificato include – il nome utente

• persone fisica, organizzazione, server, applicazione, …

– la chiave pubblica dell’utente

– la data di scadenza

– un numero seriale

– e la firma, della CA che lo ha emesso, dell’intero contenuto del certificato

• lo standard X.509 per le infrastrutture a chiave pubblica ha definito il formato standard di un certificato

Visualizzazione di un certificato


– i certificati possono essere memorizzati nel luogo ritenuto più conveniente

– in un directory service, oppure

– ciascun nodo può memorizzare i certificati d’interesse e trasmetterli durante lo “scambio di autenticazione”

– in un certo senso le CA sono la controparte dei KDC nelle infrastrutture a chiave pubblica

– CA e KDC costituiscono l’intermediario fidato la cui compromissione può arrecare seri danni all’integrità della rete

Vantaggi della CA rispetto i KDC

• La CA non è necessario che sia on-line – può risiedere in una stanza fisicamente ben protetta

(magari con una guardia)

– si può limitare l’accesso alla CA ad una sola persona di grande fiducia • questa persona interagendo con la CA, genera il certificato di un

dato utente, lo memorizza su un qualche supporto di memoria esterna che può consegnare “a mano” al diretto interessato

– se la CA non è on-line • nessun potenziale intruso può accedervi per ottenere informazioni

utili

• non deve implementare protocolli di rete che richiedono elevata efficienza computazionale

• può essere implementata da un dispositivo estremamente semplice e pertanto molto più sicuro


• Se la CA dovesse “crashare”, la rete continuerebbe a funzionare – non sarebbe però possibile aggiungere nuovi utenti o

revocare certificati compromessi o di utenti sospetti

– pertanto non è essenziale avere CA multiple

• I certificati sono poco sensibili ad eventuali attacchi – se memorizzati in modo conveniente, ma potenzialmente

insicuro (ad es. in un servizio di directory),

– un sabotatore può cancellare i certificati, impedendo l’accesso ai corrispondenti nodi della rete (attacco DOS)

– ma non può creare dei certificati fasulli o modificarli in qualche modo se non dispone della chiave privata della CA


• Una CA compromessa non può decifrare le conversazioni tra due nodi (reali) da lei serviti – mentre un KDC compromesso può decifrare tutte le

conversazioni tra coppie di nodi da lui serviti

– una CA compromessa • può ingannare un utente, diciamo Alice

• inviandogli una falsa chiave pubblica di Bob

• e riuscire ad impersonare Bob in una comunicazione con Alice

• ma non può decifrare una comunicazione tra la vera Alice e il vero Bob

• la compromissione di una CA rimane un fatto molto grave, ma non quanto la compromissione di un KDC

Revoca di certificati

– Le CA presentano comunque il seguente svantaggio rispetto i KDC • supponiamo che Fred offra dei servizi di hosting per conto

dell’azienda X SpA

• la società X SpA fornisce a Fred un certificato (rilasciato a favore della X SpA) necessario ad autenticare il server Fred conosce la chiave privata della chiave pubblica certificata

• supponiamo inoltre che a causa di un contrasto con Fred, la X SpA decida di interrompere il rapporto di lavoro

• se il certificato è ancora valido Fred può continuare a rendere dei servizi per conto della X SpA, magari anche danneggiandola


• per la X SpA sarebbe importante informare gli utenti di non accettare il certificato generato per Fred e ancora in corso di validità

• con i KDC tale problema è di facile soluzione, basta rimuovere KFred dal KDC

– ovviamente si ha un problema analogo anche quando viene smarrita, o peggio rubata, la chiave privata associata alla chiave pubblica certificata


– nel caso delle CA non è facile estromettere qualcuno che detiene una chiave privata la cui chiave pubblica è certificata • si noti che potrebbe essere molto rischioso attendere la

scadenza naturale del certificato; in queste situazioni conviene revocare il certificato

• Si revoca un certificato quando, – a partire da un certo momento,

– non devono essere più considerate valide le firme generate con la chiave privata

– abbinata alla chiave pubblica contenuta nel certificato

Liste di certificati revocati

• La revoca di un certificato si attua inserendo un riferimento al certificato all’interno di una lista di revoca (Certificate Revocation List CRL)

– una CRL elenca una lista di numeri seriali di certificati da non onorare

– ogni CA pubblica periodicamente una nuova CRL che contiene tutti i certificati revocati e non scaduti


• Un certificato è valido se – la firma della CA è valida, – non è scaduto – non è inserito nella CRL più recente della CA che lo ha

emesso

– la CRL ha una data e ora di emissione • se un’applicazione vuole assicurarsi che nessuno dei

certificati che onora sia stato revocato entro un’ora prima della verifica

• allora deve essere trascorsa al più un ora dal momento in cui la CRL, consultata da tale applicazione, è stata emessa

• quindi, in questo caso, una nuova CRL deve essere pubblicata con una cadenza di un’ora


• un intruso potrebbe cancellare l’ultima CRL,

• in tal caso le applicazioni configurate per consultare esclusivamente CRL pubblicate nell’ultima ora si rifiuteranno di onorare tutti i certificati

• ma l’intruso non può impersonare un utente valido distruggendo la CRL o sovrascrivendola con una CRL più vecchia

– lo standard X.509 ha definito anche il formato delle CRL, in base a tale standard una CRL deve includere • una lista di numeri seriali di certificati revocati e non scaduti

• e una data e ora di emissione della CRL

• la firma dell’intera lista con la chiave privata della CA

Problema

– Supponiamo che Bob sia un’applicazione che deve autenticare l’utente Alice

• Illustrare un possibile protocollo di autenticazione a chiave pubblica, che includa una verifica della correttezza della chiave pubblica di Alice

Soluzione

– chiaramente Bob ha bisogno del certificato di Alice, CertAlice, e di una CRL recente

• Bob può ottenerli da un servizio di directory, oppure

• Alice li trasmette a Bob

Soluzione

– 0) Bob recupera il certificato di Alice CertAlice e una CRL recente

– 1) Consultando il certificato CertAlice individua la chiave pubblica di Alice PUAlice

– 2) Verifica la correttezza di PUAlice come segue • 2.1) se il certificato CertAlice è correttamente firmato dalla CA

che lo ha emesso e non è scaduto, e

• 2.2) la CRL è correttamente firmata dalla CA ed è sufficientemente recente e non contiene il certificato CertAlice

• allora Bob conclude che PUAlice è corretta (quindi è quella nel certificato)

Soluzione

– 3) Bob ed Alice iniziano uno scambio di messaggi seguendo uno schema di autenticazione a chiave pubblica, ad esempio

• 3.1) Bob invia una sfida R ad Alice

• 3.2) Alice firma R con la propria chiave privata ed invia [R]Alice a Bob

• 3.3) Bob verifica la firma di Alice ed in caso affermativo autentica Alice

Soluzione – schema

1) ottiene PUAlice

I’m Alice, CertAlice, CRL

[R]Alice

R

Alic

e

Bo

b

2) verifica correttezza PUAlice

3.1) genera R

3.2) calcola la firma [R]Alice

3.3) verifica la firma [R]Alice

Bibliografia






Autenticazione Crittografica Protocolli e Insidie

Luca Grilli

Premessa

• Le comunicazioni sicure quasi sempre richiedono una “stretta di mano” (handshake) preliminare per autenticare le parti comunicanti – spesso è necessario anche proteggere integrità e/o

confidenzialità delle informazioni trasmesse

• L’autenticazione richiede lo scambio di particolari messaggi tra le parti,

• e la conoscenza di particolari informazioni, alcune delle quali devono essere segrete

• Tutti questi aspetti vengono definiti nel protocollo


• Progettare protocolli di autenticazione (crittografici) sicuri nasconde molte insidie

– variazioni minime ad un protocollo sicuro possono introdurre delle falle molto pericolose

• per questo molti protocolli in uso presentano delle falle di sicurezza

• è cruciale comprendere a fondo le possibili falle di sicurezza di un protocollo

– attenzione alle modifiche a protocolli esistenti

– attenzione all’ambiente in cui il protocollo viene usato

Proprietà di un protocollo

• Oltre alla sicurezza sono importanti anche le prestazioni, ovvero l’efficienza del protocollo

• L’efficienza è data da

– numero di messaggi

– compattezza dei messaggi

– costo computazionale

– risorse di calcolo richieste


• Non esiste il protocollo migliore in senso assoluto – alcune minacce sono più frequenti e/o pericolose

in un dato contesto; in un altro possono anche non esistere

– è necessario tener conto delle risorse disponibili • CPU, memoria, hardware specializzato, spese per i

diritti di utilizzo di brevetti, ecc.

– dei vincoli progettuali relativi all’ambiente di uso

– e se gli utenti sono disposti a seguire le politiche di sicurezza

Iter progettuale di un protocollo

• Si parte da un primo protocollo – contenente sicuramente delle falle di sicurezza

• Si controllano tutte le debolezze immaginabili – relative al contesto d’impiego di quel protocollo

• Si rimuovono le debolezze una alla volta – attenzione, rimuovere una falla può introdurne altre non

presenti prima

• Rimossa una falla, si ricomincia daccapo e ci si arresta quando non ci sono più falle (tra quelle note!)

• conoscere le possibili falle è cruciale sia per progettare protocolli sicuri, sia per comprendere protocolli noti

Protocolli basati su password (in chiaro)

– molti protocolli di autenticazione esistenti furono progettati per ambienti in cui

• le intercettazioni non erano un problema, ed

• eventuali utenti malevoli erano considerati poco esperti

– ad esempio i protocolli basati su password che non includono alcun meccanismo di cifratura

• Alice (l’iniziatore) invia a Bob il suo nome e la password in chiaro attraverso la rete

• Bob verifica nome utente e password,

• in caso affermativo la comunicazione prosegue,

• senza alcuna ulteriore attenzione alla sicurezza (nessuna cifratura, nessun controllo di integrità crittografico)

Protocolli crittografici challenge/response

• Un miglioramento significativo della sicurezza si è avuto sostituendo – la trasmissione della password in chiaro

– con il meccanismo a sfida/risposta crittografico (cryptographic challenge/response)

• nelle prossime slide, si esamineranno

– protocolli crittografici a sfida e risposta basati sulla conoscenza di un segreto condiviso • usando sia algoritmi di cifratura a chiave segreta sia algoritmi

di digest

– successivamente, si discuteranno protocolli simili utilizzando la tecnologia a chiave pubblica

PROTOCOLLI A SFIDA E RISPOSTA UNIDIREZIONALI (“LOGIN ONLY”)

Autenticazione Crittografica – Protocolli e Insidie

Segreto condiviso – Notazione

R: sfida; numero casuale e non prevedibile

KAlice-Bob{R}: cifratura di R con un algoritmo a chiave segreta (DES, AES); KAlice-Bob è la chiave di cifratura

h(KAlice-Bob, R): hash di R dipendente dal segreto KAlice-Bob ad esempio la sfida R viene concatenata con KAlice-Bob

f(KAlice-Bob, R): quantità ottenuta applicando ad R una trasformazione crittografica dipendente dal segreto cioè f(KAlice-Bob, R) può essere sia KAlice-Bob{R} sia h(KAlice-Bob, R)

Prot. 1 – Chiave segreta unidirezionale

– si consideri il seguente protocollo di tipo “login only” • rappresenta un notevole passo in avanti rispetto a spedire la

password in chiaro

• uno spione non può impersonare Alice “ascoltando” lo scambio perché la sfida R cambia di volta in volta in modo non prevedibile

I’m Alice

f(KAlice-Bob, R)

a challenge R

Alic

e

Bo

b

Bob autentica Alice sfruttando un segreto condiviso KAlice-Bob

Prot. 1 – Debolezze

• Non c’è mutua autenticazione

– Bob autentica Alice, ma non il viceversa

• se Trudy può ricevere i pacchetti inviati all’indirizzo di rete di Bob, e rispondere con l’indirizzo di rete di Bob (o attraverso altri mezzi convince Alice che il suo indirizzo è quello di Bob)

• Alice sarà ingannata è crederà che Trudy è Bob

• Trudy non ha bisogno di conoscere il segreto condiviso KAlice-Bob per impersonare Bob

• deve solo limitarsi ad inviare ad Alice una qualsiasi vecchia sfida R e ignorare la sua risposta


• Se questo è l’intero protocollo

– cioè se non è prevista una protezione della confidenzialità del resto della conversazione

• allora Trudy può dirottare la conversazione dopo lo scambio iniziale,

• assumendo che sia in grado di generare pacchetti aventi per source address l’indirizzo di Alice (IP spoofing)

• potrebbe anche essere utile, ma non essenziale, per Trudy, poter ricevere pacchetti indirizzati ad Alice


• Se il segreto condiviso KAlice-Bob fosse derivato da una password,

– allora conoscendo R, f(KAlice-Bob, R) e l’algoritmo per ottenere la chiave dalla password,

– un intercettatore potrebbe sferrare un attacco off-line sulla password

• sceglie una parola w, quale password candidata

• calcola la relativa chiave segreta Kw

• e verifica se f(Kw, R) = f(KAlice-Bob, R)

• in caso negativo ritenta


• Qualcuno che accede (in lettura) al server Bob potrebbe ottenere KAlice-Bob – ciò è particolarmente rischioso se KAlice-Bob è

derivata da una password, e

– le password sono memorizzate in un database di Bob • proteggere il database implica proteggere tutti i suoi

backup

• impedendone l’accesso fisico o

• cifrando il contenuto e proteggendo in qualche modo la chiave di cifratura

Prot. 1 – Impiego

• Nonostante i precedenti svantaggi,

• se le risorse per aumentare la sicurezza sono molto limitate,

• il protocollo 1 costituisce un’alternativa molto più sicura rispetto ad inviare password in chiaro

– anche se KAlice-Bob viene derivata dalla password

Prot. 2 – Variante del Prot. 1

– Una piccola variante del prot. 1 è la seguente

• Bob sceglie una sfida random R, la cifra, e trasmette il risultato

• Alice decifra la quantità ricevuta, usando KAlice-Bob per ottenere R, ed invia R a Bob

I’m Alice

R

KAlice-Bob{R}

Alic

e

Bo

b

Bob autentica Alice sfruttando una chiave segreta condiviso KAlice-Bob

Prot. 2 vs Prot. 1

– Prot. 2 richiede l’uso di operazioni crittografiche invertibili • Prot. 1 può implementarsi usando solo algoritmi di hash; in

genere gli algoritmi di hash offrono migliori prestazioni e maggior portabilità

– Se KAlice-Bob è derivata da una password ed è pertanto vulnerabile ad attacchi dictionary • se inoltre R è una quantità riconoscibile, ad es. 32 bit

random + 32 bit nulli di padding Trudy può eseguire un attacco dictionary senza dover essere in grado di intercettare i messaggi (cosa non sempre facile)

• ovviamente, se può intercettare i messaggi scambiati tra le parti può eseguire un attacco dictionary in entrambi i protocolli

Prot. 2 vs Prot. 1

– Se R è una quantità riconoscibile con tempo di vita limitato; ad esempio R = random||timestamp

– anche Alice può autenticare Bob (autenticazione mutua)

• infatti, soltanto chi conosce KAlice-Bob può generare

KAlice-Bob{R} = KAlice-Bob{random||timestamp}

– è essenziale che R abbia una durata temporale molto limitata per evitare che KAlice-Bob{R} possa essere “riciclato” da un falso Bob

Prot. 3 – altra variante del Prot. 1

– la seguente è un’altra variante del protocollo 1 • utilizzando un timestamp invece di una sfida random R

• è sufficiente un solo messaggio per l’handshake

• Alice cifra l’istante temporale corrente,

• Bob decifra il risultato e si assicura che sia un istante temporale circa uguale a quello fornito dal suo orologio

• è necessario che gli orologi di Alice e Bob siano “ragionevolmente” ben sincronizzati

I’m Alice, KAlice-Bob{timestamp}

Alic

e

Bo

b

Bob autentica Alice sfruttando la sincronizzazione degli orologi e un segreto condiviso KAlice-Bob

Prot. 3 vs Prot. 1

– il prot. 3 può facilmente rimpiazzare un protocollo non crittografico in cui la password è inviata in chiaro

• non è necessario aggiungere lo scambio di ulteriori messaggi

– il prot. 3 è più efficiente del prot. 1

• oltre a risparmiare due messaggi, il server Bob non deve mantenere alcuno stato volatile (ad esempio R) riguardo Alice (assumendosi qualche rischio)

• inoltre può aggiungersi ad un qualsiasi protocollo di tipo request/response (come l’HTTP) ottenendo un’autenticazione mutua; basta che Bob invii ad Alice una risposta dipendente in modo opportuno dal suo timestamp originario (si vedrà in seguito)

Prot. 3 vs Prot. 1

– qualcuno potrebbe impersonare Alice intercettando e riusando KAlice-Bob{timestamp}

• tale attacco va però eseguito subito dopo aver intercettato KAlice-Bob{timestamp}; il timestamp generato dal server Bob non deve essere troppo diverso da quello di Alice

• un modo per sventare tale minaccia è memorizzare nel server Bob tutti i timestamp ricevuti e non ancora scaduti

– si ha un’altra potenziale debolezza se Alice usa lo stesso segreto KAlice-Bob con più server distinti

• un intercettatore che opera in modo veloce può ottenere la quantità KAlice-Bob{timestamp} trasmessa ad un server per impersonare Alice con un altro server

Prot. 3 vs Prot. 1

• tuttavia, tale minaccia è sventabile concatenando il nome del server con il timestamp

• anziché KAlice-Bob{timestamp} va inviato • KAlice-Bob{“Bob”||timestamp}

– il prot. 3 è vulnerabile ad eventuali modifiche all’orologio di sistema del server Bob • timestamp scaduti possono essere riusati

– se la sicurezza dipende dall’ora la configurazione dell’ora richiederà un handshake sicuro • un handshake basato sull’istante corrente potrebbe fallire se

i due orologi non sono sincronizzati • necessaria un’autenticazione basata su un handshake di

tipo challenge/response per la sincronizzazione degli orologi

Prot. 3 vs Prot. 1

– nel prot. 1, calcolare f(KAlice-Bob, R) voleva dire

• calcolare KAlice-Bob{R} oppure

• calcolare l’hash h(R||KAlice-Bob)

– ciò continua a valere nel caso del prot. 3, ma con piccole complicazioni aggiuntive se si usa l’hash

• Bob deve eseguire un certo numero di tentativi per verificare che h(timestamp||KAlice-Bob) sia stato generato da Alice,

• se si accettano 10 minuti di differenza tra i due orologi

• e il timestamp è espresso in minuti

• allora 20 tentativi sono sufficienti

• ma per timestamp in microsecondi sono necessari più di un miliardo di tentativi!

Protocollo 4

– assumendo che si voglia utilizzare un timestamp in microsecondi e

– una funzione di hash anziché una funzione crittografica invertibile

– una possibile soluzione è che Alice trasmetta anche il timestamp non cifrato

I’m Alice, timestamp, hash(KAlice-Bob, timestamp)

Alic

e

Bo

b

Bob autentica Alice calcolando l’hash di un timestamp ad alta risoluzione e sfruttando un segreto condiviso KAlice-Bob

Prot. 5 – Chiave pubblica unidirezionale

– Tutti i precedenti protocolli, a chiave segreta, consentono a Trudy di impersonare Alice se può leggere il database del server

– Utilizzando la tecnologia a chiave pubblica questa vulnerabilità può essere evitata

I’m Alice

[R]Alice

R

Alic

e

Bo

b

Bob autentica Alice verificando la sua firma digitale

Protocollo 5

– [R]Alice: R firmato da Alice; cioè cifrato con la sua chiave privata PRAlice

• Bob verifica la firma [R]Alice usando la chiave pubblica di Alice PUAlice

• ed accetta il login se il risultato è R

– il vantaggio di questo protocollo è che il database di Bob non è più vulnerabile agli accessi in lettura non autorizzati

– tuttavia, il database di Bob va comunque protetto da modifiche non autorizzate, ma non da accessi non autorizzati in lettura

• qualcuno potrebbe modificare la chiave pubblica di Alice!

Prot. 6 – Variante di Prot. 5

– Bob sceglie R e la cifra con PUAlice

– Alice dimostra di conoscere PRAlice decifrando {R}Alice e recuperando R

– un problema di questa variante è che molte tecnologie a chiave pubblica (si pensi a DSS) permettono solo di firmare e non di decifrare

I’m Alice

R

{R}Alice

Alic

e

Bo

b

Bob autentica Alice se lei può decifrare un messaggio cifrato con la sua chiave pubblica

Prot. 5 e 6 – Un serio problema

• In entrambi i protocolli 5 e 6 c’è un potenziale serio problema – il protocollo 5 permette di ingannare qualcuno a

firmare qualcosa • si supponga di avere una quantità Q che si desidera

venga firmata da Alice

• se si è in grado di impersonare l’indirizzo di rete di Bob

• si può attendere che Alice effettui il login

• e fornirle la quantità Q quale sfida da firmare

• Alice firmerà la sfida fornendo [Q]Alice all’attaccante


– similmente, il protocollo 6 permette ad un attaccante di decifrare un messaggio cifrato con PUAlice

• se un attaccante vuole decifrare {msg}Alice

• impersonando l’indirizzo di rete di Bob

• può attendere che Alice effettui il login

• e fornirle la quantità {msg}Alice quale sfida cifrata da decifrare

• così facendo, otterrà da Alice msg


• Come è possibile evitare tali attacchi?

• La regola generale è evitare di usare la stessa chiave per due scopi diversi

– a meno che i vari protocolli non siano coordinati in modo tale che un attaccante non possa mai usarne uno per violarne un altro

– un esempio di coordinamento è vincolare la struttura di R in base al tipo di applicazione

Sfide R strutturate

– ad esempio la struttura di R dovrebbe prevedere un campo type, da concatenare con il messaggio vero e proprio, che dipende dal tipo di protocollo/applicazione

• in questo modo il protocollo è incorporato nella firma

• quindi non è possibile “passare da un protocollo all’altro” senza violare il contenuto nel campo type

– nel caso di RSA, tali aspetti sono definiti nello standard PKCS

Osservazioni

• si noti pertanto che valgono le seguenti considerazioni

– è possibile progettare singoli protocolli sicuri,

– che complessivamente introducono delle vulnerabilità (prima assenti)

– è possibile progettare un nuovo protocollo sicuro il cui dispiegamento potrebbe compromettere la sicurezza degli schemi esistenti

PROTOCOLLI A SFIDA E RISPOSTA MUTUA AUTENTICAZIONE


Prot. 7 – Mutua autent. a chiave segreta

• Se si desidera autenticare reciprocamente ambo le parti • è sufficiente eseguire uno scambio di autenticazione in

entrambe le direzioni

f(KAlice-Bob, R1)

f(KAlice-Bob, R2)

R2

Alic

e

Bo

b

Mutua autenticazione basata su un segreto condiviso KAlice-Bob

R1

I’m Alice

Prot. 8 – Mutua autent. a chiave segreta

• Il protocollo 7 richiede lo scambio di cinque messaggi complessivi (poco efficiente)

• Sembra immediato poter ridurre a tre il numero di messaggi caricando in ogni messaggio più informazioni

I’m Alice, R2

f(KAlice-Bob, R1)

R1, f(KAlice-Bob, R2)

Alic

e

Bo

b

Mutua autenticazione ottimizzata basata su un segreto condiviso KAlice-Bob

Prot. 8 – Reflection Attack

• Il protocollo 8, più compatto del 7, è ora vulnerabile ad un attacco di tipo reflection – si supponga che Trudy voglia impersonare Alice

– Trudy inizia il protocollo 8,

– ma quando riceve la sfida di Bob non può proseguire; non potendo cifrare R1

I’m Alice, R2

R1, f(KAlice-Bob, R2) Tru

dy

Bo

b

Inizio dell’attacco reflection (sessione 1)

Prot. 8 – Reflection Attack

– tuttavia, Trudy può interrompere temporaneamente le sessione corrente

– e può iniziarne una nuova usando R1 quale sfida per Bob

– Trudy non può completare la seconda sessione; non può cifrare R3

– ma ora conosce f(KAlice-Bob, R1) e può completare la prima sessione rimasta appesa

I’m Alice, R1

R3, f(KAlice-Bob, R1) Tru

dy

Bo

b

Seconda sessione nell’attacco reflection

Attacco di tipo reflection

Trudy (sessione 1) Bob

Trudy (sessione 2)

Sull’attacco di tipo reflection

• Un attacco di tipo reflection è facile da sferrare se – è possibile aprire simultaneamente più connessioni con lo

stesso server – ci sono più server che condividono uno stesso segreto con

Alice

• Tale attacco può essere sventato con un po’ di attenzione e comprendendo bene la debolezza che sfrutta

• ovvero che Alice e Bob sono perfettamente interscambiabili – la risposta ad una stessa sfida è identica

Protezioni per attacchi di tipo reflection

• L’idea è quella di differenziare, in qualche modo, la risposta di Alice e quella di Bob ad una stessa sfida; seguono alcune possibili soluzioni

– Usare chiavi differenti

• una possibilità è che Alice e Bob condividano due chiavi completamente differenti KAAB e KABB; Alice cifra con KAAB, mentre Bob cifra con KABB

• in alternativa, una delle chiavi può essere derivata dall’altra:

• KABB = -KAAB oppure KABB = KAAB + 1 oppure

• KABB = KAAB F0F0F0F0F0F0F0F016

Protezioni per attacchi di tipo reflection

– Usare sfide strutturalmente differenti, garantire che la sfida dell’iniziatore abbia una struttura diversa da quella di chi risponde

• ad esempio, l’iniziatore (Alice) potrebbe usare un numero dispari mentre il risponditore un numero pari

– Usare risposte dipendenti dal risponditore la risposta non consiste nella cifratura della sola sfida, ma viene aggiunta un’informazione associata in modo univoco al risponditore

• ad esempio, la risposta ad una sfida R non è semplicemente f(K, R) ma f(K, R||”nome-id-risponditore”)

Domanda

• Il protocollo 7 è vulnerabile ad un attacco di tipo reflection? Per quale ragione?

• La risposta è NO

– tale protocollo segue infatti un altro importante principi generale:

– idealmente, l’iniziatore dovrebbe essere il primo a provare la sua identità

Altra vulnerabilità del Prot. 8

• assumendo che il segreto condiviso KAlice-Bob sia derivato da una password

– Trudy può eseguire un attacco off-line sulla password senza dover intercettare alcuna comunicazione tra Alice e Bob (tale vulnerabilità non esiste nel protocollo 7)

• Trudy deve solo inviare un messaggio a Bob affermando di essere Alice e includere un numero R da cifrare (attacco di tipo testo in chiaro selezionato)

• ottenendo pertanto la coppia R, f(KAlice-Bob, R) che può essere utilizzata per indovinare la password

Prot. 9

– aggiungendo un messaggio al protocollo 8 è possibile renderlo molto più robusto ad attacchi off-line sulla password

• il nuovo protocollo è chiaramente meno efficiente

I’m Alice

f(KAlice-Bob, R2)

f(KAlice-Bob, R1), R2 Alic

e

Bo

b

Mutua autenticazione parzialmente ottimizzata basata su un segreto condiviso KAlice-Bob

R1

Prot. 9

• ora Trudy non può più effettuare un attacco off-line sulla password semplicemente spacciandosi per Alice, senza dover intercettare i messaggi

– tuttavia, impersonando l’indirizzo di Bob può tentare di ingannare Alice facendogli stabilire una connessione con lei

– tale vulnerabilità non va ignorata, ma è comunque molto più difficile da sfruttare per un attaccante

Prot. 10 – Mutua autent. a chiave pubblica

• Assumendo che Alice e Bob conoscano ognuno la chiave pubblica dell’altro

• Utilizzando la tecnologia a chiave pubblica, possono autenticarsi reciprocamente scambiandosi tre messaggi

I’m Alice, {R2}Bob

R1

R2, {R1}Alice

Alic

e

Bo

b

Mutua autenticazione a chiave pubblica (basata sulla cifratura/decifratura)

Prot. 11 – Mutua autent. a chiave pubblica

• Una variante del protocollo 10 e che fa uso della firma digitale è la seguente

I’m Alice, R2

[R1]Alice

R1, [R2]Bob

Alic

e

Bo

b

Mutua autenticazione a chiave pubblica (basata sulla firma digitale)

Prot. 9 e 10 – Alcuni problemi

• supponendo che Alice sia una persona (o una workstation)

– Alice non può ricordare la chiave pubblica di Bob PUBob

• (nel caso della workstation, quest’ultima potrebbe non avere in memoria PUBob )

– (a) Come fa Alice ad ottenere PUBob?

• una possibilità è che Bob stesso invii PUBob ad Alice

• ciò non sarebbe però sicuro se Bob venisse impersonato da Trudy


• si assuma che Alice sia un utente umano collegato ad una workstation

– (b) un altro problema è il recupero della chiave privata di Alice PRAlice considerando che Alice può, al massimo, ricordare una password • convertire una password in una chiave segreta è fattibile in

modo efficiente

• convertire invece una password in una coppia PU, PR non è altrettanto semplice

– la soluzione generalmente adottata per il problema b) consiste nel recuperare PRAlice da un servizio di directory o, in alcuni casi, da Bob stesso


– ovviamente, PRAlice non è memorizzata in chiaro, ma è cifrata con una chiave segreta derivata dalla password di Alice

– a questo punto, anche il problema a) può risolversi allo stesso modo

• memorizzando PUBob in un servizio di directory oppure presso Bob stesso

– a tale scopo esistono due possibili modi

• 1) memorizzare PUBob cifrato con la chiave segreta di Alice derivata dalla sua password


• per ingannare Alice, un impostore, impersonando Bob, dovrebbe saper cifrare una chiave pubblica falsa (di cui conosce la chiave privata) con la chiave segreta di Alice

• 2) memorizzare un certificato per la chiave pubblica di Bob firmato con la chiave privata di Alice

• una volta che la workstation recupera PRAlice, può verificare la validità del certificato per PUBob

Prot. 11 – Mutua autent. con timestamp

– Utilizzando dei timestamp, anziché sfide random, è possibile ottenere un protocollo di mutua autenticazione di due soli messaggi • tale soluzione è molto utile, può essere facilmente

aggiunta ai protocolli a richiesta/risposta (HTTP)

• senza dover aggiungere un ulteriore messaggio

I’m Alice, f(KAlice-Bob, timestamp)

f(KAlice-Bob, timestamp + 1) Alic

e

Bo

b

Mutua autenticazione basata sulla sincronizzazione degli orologi e su un segreto condiviso KAlice-Bob


– per evitare che Trudy possa impersonare Bob riusando f(KAlice-Bob, timestamp) • copia la quantità crittografica di Alice e gliela

restituisce!

– nella risposta viene richiesto un timestamp diverso, cioè timestamp + 1

– ovviamente, sono possibili altre soluzioni • usare chiavi diverse per cifrare il timestamp

• concatenare il proprio nome al timestamp prima di applicare f( )

• o in generale, rendere la risposta dell’iniziatore e del risponditore non interscambiabili


• chiaramente, tutte le questioni viste nel caso unidirezionale e riguardanti gli orologi continuano ad essere valide

– l’idea di usare timestamp + 1 è stata introdotta nel protocollo Needham-Schroeder e ripresa in Kerberos V4

– non si tratta però della scelta migliore

• Trudy intercettando la risposta di Bob potrebbe riusarla per impersonare subito dopo Alice

• Bob potrebbe mantenere in cache tutte le coppie timestamp, timestamp + 1 incontrate, ma tale soluzione non è elegante

Prot. 11’ – Mutua autent. con timestamp

• se esistono più repliche di Bob aventi la stessa chiave, sarebbe necessario sincronizzare le loro cache oppure concatenare il timestamp con un identificatore univoco di ogni replica

• una scelta migliore potrebbe essere concatenare al timestamp un flag che specifica se il messaggio è inviato dall’iniziatore o dal risponditore

I’m Alice, f(KAlice-Bob, “S”||timestamp)

f(KAlice-Bob, “R”||timestamp) Alic

e

Bo

b

Mutua autenticazione basata sulla sincronizzazione degli orologi e su un segreto condiviso KAlice-Bob

CIFRATURA/INTEGRITÀ DEI DATI Autenticazione Crittografica – Protocolli e Insidie

Cifratura/Integrità dei dati

– Al fine di fornire protezione dell’integrità e della confidenzialità dei dati da trasmettere dopo lo scambio di autenticazione

– Alice e Bob devono necessariamente usare la crittografia (a chiave segreta) per cifrare e/o aggiungere dei controlli di integrità crittografici

– L’esecuzione di tali operazioni richiede preliminarmente che le parti stabiliscano una chiave segreta di sessione (session key) • anche se già condividono dei segreti a lungo termine che

permetterebbero di cifrare o di eseguire dei controlli di integrità


– Tipicamente, una chiave di sessione viene stabilita modificando lo scambio di autenticazione in modo tale che terminato l’handshake le due parti condividano una chiave segreta

– Esamineremo come procedere in relazione ai seguenti scambi di autenticazione • Chiave segreta: Alice e Bob condividono una chiave segreta

KAlice-Bob (che non è la chiave di sessione)

• Chiave pubblica: Alice e Bob conoscono ciascuno la chiave pubblica dell’altro e chiaramente la propria chiave privata

• Chiave pubblica unidirezionale: soltanto una parte ha una coppia PU, PR; l’autenticazione è unidirezionale


– ovviamente, un intercettatore non deve essere in grado di ottenere la chiave di sessione

– una volta illustrato come ottenere una chiave di sessione

• per ciascuno degli scenari precedenti

– si illustrerà come utilizzarla per cifrare e/o aggiungere dei controlli di integrità crittografici

Autenticazione a chiave segreta

– KAlice-Bob: segreto a lungo termine condiviso tra Alice e Bob

– si consideri lo schema di autenticazione riportato sotto, anche se quanto detto potrà applicarsi al caso di • mutua autenticazione; anziché R ci saranno R1 e R2

• autenticazione mediante timestamp anziché sfide random R

– in ogni caso, c’è sufficiente informazione per stabilire una chiave di sessione condivisa

I’m Alice

KAlice-Bob{R}

R

Alic

e

Bo

b

Autenticazione con chiave segreta KAlice-Bob


– una possibile chiave di sessione è Ks = (KAlice-Bob + 1){R}

– in generale, una chiave di sessione può ottenersi

• modificando KAlice-Bob in qualche modo; Kmodified = f(KAlice-Bob)

• e cifrando la sfida R con la chiave modificata

– il risultato è la chiave di sessione Ks

Ks = Kmodified{R} = (f(KAlice-Bob)){R}

I’m Alice

KAlice-Bob{R}

R

Alic

e

Bo

b

Autenticazione con chiave segreta KAlice-Bob


• Domanda

– Perché è necessario modificare KAlice-Bob?

– Perché non è possibile usare KAlice-Bob{R} come chiave di sessione?

• Risposta

– KAlice-Bob{R} non può utilizzarsi perché è trasmessa da Alice nel terzo messaggio dell’handshake!


• Domanda

– KAlice-Bob{R+1} può andare bene?

• Risposta

– Tale chiave di sessione non è sicura per una ragione molto sottile

• si supponga che Alice e Bob abbiano iniziato una conversazione e Bob abbia inviato R come sfida

• Trudy potrebbe aver registrato l’intera conversazione, cifrata con Ks = KAlice-Bob{R+1}


• in seguito, Trudy potrebbe impersonare l’indirizzo di rete di Bob in una successiva comunicazione con Alice

• e dichiarandosi Bob, potrebbe inviare R+1 come sfida

• alla quale Alice risponderebbe con KAlice-Bob{R+1}

• Trudy sarebbe in grado di decifrare la precedente conversazione (registrata) tra Alice e Bob

I’m Alice

KAlice-Bob{R+1}

R+1

Alic

e

Tru

dy

as B

ob

Trudy impersona Bob


– in definitiva, Alice e Bob, dopo lo scambio di autenticazione, conoscono oltre KAlice-Bob anche R • molte combinazioni di tali quantità permettono di

ottenere una chiave di sessione sicura,

• ma ci sono anche combinazioni non accettabili

– si noti che una buona chiave di sessione deve • variare da sessione a sessione

• non essere indovinabile da un intercettatore

• e non deve ottenersi cifrando con KAlice-Bob una quantità X, dove X è un valore che può essere predetto o estratto da un intruso (come ad esempio X = R + 1)

Autent. a chiave pubblica bidirezionale

– nel caso di autenticazione a chiave pubblica bidirezionale • Alice e Bob conoscono la propria chiave privata e la chiave

pubblica dell’altro

– per definire una chiave (segreta) di sessione condivisa Ks esistono varie possibilità


R1, {R}Bob

R2, {R1}Alice

Alic

e

Bo

b

Ks = R

(1) Ks = R – Alice invia {R}Bob

– una parte, diciamo Alice,

• sceglie un numero random R; che sarebbe la chiave di sessione

• lo cifra con la chiave pubblica di Bob

• ed invia a Bob {R}Bob

– questo schema presenta la seguente vulnerabilità

• un intruso, Trudy, può dirottare la conversazione scegliendo un suo R, cifrandolo con la chiave pubblica di Bob

• e inviando il risultato a Bob al posto della chiave cifrata fornita da Alice

• contestualmente dovrebbe impersonare l’indirizzo di rete di Alice

(2) Ks = R – Alice invia [{R}Bob]Alice

– rispetto a prima Alice firma la quantità {R}Bob

– e invia a Bob [{R}Bob]Alice

– Bob verifica prima la firma di Alice usando PUAlice

– e poi decifra con la propria chiave privata {R}Bob riottenendo R


R1, [{R}Bob]Alice

R2, {R1}Alice

Alic

e

Bo

b

Ks = R


– l’attacco precedente di Trudy

• scegliere un proprio R, in luogo di quello di Alice, e inviarlo a Bob crittografato

– ora non può funzionare perché Trudy non è in grado di forgiare la firma di Alice

– tuttavia, se si vuole essere paranoici, c’è ancora una “piccola” vulnerabilità

• che può essere ridotta parzialmente (vedi caso (3)) o del tutto (vedi caso (4))


– la vulnerabilità è la seguente:

• si supponga che Trudy registri una intera conversazione tra Alice e Bob; inclusi i dati cifrati con la chiave di sessione

• si supponga inoltre che “successivamente” (dopo un minuto/giorno/mese) Trudy riesca a violare il server Bob e ad ottenere tutti i suoi segreti; quindi anche PRBob

• ottenendo PRBob Trudy può recuperare la chiave di sessione dalle informazioni trasmesse, in particolare da [{R}Bob]Alice può ottenere Ks = R


– quindi Trudy può decifrare la conversazione cifrata tra Alice e Bob, precedentemente registrata

– in altri termini la soluzione (2) permette di sferrare degli attacchi alla confidenzialità “retroattivi” se nel futuro un avversario riuscisse a violare Bob

(3) Ks = R P – R e P non inviate in chiaro

• similmente a (2),

– Alice genera una quantità random R – e invia {R}Bob a Bob – Bob genera una quantità random P – e invia {P}Alice a Alice – terminata la conversazione Alice e Bob

dimenticheranno R e P


R1, {R}Bob

R2, {R1}Alice, {P}Alice

Alic

e

Bo

b

Ks = R P

genera R

genera P

(3) Ks = R P – R e P non inviate in chiaro

– definendo Ks = R P, per ottenere la chiave di sessione Trudy deve • registrare lo scambio tra Alice e Bob,

• violare Bob per ottenere PRBob e quindi R

• ma anche violare Alice per ottenere PRAlice e quindi P

– per ottenere Ks Trudy dovrebbe violare entrambi


R1, {R}Bob

R2, {R1}Alice, {P}Alice

Alic

e

Bo

b

Ks = R P

genera R

genera P

(3) vs (2)

• Domanda

– nel caso (2) Alice deve firmare la sua quantità (Alice invia [{R}Bob]Alice) invece di inviare direttamente {R}Bob

– Perché nel caso (3) ciò non è necessario?

(3) vs (2)

• Risposta – Alice e Bob non hanno bisogno di firmare le quantità

da loro inviate poiché,

– anche se Trudy riesce a sostituire {R}Bob con una quantità a lei nota {R’}Bob

– non sarebbe comunque in grado di ottenere la chiave di sessione che vedrebbe Bob, cioè Ks’ = R’ P • per ottenere P Trudy dovrebbe decifrare {P}Alice

– al massimo, Trudy può impedire che Alice e Bob dialoghino (attacco DoS), ma non può ottenere il testo in chiaro di una loro conversazione

(4) Usare Diffie-Hellman

– Alice e Bob possono effettuare uno scambio Diffie-Hellman autenticato (già esaminato)

– dove ognuno firma la quantità da inviare all’altro

– si supponga che le quantità g e p siano pubbliche

I’m Alice, [TA]Alice

[TB]Bob Alic

e

Bo

b

Ks = KAB = TBsA mod p = TA

sB mod p = KBA

genera sA

TA = gsA mod p genera sB

TB = gsB mod p

(4) Usare Diffie-Hellman

• Usando Diffie-Hellman autenticato,

• anche se Trudy riesce a violare sia Alice che Bob,

• non potrà comunque essere in grado di decifrare delle conversazioni registrate

• perché non è in grado di dedurre né SA né SB

Autent. a chiave pubblica unidirezionale

– In alcuni casi solo una delle parti ha una coppia chiave-pubblica, chiave-privata • spesso, come nel caso di SSL, si assume che i server abbiano

le chiavi pubbliche certificate, e i client non si preoccupano di ottenere chiavi e certificati

– pertanto, l’autenticazione crittografica è unidirezionale

– il protocollo assicura il client (Alice) che sta contattando il server Bob giusto,

– ma terminato la scambio di autenticazione, che permette tra l’altro di definire una chiave di sessione,

– il server non ha ancora autenticato il client

Autent. a chiave pubblica unidirezionale

– il client Alice si autentica dopo lo scambio di autenticazione

– inviando username e password, cifrati con la chiave di sessione Ks

– nelle slide successive sono illustrati due possibili, (a) e (b), modi per stabilire una chiave di sessione condivisa Ks

– durante lo scambio di autenticazione a chiave pubblica unidirezionale

(a) Ks = R – Alice invia {R}Bob

– Alice, sceglie un numero random R, lo cifra con la chiave pubblica di Bob ed invia {R}Bob

– tale schema presenta le debolezze viste nel caso (1)

• Trudy può registrare una intera conversazione e decifrarla se riesce in futuro a violare Bob

• Trudy può sostituire un suo {R}Bob e dirottare la conversazione seguente; tale debolezza è meno critica in un contesto dove non è necessaria una mutua autenticazione

I’m Alice, {RA}Bob, {R}Bob

RA Alic

e

Bo

b

Ks = R

(b) Usare Diffie-Hellman

– Bob e Alice possono effettuare uno scambio Diffie-Hellman

– dove Bob firma la sua quantità TB

• Alice non può firmare nulla non disponendo di una coppia PU, PR

– il caso (b) rispetto al caso (a) è un po’ più sicuro

– Trudy non può ottenere la chiave di sessione Ks usata in una precedente conversazione neanche violando Bob

• si assuma che Bob dimentichi Ks non appena la conversazione con Alice termina

I’m Alice, TA

[TB]Bob Alic

e

Bo

b

Ks = KAB = TBsA mod p = TA

sB mod p = KBA

genera sA

TA = gsA mod p genera sB

TB = gsB mod p

Bob non autentica Alice, ma …

• Si noti che nessuno degli schemi (a) e (b) assicura a Bob di comunicare con la vera Alice

• ma in entrambi i casi Bob è sicuro che l’intera conversazione è con una singola persona

Confidenzialità e Integrità(Autenticità)

– Tipicamente, la conversazione che segue lo scambio di autenticazione viene cifrata con la chiave di sessione per proteggere la confidenzialità

– inoltre viene applicato un controllo di integrità ai vari messaggi trasmessi (MIC o MAC) • ottenuto con tecniche crittografiche a chiave segreta oppure

sfruttando degli algoritmi di digest

– si è visto che non esiste un algoritmo standard per proteggere contemporaneamente confidenzialità e integrità

– disponendo di una sola chiave (la chiave di sessione Ks)

– ed effettuando una singola operazione crittografica


• pertanto si applicano alcune delle seguenti soluzioni che proteggono confidenzialità ed integrità in due fasi

– i) stabilire due chiavi di sessione nello scambio di autenticazione Ksc e Ksi

• Ksc: chiave di sessione per la confidenzialità

• Ksi: chiave i sessione per l’integrità

– ii) derivare una chiave dall’altra, cambiando alcuni bit in modo deterministico Ksi = f(Ksc)

– iii) una sola chiave Ks, ma algoritmi crittografici distinti

• ad esempio, confidenzialità tramite AES/CBC

• integrità tramite HMAC


– iv) includere un checksum debole per l’integrità all’interno di un algoritmo robusto per la protezione della confidenzialità

– una volta stabilità una (o più) chiave di sessione la conversazione, generalmente, consiste nello scambio di messaggi singolarmente cifrati e dei relativi MAC

– ogni volta che una parte riceve un messaggio lo decifra ed esegue il controllo di autenticità

– poi, eventualmente, può proseguire la conversazione

Attacchi all’integrità

– manca un controllo sull’ordine dei messaggi scambiati; sono possibili pertanto attacchi all’integrità di tipo “replay”

• un attaccante potrebbe registrare un messaggio (e il relativo MAC) e poi effettuarne il replay in un secondo momento; ciò non sarebbe rilevabile

– ovviamente, ciò può evitarsi includendo in ogni messaggio un numero di sequenza

• tale soluzione è adottata in entrambe le versioni di Kerberos


– in alternativa, si può far dipendere il MIC (MAC) di un messaggio m, oltre che da m stesso, anche da tutti i precedenti messaggi scambiati • se mi = mj ciò non implica che MAC(mi) = MAC(mj)

– un’altra forma di attacco all’integrità e la reflection • un attaccante registra un messaggio avente una data

direzione (da Bob a Alice) ed

• effettua il replay nell’altro senso (da Alice a Bob)

• se lo stesso numero di sequenza è valido in entrambe le direzioni

• tale attacco all’integrità non viene rilevato


– l’attacco all’integrità di tipo reflection può evitarsi

• usando, per ciascuna direzione, dei range diversi per i numeri di sequenza

• oppure inserendo un flag che definisce la direzione

• o differenziando in modo minimo l’algoritmo per il calcolo dl MAC per le due direzioni

Numeri di sequenza e Key Rollover

– Una conversazione potrebbe esaurire tutti i numeri di sequenza; a meno che quest’ultimi possano assumere valori enormi

– Si noti che, il riuso di precedenti numeri di sequenza, espone (almeno teoricamente) ad attacchi all’integrità di tipo reply

– Una possibile soluzione è il key rollover, cioè la rinegoziazione della chiave di sessione • ciò ha anche il vantaggio di limitare il materiale che un

crittoanalista potrebbe raccogliere

Key Rollover

– Il modo più semplice per rinegoziare la chiave è il seguente • una della due parti sceglie una chiave random Ks’

• la cifra con la vecchia chiave Ks

• e invia all’altra parte Ks{Ks’}

– tale soluzione è un po’ debole; se un crittoanalista fosse riuscito ad ottenere Ks otterrebbe anche Ks’ • il vantaggio di cambiare chiave si attenua

– conviene pertanto o ripetere lo scambio di autenticazione

– oppure utilizzare Diffie-Hellman

– il rollover della chiave permette, tra l’altro, di scegliere la vecchia chiave per l’integrità e la nuova per la confidenzialità

AUTENTICAZIONE MEDIATA (CON KDC)


KDC – alcuni richiami

– Si è già visto che un KDC ha un database con le chiavi di tutti gli utenti a lui afferenti

– ogni utente Alice registrato presso il KDC può comunicare in modo sicuro con il KDC • Alice e il KDC possono autenticarsi reciprocamente e

• proteggere la confidenzialità di ogni loro conversazione

• poiché entrambi conoscono la chiave segreta di Alice KAlice

– il KDC entra in gioco quando un utente Alice, desidera ottenere una chiave segreta KAB da condividere con un altro utente Bob del KDC

– non potendo Alice e Bob comunicare direttamente il KDC funge da mediatore

Mediazione del KDC – idea base

– Lo scambio riportato sotto illustra in modo esemplificato il ruolo di mediazione del KDC • il KDC non sa se è realmente Alice l’utente che ha chiesto di

comunicare con Bob

• Trudy potrebbe spacciarsi per Alice, ma poi non riuscirebbe ad ottenere KAB; non è in grado di decifrare il messaggio KAlice{use KAB for Bob}

Alice wants Bob

KAlice{use KAB for Bob} Alic

e

Bo

b

KBob{use KAB for Alice} KD

C

invents key KAB

Operazioni svolte dal KDC (in linea di principio)

Mediazione del KDC – in pratica

• Trudy al massimo può indurre il KDC ad inviare ad Alice un messaggio da lei non richiesto

– le uniche parti che conoscono KAB dopo questo scambio sono Alice, Bob e il KDC

– pertanto, dopo lo scambio Alice e Bob possono autenticarsi reciprocamente utilizzando il segreto condiviso KAB

– il protocollo precedente però non è quello utilizzato nella pratica • se Alice invia immediatamente un messaggio a Bob

• per i ritardi nella rete, è possibile che questi arrivi prima del messaggio che il KDC ha inviato a Bob


• inoltre, il fatto che un utente qualsiasi, senza autenticarsi presso il KDC, possa indurre quest’ultimo ad aprire connessioni verso un suo qualsiasi utente comporta una serie di pericoli che dovrebbero essere gestiti

– siccome è Alice che desidera comunicare con Bob

– la cosa più ragionevole, è che il KDC fornisca ad Alice tutte le informazioni che egli avrebbe fornito a Bob per instaurare una connessione sicura con Alice

– nel protocollo Kerberos, l’informazione cifrata che il KDC invia ad Alice da passare a Bob è chiamata ticket

• il cosiddetto ticket per Bob

Prot. 12 Mediazione del KDC – in pratica

– nella pratica la mediazione del KDC avviene in modo simile a come illustrato sotto

– naturalmente, Alice e Bob devono poi autenticarsi reciprocamente con una delle tecniche esaminate prima • ciascuno deve dimostrare all’altro di conoscere realmente KAB

KAlice{use KAB for Bob} ticket to Bob = KBob{use KAB for Alice}

Alice wants Bob

Alic

e

Bo

b K

DC

invents key KAB

“I’m Alice”, ticket to Bob = KBob{use KAB for Alice}

Operazioni svolte dal KDC (nella pratica)


– rimangono comunque delle vulnerabilità molto sottili

– che hanno giustificato l’introduzione di molti protocolli

– alcuni dei quali si esamineremo nel seguito

– come il protocollo di Needham-Schroeder

Protocollo di Needham-Schroeder (N-S)

– Tale protocollo ha la stessa struttura portante di quello esaminato prima, ma in aggiunta

• aggiunge uno scambio per autenticare reciprocamente Alice e Bob e

• rimuove alcune sottili debolezze che ora saranno illustrate

– Il protocollo di Needham-Schroeder [NEED78] è importante perché è un classico protocollo di autenticazione mediata da un KDC e

– a lui si sono ispirati molti protocolli moderni, incluso Kerberos

– per una sua comprensione, al solito, è necessario analizzarlo in modo “viscerale”

Protocollo N-S – terminologia

– Il termine nonce sta per “number that is used only once” cioè numero che è usato soltanto una volta

– Un nounce potrebbe essere

• un numero di sequenza (ammesso che non vi sia perdita di stato durante i crash)

• un numero random molto grande (la probabilità di una ripetizione è prossima a zero)

– in teoria potrebbe essere anche un timestamp

• se gli orologi degli apparati hardware non vanno mai indietro

• si noti tuttavia che Needham e Schroeder vollero evitare in modo esplicito ogni tipo di dipendenza da timestamp

Prot. 12 Prot. N-S – 1^a vuln.

– Il Prot. 12 presenta la seguente vulnerabilità • anche se in pratica è improbabile che possa essere sfruttata da un

attaccante

– si supponga che Trudy abbia rubato una vecchia chiave di Bob K’Bob

• Bob scoprendolo potrebbe già aver provveduto a cambiarla

– e che abbia anche rubato un vecchio messaggio di risposta del KDC ad Alice • quando la chiave di Bob era ancora K’Bob

– Trudy attende che Alice richieda al KDC di parlare con Bob

– poi sostituisce la risposta del KDC con quella vecchia in suo possesso, che appare ad Alice come una risposta ordinaria


– Trudy può pertanto impersonare Bob

• riesce a decifrare il ticket e ad ottenere la chiave di sessione

– questa vulnerabilità, prevalentemente teorica, può essere rimossa non permettendo a Trudy di riusare (reply) vecchie risposte del KDC

– ad esempio aggiungendo un nounce N1 alla richiesta iniziale di Alice

– e chiedendo al KDC di cifrarlo insieme alla chiave KAB


– segue sotto il Prot. 12.1 ottenuto rimuovendo la vulnerabilità appena illustrata

KAlice{N1, KAB} ticket to Bob = KBob{KAB}

N1, Alice wants Bob

Alic

e

Bo

b K

DC

invents key KAB

“I’m Alice”, ticket to Bob

Protocollo 12.1


– Nel Prot. 12.1 sussiste ancora la seguente vulnerabilità

– si supponga che Trudy, utente del KDC, riesca a modificare la richiesta di Alice, sostituendo “Bob” con “Trudy”

– il KDC restituirebbe ad Alice una chiave condivisa con Trudy e non con Bob; cioè KAT e non KAB

– tuttavia, dalle informazioni ricevute Alice non può rendersi conto di tale attacco; cioè Alice è convinta di aver ricevuto KAB

– quindi Trudy potrebbe impersonare Bob senza che Alice se ne accorga


– il precedente attacco è sventabile aggiungendo alle informazioni che il KDC deve inviare ad Alice (cifrate con KAlice)

– il destinatario della richiesta di connessione che ha ricevuto il KDC

• in tal modo Alice può verificare se coincide con quello presente nella sua richiesta

– inoltre il KDC può aggiungere il nome dell’utente che ha effettuato la richiesta tra le informazioni che costituiscono il ticket per Bob

• il motivo di tale scelta sarà chiaro più tardi


– implementando le precedenti modifiche si ottiene il Prot. 12.2

KAlice{N1, “Bob”, KAB} ticket to Bob = KBob{KAB, “Alice”}

N1, Alice wants Bob

Alic

e

Bo

b K

DC

invents key KAB

“I’m Alice”, ticket to Bob

Protocollo 12.2


– Il Prot. 12.2 analogamente ai precedenti non include uno scambio che permetta di autenticare reciprocamente Alice e Bob

– per l’autenticazione reciproca ciascuno deve provare all’altro di conoscere KAB

• Alice sa che soltanto chi conosce KBob può decifrare il ticket per Bob e quindi riottenere KAB

• Bob decifrando il ticket, oltre a KAB, ottiene “Alice” e sa pertanto che il KDC è stato contattato da Alice e che solo lei, Alice e il KDC conoscono KAB

• (ciò spiega una delle modifiche inserite nel protocollo 12.2)


– Alice e Bob possono autenticarsi reciprocamente nel seguente modo

• Alice, insieme al ticket invia a Bob una sfida (N2) cifrata con la chiave KAB

• Bob decifra il ticket e ottiene KAB, quindi usa KAB per estrarre N2

• poi invia ad Alice KAB{N2 – 1, N3}, N2 – 1 serve a provare ad Alice che conosce KAB

• N3 è invece la sfida per Alice

• infine, Alice dimostra a Bob di conoscere KAB rispondendo alla sua sfida con KAB{N3}


– Il Prot. 12.3 include anche lo scambio per autenticare reciprocamente Alice e Bob

KAlice{N1, “Bob”, KAB} ticket to Bob = KBob{KAB, “Alice”}

N1, Alice wants Bob

Alic

e

Bo

b

KD

C

invents key KAB

“I’m Alice” ticket to Bob, KAB{N2}

Protocollo 12.3

KAB{N2 – 1, N3}

KAB{N3 – 1}

Protocollo di Needham-Schroeder

– Il protocollo di Needham-Schroeder in pratica concide con il Prot. 12.3

• tranne per il fatto che il KDC include il ticket per Bob tra le informazioni da cifrare con KAlice

• si osservi che ciò non migliora la sicurezza in quanto il ticket per Bob è qualcosa di indecifrabile per Alice

• tale ulteriore cifratura poteva pertanto omettersi

Protocollo di Needham-Schroeder

KAlice{N1, “Bob”, KAB, ticket to Bob} where ticket to Bob = KBob{KAB, “Alice”}

N1, Alice wants Bob

Alic

e

Bo

b

KD

C

invents key KAB

ticket, KAB{N2}

Needham-Schroeder

KAB{N2 – 1, N3}

KAB{N3 – 1}

m1

m3

m4

m5

m2

Bibliografia



• [NEED78] R. M. Needham, M. D. Schroeder. Using Encryption for Authentication in Large Networks of Computers. Communications of the ACM, Vol. 21, December 1978, pp. 993-999.






Standard di Autenticazione Kerberos V4

Luca Grilli

Introduzione

– Kerberos è un servizio, a chiave segreta, per autenticare utenti e risorse (principal) in una rete insicura

– Basato sul lavoro di Needham e Schroeder, fu progettato originariamente al MIT

– Serve a semplificare l’autenticazione di un utente di una workstation per accedere a risorse remote (protette) di cui possiede i diritti di accesso

– Le prime tre versioni di Kerberos non sono più usate

– Le versioni V4 e V5, sebbene concettualmente simili, sono sostanzialmente diverse e si stanno contendendo il mercato

Introduzione

– La versione V4 è più diffusa, più semplice, e offre migliori prestazioni, ma funziona solo su reti TCP/IP

– mentre la versione V5 offre maggiori funzionalità ed è meno restrittiva

– Si esaminerà soltanto la versione V4 nelle prossime slides

– Curiosità: il nome Kerberos (Cerbero) deriva dalla mitologia greca, Cerbero era il cane a tre teste posto a guardia dell’ingresso dell’Ade (inferi)

Scenario di impiego tipico

– Si supponga che un utente Alice effettui il login presso una workstation inserendo username e password

• o presso un sistema operativo di un computer multiutente

– durante la sessione di login

• cioè nel periodo di tempo che intercorre dal login al logout

– Alice potrebbe avere la necessità di accedere, previa autenticazione, a risorse remote di cui possiede i diritti di accesso

• host remoti su cui Alice ha un account,

• oppure file su server remoti di cui possiede i diretti di accesso e/o modifica


WorkStation usr

pwd server2

server1

serverN

rete insicura


– se l’autenticazione coinvolgesse direttamente Alice

– dovrebbe, molto probabilmente, basarsi sull’inserimento delle credenziali di accesso, con ovvi svantaggi

• l’autenticazione basata su password è meno sicura di un’autenticazione a sfida e risposta a chiave segreta

• Alice sarebbe chiamata ad inserire molto spesso le proprie credenziali, oppure queste dovrebbero essere memorizzate in qualche punto

– Kerberos fornisce una soluzione sicura a tale problema semplificando la vita ad Alice

Kerberos – Idea Base

– con Kerberos la workstation (sistema operativo) di Alice è in grado di effettuare l’autenticazione al suo posto

– senza che Alice si renda conto che è in atto un processo di autenticazione

– in altri termini, l’autenticazione è completamente trasparente all’utente

– Kerberos è stato pensato per reti insicure (come Internet) • ove sono possibili sia attacchi alla confidenzialità,

• che attacchi all’integrità

Implementazione di Kerberos

– Un’implementazione di Kerberos consiste in

– un Key Distribution Center (KDC) che viene eseguito in qualche parte della rete su un nodo fisicamente sicuro,

– e una libreria di subroutine usate dalle applicazioni distribuite che desiderano autenticare i propri utenti

– Tra le applicazioni che sono state modificate per incorporare delle chiamate a subroutine nella libreria di Kerberos troviamo

• telnet: serve ad interagire su un sistema remoto tramite riga di comando


• BSD rtools: gruppo di programmi di utilità inclusi in BSD Unix che supportano il login remoto (rlogin), la copia di file remoti (rcp) e l’esecuzione remota di comandi (rsh)

• NFS (Network File System): programma di utilità che permette di accedere a file di un host remoto come se fossero locali

– Sebbene sono previste diverse modalità operative

– Kerberos fu progettato per un ambiente in cui un utente effettua il login in una workstation inserendo user-name e password


– user-name e password sono usate dalla workstation per ottenere dal KDC

– le informazioni necessarie ai processi locali per autenticarsi e per accedere alle risorse remote al posto dell’utente

• evitando che l’utente inserisca ogni volta le sue credenziali


WorkStation usr

pwd server2

server1

serverN

KDC

rete insicura

librerie di subroutine di Kerberos

DA NEEDHAM-SCHROEDER A KERBEROS

Standard di Autenticazione – Kerberos V4

N-S Kerberos – (0)

– si supponga che l’utente Alice, dopo aver effettuato il login presso la workstation, desideri effettuare un login remoto, comando rlogin, presso il server Bob

– ovviamente Alice dispone già di un account utente presso Bob

– nelle prossime slide si illustrerà l’interazione “logica” tra Alice e il KDC (in pratica Needham-Schroeder)

• Alice e il KDC non interagiscono direttamente, ma c’è l’intermediazione della workstation che inizialmente sarà trascurata

• ciò sarà comunque evidenziato nello schema utilizzando delle frecce tratteggiate


– Il KDC condivide una chiave segreta, detta chiave master, con ciascun principal (cioè ciascun utente e/o risorsa coinvolte nel processo di autenticazione)

• KA e KB indicheranno le chiavi master di Alice e Bob

– Alice informa il KDC che desidera contattare Bob

– il KDC inventa una chiave di sessione KAB per Alice (per la sua workstation) e Bob

– poi cifra KAB e il nome “Bob” con la chiave master di Alice KA

– e cifra KAB e il nome “Alice” con a chiave master di Bob KB ottenendo il ticket per Bob


– restituisce poi tutte queste informazioni ad Alice

– Alice non può leggere cosa c’è nel ticket di Bob • perché è cifrato con la chiave master di Bob

– solo Bob (e il KDC) può decifrare il suo ticket ed ottenere KAB e il nome “Alice”

– ciò rassicura Bob che chiunque conosce KAB agisce per conto di Alice

– pertanto, usando KAB, Alice e Bob possono autenticarsi reciprocamente

– ed eventualmente proteggere la confidenzialità e l’integrità della loro conversazione


– la chiave di sessione KAB insieme al ticket per Bob costituiscono le credenziali di Alice presso Bob

KA{KAB, “Bob”}

ticket to Bob = KB{KAB, “Alice”}

Alice wants Bob

Alic

e

Bo

b

KD

C

invents key KAB

“I’m Alice”, ticket = KB {KAB, “Alice”}

mutua autenticazione a chiave segreta KAB

conversazione cifrata e con controllo d’integrità


– ora si introdurrà, in modo graduale, l’intermediazione della workstation di Alice

– per prima cosa, Alice non dovrà ricordarsi la propria chiave master KA,

– una possibilità è che la chiave master di Alice si ottenga dal usr e pwd: KA = f(usr, pwd)

– e che la workstation calcoli KA quando Alice effettua il login

N-S Kerberos – (1.a) A

lice

Bo

b

KD

C login

usr pwd

Alic

e’s

wo

rkst

atio

n

la workstation calcola la chiave master di Alice KA = f(usr, pwd)

Fase di login

N-S Kerberos – (1.b)

KA{KAB, “Bob”} ticket to Bob = KB{KAB, “Alice”}

Alice wants Bob

Alic

e

Bo

b

KD

C




rlogin Bob

Alic

e’s

wo

rkst

atio

n

any commands

Esecuzione di un comando remoto

i) invents key KAB

ii) finds Bob’s master key KB

Schema (1) – vulnerabilità

– la workstation, che effettua l’autenticazione al posto di Alice, dovrebbe ricordare la sua password durante l’intera sessione di login

• oppure dovrebbe ricordare la sua chiave master KA

– ed usarla quando Alice effettua delle operazioni che richiedono la verifica della sua identità

– tale soluzione non può considerarsi sicura

• Alice potrebbe, durante la sessione di login, eseguire del software non fidato che potrebbe rubare la sua password

– va limitato il più possibile il tempo di memorizzazione della password e della chiave master di Alice

Schema (1) – riduzione vulnerabilità

• per ridurre la precedente vulnerabilità conviene procedere nel seguente modo

– l’idea è quella di sostituire il ruolo della chiave master KA con quello di una chiave di sessione di utente SA

• SA varia da sessione a sessione

– pwd, usr e quindi KA vengono usati solo temporaneamente all’inizio di ogni sessione di login per ottenere SA

– la chiave di sessione SA viene generata dal KDC

– una volta ottenuta SA la workstation dimentica la pwd di Alice e ricorda soltanto SA

Schema (1) – riduzione vulnerabilità

• in altri termini, per ridurre la vulnerabilità, la prima cosa che effettua la workstation è

– richiedere al KDC una chiave di sessione SA per l’utente Alice

• SA sarà valida soltanto per la sessione di login corrente; in generale, SA sarà valida per un tempo molto ridotto, tipicamente poche ore

• e sarà usata dalla workstation, che agirà al posto di Alice, per verificare la sua identità

• se qualcuno dovesse rubare SA, a differenza di prima, questi può impersonare Alice, ma solo per poco tempo; fino alla scadenza di SA


lice

Bo

b

KD

C login

usr pwd

Alic

e’s

wo

rkst

atio

n

la workstation ottiene la chiave di sessione SA per l’utente Alice

dopodiché dimentica pwd e KA

Alice needs a user session key

a) invents key SA

b) finds Alice’s master key KA

Fase di login

KA{SA}


SA{KAB, “Bob”} ticket to Bob = KB{KAB, “Alice”}

Alice wants Bob

Alic

e

Bo

b

KD

C




rlogin Bob

Alic

e’s

wo

rkst

atio

n

any commands


i) invents key KAB

ii) finds SA

iii) finds KB

Schema (2) – svantaggio

– così come illustrato, il precedente protocollo richiede al KDC di memorizzare, oltre alla chiave master di ogni utente

– anche la chiave di sessione; nel caso di Alice, il KDC deve memorizzare sia KA che SA

– ciò è evitabile utilizzando il cosiddetto

– Ticket-Granting Ticket (TGT) che il KDC invia ad Alice e consiste • nella chiave di sessione SA

• più altre informazioni come il nome di Alice e la scadenza del TGT stesso

– il tutto cifrato con la chiave master KKDC del KDC

Ticket-Granting Ticket (TGT)

• Un Ticket-Granting Ticket, per il KDC, da inviare ad un utente U viene generato dal KDC e consiste

– nella chiave di sessione SU,

– più il nome dell’utente “UserName”

– ed altre informazioni accessorie cifrate con la chiave master del KDC

• come ad esempio l’expiration time del TGT

TGT = KKDC{SU, “UserName”, “ExpirationTime”, …}

Uso del TGT

– Durante il login iniziale, la workstation, che agisce al posto di Alice, richiede al KDC una chiave di sessione

– il KDC genera una chiave di sessione SA e la trasmette, alla workstation, cifrata con la chiave master di Alice KA

– il KDC trasmette anche un TGT

– la workstation usa la chiave master di Alice KA per decifrare SA

– dimentica poi la pwd di Alice e ricorda solo SA e il TGT

Uso del TGT

– quando Alice deve accedere ad una risorsa remota

– la sua workstation trasmette il TGT al KDC

– insieme al nome della risorsa (server) per la quale Alice ha bisogno di un ticket (diciamo Bob)

– il KDC decifra il TGT ed ottiene SA

– e usa SA per cifrare la chiave di sessione condivisa per Alice e Bob KAB

– in sintesi, il TGT informa il KDC di usare SA invece della chiave master di Alice KA


lice

Bo

b

KD

C login

usr pwd

Alic

e’s

wo

rkst

atio

n

la workstation ottiene la chiave di sessione SA per l’utente Alice

dopodiché dimentica pwd e KA

e ricorda solo SA e TGT

Alice needs a user session key and a TGT

a) invents key SA

b) finds KA

c) TGT = KKDC{SA, “Alice”}

Fase di login

KA{SA}, TGT


SA{KAB, “Bob”} ticket to Bob = KB{KAB, “Alice”}

Alice wants Bob, TGT

Alic

e

Bo

b

KD

C




rlogin Bob

Alic

e’s

wo

rkst

atio

n

any commands


i) invents key KAB

ii) finds SA from TGT

iii) finds KB

Alcune note

– Nelle prime versioni di Kerberos non esisteva la nozione di TGT

• la comunicazione con il KDC utilizzava sempre la chiave master dell’utente

• più tardi, per aumentare la sicurezza, fu introdotta la chiave di sessione di utente generata in fase di login

– l’idea era che soltanto i TGT fossero generati dal KDC

– mentre gli altri ticket dovevano essere ottenuti da un’altra entità, che Kerberos chiama

Ticket-Granting Server (TGS)

Alcune note

– tuttavia, il Ticket-Granting Server deve avere lo stesso database del KDC

• deve conoscere la chiave master di Bob KB per poter dare ad Alice un ticket per Bob

– pertanto, nella pratica il TGS e il KDC di Kerberos sono la stessa cosa!

• sarebbe più facile comprendere Kerberos se la documentazione non facesse riferimento a due entità distinte (il TGS e il KDC)

• e a due set di messaggi distinti, uno per protocollo, che in pratica fanno la stessa cosa

Alcune note

– in particolare, la documentazione di Kerberos fa riferimento a

– un Server di Autenticazione (Authentication Server AS) e a

– un Ticket-Granting Server (TGS)

– che sono collocati nel KDC, intendendo che in pratica sono la stessa cosa • la distinzione AS e TGS è stata mantenuta per non

stravolgere la documentazione rispetto alle prime versioni

– pertanto, nel seguito si useranno i termini KDC, AS e TGS in modo intercambiabile

PROTOCOLLO KERBEROS V4 Standard di Autenticazione – Kerberos V4

Configurazione

– Ciascun principal ha una sua chiave segreta, detta chiave master

– Il server Kerberos è chiamato KDC (Key Distribution Center) • a volte è chiamato Authentication Server o KDC/AS

– Il KDC ha un database con i nomi di tutti i principal, a lui afferenti, e le relative chiavi master

– Per ragioni di sicurezza, le chiavi master dei principal non vengono memorizzate in chiaro

– ma vengono memorizzate cifrate con una chiave segreta KKDC nota solo al KDC; KKDC è detta la chiave master del KDC

Configurazione

– La chiave master di un utente umano è derivata dalla sua password

– le altre risorse associate agli utenti umani sono configurate utilizzando la loro chiave master

– Kerberos si basa sulla tecnologia a chiave segreta

• generalmente si usa DES quale algoritmo di cifratura

• la versione V5 permette di impostare l’algoritmo di cifratura, per lo meno a livello protocollare

• ma nella pratica si usa sempre DES

In sintesi

– Gli utenti umani devono memorizzare una password; i dispositivi di rete devono memorizzare una chiave segreta

– Il KDC ha un database con i nomi dei principal, a lui afferenti, e le relative chiavi master

– Il KDC deve anche ricordare una chiave segreta KKDC per se stesso

• al fine di cifrare/decifrare il database con le chiavi degli utenti, e

• per generare i Ticket-Granting Tickets

Fasi di Kerberos

• Nel seguito si esamineranno le due fasi di Kerberos:

1. Login: Alice effettua il login presso la sua workstation, ottenendo una chiave di sessione e un TGT

2. Esecuzione di un comando remoto: Alice esegue un comando su un server remoto per il quale è prevista una fase preliminare di autenticazione

– la workstation di Alice effettuerà l’autenticazione al suo posto

KRB V4 – Login/acquisizione di un TGT

• Messaggio m1

– Alice trasmette il proprio nome utente e password alla workstation

• Messaggio m2 [AS_REQ]

– La workstation invia un messaggio al KDC, in chiaro, contenente il nome utente di Alice

• Messaggio m3 [AS_REP]

– una volta ricevuto m2, il KDC restituisce alla workstation, le credenziali per il KDC, cifrate con la chiave master di Alice KA

Kerberos V4 – Acquisizione di un TGT A

lice

Wo

rkst

atio

n K

DC

i) invents key SA

ii) finds Alice’s master key KA

iii) TGT = KKDC{“Alice”, SA}

Login/acquisizione di un TGT

Alice, password [AS_REQ] Alice needs a TGT

[AS_REP] KA{SA, TGT}

m1

m2

m3

KRB V4 – Credenziali per il KDC

• Le credenziali di Alice per il KDC consistono in

– una chiave di sessione di utente SA

• una chiave segreta da usare durante la sessione di login

– un Ticket-Granting Ticket (TGT), costituito da

• la chiave di sessione SA

• il nome utente e

• la data di scadenza

il tutto cifrato con la chiave master del KDC KKDC

• pertanto il TGT è una stringa di bit non intelligibile per chiunque tranne che per il KDC


– le credenziali di Alice per il KDC, sono inviate indietro, dal KDC ad Alice, cifrate con la chiave master KA

• le informazioni nel TGT sono pertanto cifrate due volte; prima con KKDC e poi con KA

• Kerberos V4 è stato spesso criticato per questa scelta che comporta uno sforzo computazionale doppio non giustificato da un reale beneficio in termini di sicurezza

– la workstation converte la password digitata da Alice nella corrispondente chiave DES KA

– e una volta ricevute le credenziali, tenta di decifrarle con KA


– se tale decifratura viene eseguita con successo

• cioè se Alice ha digitato correttamente la password

– la workstation, scarta la chiave master di Alice KA (la chiave derivata dalla password) e

– memorizza invece il TGT e la chiave di sessione SA

Alcuni dettagli

– In realtà, Kerberos V4 richiede all’utente di inserire la propria password solo dopo che la workstation ha ricevuto le credenziali dal KDC

• la workstation mantiene l’utente in attesa e gli permette di inserire la password solo dopo aver ricevuto la risposta dal KDC

– l’obiettivo è ridurre il più possibile il tempo di permanenza della password d’utente nella workstation

• si tratta di una buona regola generale di sicurezza

• tuttavia, nella pratica non si ha un vantaggio significativo in quanto i tempi in gioco sono dell’ordine dei secondi

Alcuni dettagli

– Invece, in Kerberos V5, l’utente inserisce la password prima che il KDC fornisca le credenziali alla workstation

– in particolare, in V5, la workstation deve prima provare di conoscere la password d’utente dopodiché può richiedere le credenziali per il KDC

– in questo modo è meno facile sferrare un attacco off-line sulla password

– nella versione V4, chiunque, sostenendo di essere Alice, ottiene KA{SA, TGT} senza dover intercettare alcun messaggio

• KA è la chiave master di Alice, ottenuta dalla sua password

KRB V4 – Documentazione ufficiale

– la documentazione ufficiale di Kerberos nomina i messaggi nel seguente modo

– KRB_AS_REQ: Kerberos Authentication Server Request

• corrisponde al messaggio m2, per brevità nello schema si è usato AS_REQ

– KRB_AS_REP: Kerberos Authentication Service Reply

• corrisponde al messaggio m3, per brevità nello schema si è usato AS_REP

Scopo del TGT

• Qual è lo scopo del TGT?

• Risposta – Quando Alice deve accedere a una risorsa remota, la

sua workstation invia il TGT al KDC insieme a una richiesta di un ticket per il nodo di tale risorsa

– il TGT contiene le informazioni di cui ha bisogno il KDC relative alla sessione di login di Alice • la chiave di sessione SA, il nome utente di Alice, la data di

scadenza, …

– tali informazioni permettono al KDC di operare senza la necessità di mantenerle in memoria

Scopo del TGT

– il KDC ha una base di dati prevalentemente statica,

– e per ogni richiesta invia una risposta e

– dimentica ciò che è accaduto

– ciò offre diversi vantaggi pratici, come semplificare la replicazione dei KDC e il

– non dover preoccuparsi di mantenere lo stato quando si verificano dei crash di sistema

KRB V4 – Esecuzione comando remoto

– Nelle prossime slide si esaminerà l’esecuzione di un comando remoto (rlogin), presso un server Bob

– per il quale è prevista un’autenticazione preliminare di Alice, che sarà eseguita dalla sua workstation

– è comodo distinguere due sottofasi

• la workstation acquisisce dal KDC un ticket per Bob

• la workstation (che agisce al posto di Alice) e Bob si autenticano reciprocamente

KRB V4 – Acquisizione di un ticket

– Si supponga che dopo il login, Alice digiti un comando che richiede l’accesso ad un nodo remoto (messaggio m4) • ad esempio “rlogin Bob” che permette ad Alice di effettuare

il login su Bob

– la workstation invia al KDC (messaggio m5) il TGT, il nome “Bob” e un authenticator

– il cui scopo è provare che la workstation conosce la chiave di sessione SA

• l’authenticator consiste nel timestamp cifrato con SA

– tale richiesta (m5) nella documentazione di Kerberos è chiamata KRB_TGS_REQ


– mentre la corrispondente risposta (m6) è chiamata KRB_TGS_REP

• per brevità, nello schema si sono usati TGS_REQ e TGS_REP, rispettivamente

– TGS_REP contiene il ticket per Bob e KAB (la chiave di sessione che Alice e Bob condivideranno) cifrate con SA (la chiave di sessione che Alice condivide con il KDC)

KRB V4 – Acquisizione di un ticket A

lice

Wo

rkst

atio

n K

DC

a) invents key KAB

b) decrypts TGT to get SA

c) decrypts authenticator d) verifies timestamp e) finds Bob’s master key KB

f) ticket to Bob = KB{“Alice”, KAB}

Alice ottiene un ticket per Bob

rlogin, Bob

[TGS_REQ] Alice wants to talk to Bob

TGT = KKDC{“Alice”, SA} authenticator = SA{timestamp}

[TGS_REP] SA{“Bob”, KAB, ticket to Bob}

m4

m5

m6


– il KDC decifra il TGT (con KKDC) ed ottiene la chiave di sessione SA; controlla anche la data di scadenza del TGT

– se il TGT è valido, genera una nuova chiave KAB

• la chiave segreta condivisa tra Alice e Bob

– e costruisce un ticket per Bob composto da • la nuova chiave KAB, il nome “Alice” (l’utente da cui ha

ricevuto la richiesta) e l’expiration time del ticket stesso

• il tutto cifrato con la chiave master di Bob, KB

– il KDC invia il ticket insieme al nome “Bob” e KAB, alla workstation, cifrando tali informazioni con SA (messaggio m6)

– una volta ricevute, la workstation le decifrerà con SA

Sull’uso dell’authenticator

– Necessità di sincronizzare gli orologi

• l’uso dell’authenticator comporta che gli orologi delle risorse di rete debbano essere ragionevolmente ben sincronizzati

• devono essere tollerati dei ritardi tra i vari orologi

• la forbice permessa viene impostata in modo indipendente su ogni server

• pertanto, alcuni server possono essere configurati in modo tale da tollerare ritardi maggiori

• tipicamente, si tollera una forbice di cinque minuti, si assume che si è in grado di garantire un tale disallineamento senza dover sostenere degli sforzi amministrativi considerevoli


• ma nella pratica tale assunzione si è rivelata più problematica del previsto

• per tale ragione, conviene usufruire di servizi per la sincronizzazione oraria, che permettono di risolvere in problema in modo efficace

– si osservi inoltre che l’uso dell’authenticator è evitabile; non aumenta il livello di sicurezza

• se qualcuno che non conosce SA trasmettesse il TGT e il nome Bob al KDC, non sarebbe comunque in grado di decifrare la risposta del KDC che è cifrata con SA


– i progettisti di Kerberos inclusero l’authenticator per ragioni di uniformità

• cioè per rendere il protocollo che regola la comunicazione con il TGS analogo ai protocolli che regolano la comunicazione con altre risorse

• i quali richiedono invece la presenza di un autheticator per sventare attacchi di tipo replay di vecchie richieste

KRB V4 – Mutua autenticazione Alice/Bob

– una volta che la workstation è in possesso di un ticket per Bob, può inviare una richiesta a Bob

– nella documentazione ufficiale di Kerberos tale richiesta è chiamata KRB_AP_REQ

• KeRBeros APplication REQuest

• per semplicità si userà AP_REQ (messaggio m7)

– AP_REQ è costituita da

• il ticket per Bob

• un authenticator, ovvero un timestamp cifrato con la chiave KAB


Alic

e’s

Wo

rkst

atio

n

Bo

b

[AP_REQ] ticket to Bob = KB{“Alice”, KAB}

authenticator = KAB{timestamp} K

DC

m7

[AP_REP] KAB{timestamp + 1}

m8

Alic

e

Login su Bob dalla workstation di Alice


– la risposta di Bob è nota come KRB_AP_REP, in breve AP_REP (messaggio m8)

– Bob decifra il ticket ed ottiene KAB e il nome “Alice”

• assume pertanto che l’entità (workstation) che conosce KAB stia agendo al posto di Alice

– poi Bob decifra l’authenticator per assicurarsi che l’entità con cui sta dialogando conosca realmente KAB

• verifica se il timestamp ottenuto è prossimo all’orario corrente (cinque minuti di tolleranza)

• in questo modo può sventare eventuali attacchi di tipo replay di vecchie richieste (più vecchie di cinque minuti)

Sul controllo del timestamp

– per assicurarsi che non sia in corso un attacco di tipo replay che sfrutta richieste molto recenti

– Bob dovrebbe mantenere i memoria tutti i timestamps ricevuti negli ultimi cinque minuti

– e verificare, non appena riceve un nuovo timestamp, che sia diverso da tutti quelli in memoria e che sia prossimo all’ora corrente • ogni authenticator più vecchio di cinque minuti viene

scartato a priori

– tuttavia, Kerberos V4 non si preoccupa di salvare i timestamp

Sul controllo del timestamp

– salvare i timestamp non sarebbe comunque d’aiuto se Bob fosse un servizio replicato e ogni sua istanza usasse la stessa chiave master

– a meno che non viene incluso l’indirizzo di rete dell’istanza di Bob (d’interesse) nell’authenticator


– per completare la mutua autenticazione è necessario anche che la workstation di Alice autentichi Bob, a tale scopo

– Bob incrementa di un’unità il timestamp ottenuto decifrando l’authenticator

– cifra con KAB il valore ottenuto; cioè calcola KAB{timestamp + 1}

– e lo rispedisce indietro alla workstation

– la workstation di Alice è ora rassicurata sul fatto che sta dialogando con il vero Bob


– in quanto, il suo interlocutore (il presunto Bob) conosce KAB

– deve essere stato in grado di decifrare il ticket per Bob

– deve conoscere la chiave master di Bob KB

– si assume chiaramente che

• solo la workstation di Alice, il KDC e in seguito Bob conoscano KAB

• solo Bob e il KDC conoscano KB

Confidenzialità e Integrità

– Successivamente, dipendentemente dalla applicazione, i messaggi tra Alice e Bob possono essere

– non protetti (in chiaro) oppure

– può essere protetta

• solo l’integrità,

• solo la confidenzialità,

• sia l’integrità che la confidenzialità

Confidenzialità e Integrità

– la protezione della confidenzialità e/o della integrità può essere gestita in modo autonomo dalle applicazioni che usano Kerberos per l’autenticazione

– tuttavia, Kerberos mette anche a disposizione delle facility per proteggere integrità e/o confidenzialità

– a tale scopo utilizza DES nella modalità operativa PCBC (Plaintext Cipher Block Chaining)

• una variante di CBC che permette di rivelare eventuali modifiche ai blocchi cifrati

Bibliografia



• [NEED78] R. M. Needham, M. D. Schroeder. Using Encryption for Authentication in Large Networks of Computers. Communications of the ACM, Vol. 21, December 1978, pp. 993-999.






Alic

e

Wo

rkst

atio

n K

DC

i) invents key SA

ii) finds Alice’s master key KA

iii) TGT = KKDC{“Alice”, SA}

Acquisizione di un TGT

Alice, password [AS_REQ] Alice needs a TGT

[AS_REP] KA{SA, TGT}

m1

m2

m3

Alic

e

Wo

rkst

atio

n K

DC

a) invents key KAB

b) decrypts TGT to get SA

c) decrypts authenticator d) verifies timestamp e) finds Bob’s master key KB

f) ticket to Bob = KB{“Alice”, KAB}

Alice ottiene un ticket per Bob

rlogin, Bob

[TGS_REQ] Alice wants to talk to Bob

TGT = KKDC{“Alice”, SA} authenticator = SA{timestamp}

[TGS_REP] SA{“Bob”, KAB, ticket to Bob}

m4

m5

m6

Alic

e’s

Wo

rkst

atio

n

Bo

b

[AP_REQ] ticket to Bob = KB{“Alice”, KAB}

authenticator = KAB{timestamp} K

DC

m7

[AP_REP] KAB{timestamp + 1}

m8

Alic

e

Login su Bob dalla workstation di Alice

Sicurezza dei Sistemi Operativi

Luca Grilli

Fabrizio Montecchiani

Introduzione

• Un SO (Sistema Operativo), o OS (Operating System), gestisce il modo in cui le applicazioni software accedono alle risorse hardware del calcolatore: – CPU – memoria principale – memoria secondaria – periferiche di I/O – interfacce di rete

• Un OS fornisce un’interfaccia semplificata e consistente a utenti e applicazioni al fine di interagire con i componenti hardware – grazie a questa astrazione è possibile sviluppare programmi software

senza preoccuparsi della particolare tipologia di hardware sul quale saranno eseguiti

Introduzione

• User Applications Userland

• Non-essential OS Applications

• Kernel O.S.

• CPU

• Memory

• I/O Devices Hardware

Introduzione

• Gli OS svolgono numerose funzioni, alcune delle quali strettamente legate a problemi di sicurezza, in particolare vedremo:

– meccanismi di autenticazione

– sicurezza dei processi

– sicurezza del filesystem

– sicurezza della memoria

MECCANISMI DI AUTENTICAZIONE Sicurezza dei Sistemi Operativi

Il Problema dell’Autenticazione

• Un OS deve poter identificare i propri utenti in modo sicuro – utenti diversi potrebbero avere permessi di accesso

alle risorse diversi

• Un meccanismo di autenticazione standard

ampiamente usato consiste nell’inserimento di un username e di una password – se la password inserita coincide con la password

memorizzata dall’OS per il dato username allora l’utente viene autenticato

Memorizzare le Password

• Un OS deve dunque memorizzare la password di ogni utente che può accedere al sistema

• Generalmente gli OS memorizzano le password criptate attraverso funzioni hash in un file o in un apposito database – grazie alla proprietà one-way delle funzioni hash,

un attaccante che riesce ad accedere al file dove sono memorizzate le password non può ricostruire facilmente il loro valore

Windows e Linux

• Windows (32 bit):

– C:\WINDOWS\system32\config\SAM

• Linux:

– /etc/passwd

– /etc/shadow (solo l’utente root può leggerle)

Possibili Attacchi

• Brute Force: attacco offline, tutte le possibili password per un dato alfabeto vengono generate automaticamente, criptate con la funzione hash usata dal sistema di autenticazione e confrontate con le password memorizzate

• Dizionario: attacco offline, liste di parole comuni (es: nomi) che vengono criptate con la funzione hash usata dal sistema di autenticazione e confrontate con le password memorizzate

• Rainbow tables

• Tempo e spazio sono risorse limitate!

Password Robuste

• Linee guida: – evitare parole comuni (es: nomi) – evitare password brevi – usare caratteri maiuscoli E minuscoli – usare caratteri speciali (es: segni di punteggiatura) – usare i numeri

• Quando possiamo considerare una password robusta? – Roma – P1er03 – P@$$w0rd

Complessità della Password

• Possibili password di lunghezza pari a 6 simboli – solo numeri:

• 106 = 1,000,000

– solo caratteri maiuscoli O minuscoli : • 266 = 308,915,776

– solo caratteri maiuscoli E minuscoli : • 526 = 19,770,609,664

– solo 32 caratteri speciali (&, %, $, £, “, |, ^, §, etc.): • 326 = 1,073,741,824

– numeri + caratteri maiuscoli E minuscoli + caratteri speciali: • 946 = 689,869,781,056

– ASCII standard 7 bit, 27 =128 possibili simboli: • 1286 = 4,398,046,511,104

Lunghezza della Password

• Numeri + caratteri maiuscoli E minuscoli + caratteri speciali = 94 possibili simboli – lunghezza 5:

• 945 = 7,339,040,224

– lunghezza 6: • 946 = 689,869,781,056

– lunghezza 7: • 947 = 64,847,759,419,264

– lunghezza 8: • 948 = 6,095,689,385,410,816

– lunghezza 9: • 949 = 572,994,802,228,616,704

Scadenza della Password

• Es: scadenza password ogni 60 giorni

– # PW/sec da testare con un attacco brute-force, considerando un alfabeto di 94 simboli

• lunghezza 5: 1,415 PW/sec

• lunghezza 6: 133,076 PW/sec

• lunghezza 7: 12,509,214 PW/sec

• lunghezza 8: 1,175,866,008 PW/sec

• lunghezza 9: 110,531,404,750 PW/sec

Esempio di Password Robusta

“Voglio compr@re 11 Cani!”

• Per scoprire questa password con un attacco brute-force in 60 giorni dovrei disporre di un computer in grado di generare circa 3,86 x 1044 PW/sec!!!

Password Salt

• Salt: aggiunta di bit random all’input di una funzione hash (o di un algoritmo di crittografia) al fine di aumentare la randomicità dell’ouput

• Nel caso dell’autenticazione è possibile associare un numero random all’userID dell’utente – salt = numero random + userID

Password Salt

1. L’utente inserisce il suo userID X e la password P

2. Il processo di autenticazione dell’OS recupera il salt S per l’userID X e l’hash H del salt concatenato alla password associata a X

3. OS verifica se HASH(S||P) == H

Benefici

• Se l’attaccante non può trovare il salt associato con l’userID, allora lo spazio di ricerca per un attacco con dizionario cresce notevolmente:

– 2B x D

• B = # bits del salt, D = dimensione dizionario (# parole)

Benefici

• Anche se l’attaccante fosse in grado di recuperare il salt memorizzato in forma criptata dall’OS, questo meccanismo consente di rallentare notevolmente l’attacco con dizionario, rendendolo valido per un userID alla volta – senza salt è possibile crackare molte password nello

stesso momento, inquanto si ha solo bisogno dell’hash di ogni possibile password e di confrontarlo con tutti gli hash memorizzati

– con il meccanismo di salt, ogni possibile password va concatenata al salt ad essa associato prima di calcolarne l’hash

Benefici

• E’ possibile che due utenti utilizzino la stessa password, o che lo stesso utente scelga di utilizzare la stessa password per due account diversi

• Senza il meccanismo di salt le due password hanno lo stesso hash – questo potrebbe rivelare il fatto che i due account hanno

la stessa password, permettendo a chiunque che conosce una delle due password di accedere anche all’altro account

• Grazie al meccanismo di salt gli hash delle due

password risultano invece diversi

Keyloggers e Social Engineering

• Crackare una password potrebbe non essere l’unico modo per violare un sistema di autenticazione

• Un keylogger è uno strumento (HW o SW) in grado di intercettare tutto ciò che un utente digita sulla tastiera – per proteggersi da un keylogger che invia le informazioni catturate in

remoto si può utilizzare un firewall HW o SW per intercettare e bloccare la connessione del processo incriminato

– è inoltre possibile utilizzare tastiere virtuali sullo schermo, fornite da molti OS

LanManager Hash

• LM Hash (Lan Manager Hash): algoritmo per memorizzare le password nei sistemi Windows ormai obsoleti (Win 95/98)

• Tutt’oggi mantenuto per problemi di compatibilità (va attivato manualmente)

• Utilizzabile per password di lunghezza non superiore a 14 caratteri

• No prevede l’utilizzo del salt

LanManager Hash

1. Pwd convertita in UPPERCASE 1. se la dimensione della pwd è minore di 14B (1B per carattere)

viene eseguito un NULL padding 2. se la dimensione della pwd è maggiore di 14B viene troncata

2. Password divisa in 2 chiavi da 7B, aggiungendo poi uno 0 ogni 7 bit

3. Le due chiavi da 8B sono usate per criptare la parola “KGS!@#$%” con DES

4. I due valori cifrati sono concatenati per formare un LM Hash di 16B

LanManager Hash

UPPERCASE +

NULL PADDING / TRUNCATING

LanManager Hash

• Debolezze:

– case insensitive

• di 9514 possibili pwd (charset ASCII) ne restano 6914

– le password più lunghe di 7 caratteri sono divise in 2 metà trattate separatamente e crackabili separatamente

• 697 = 7.4*1012 possibili pwd

NT Lan Manager Hash

• NTLM Hash (NT Lan Manager Hash): sostituisce LM Hash nei sistemi Windows NT moderni

• Vero hash MD4

• Supporta l’intero charset Unicode

• Lunghezza massima 127 caratteri (limite della finestra di Logon)

NT Lan Manager Hash

PWD MD4 HASH NT

(16B)

• Non prevede l’utilizzo del salt

• Output di 16B (come LM Hash)

NT Lan Manager Hash

• Complessità password:

– charset=65535 simboli

– consideriamo una lunghezza pari a 14 caratteri

• 6553514 = 2.7*1067 possibili pwd

SICUREZZA DEI PROCESSI

Processi

• Un processo è un’istanza di un programma in esecuzione – il codice di un programma in esecuzione viene caricato dalla

memoria secondaria in cui è memorizzato e passato alla memoria primaria

– più istanze di uno stesso programma possono essere eseguite come processi diversi

– un processo può controllare altri processi – un’applicazione può essere composta da più processi – i processi attivi vengono eseguiti “parallelamente” attraverso la

tecnica di time-sharing su ogni core della CPU

• Ogni processo è univocamente identificato da un intero detto PID (Process ID ) e viene associato all’user (utente) che lo ha generato

Processi

• Un nuovo processo è generato mediante il meccanismo di forking

– il processo che richiede il forking è detto parent process, il processo forked è detto child process

– nella maggior parte degli OS il processo figlio eredita i permessi del processo padre

• a meno che il processo padre non specifichi esplicitamente i permessi del processo figlio

Esempio di Codice C

int main()

{

printf("I'm the parent, my PID is %d, my parent is process %d\n",

getpid(), getppid());

fork();

printf("This sentence has been printed by process: %d my parent

is process %d\n", getpid(), getppid());

}

Istruzione fork()

• L’istruzione fork() crea una copia del processo corrente – valore di ritorno

• 0 nel processo figlio • maggiore di 0 nel processo padre (il valore restituito è

proprio il PID del figlio) • minore di 0 nel caso in cui non sia stato possibile creare un

nuovo processo

– viene creato uno address space (porzione di memoria dedicata) separato per il processo figlio, il quale eredita una copia esatta di tutti i segmenti di memoria del processo padre (codice, stack, file descriptor, heap, variabili globali, e program counter)

Albero dei processi

• Il meccanismo di forking porta ad un’organizzazione dei processi rappresentabile con una struttura ad albero radicato (rooted tree)

• Linux: la radice dell’albero è sempre il processo init che viene lanciato dal kernel durante il processo di boot del sistema operativo. Il processo init crea poi nuovi processi

• Windows: le applicazioni lanciate dagli utenti sono sempre figlie del processo Windows Explorer

Comunicazione tra Processi

• IPC (Inter-Process Communication): i processi devono poter comunicare tra loro al fine di gestire risorse condivise

• Ci sono diversi motivi per cui fornire un ambiente che permette la cooperazione tra processi: – condivisione delle informazioni – modularità – separazione dei privilegi

• IPC consente di realizzare un importante principio di sicurezza dei processi basato sull'indipendenza e l’isolamento degli address space di processi diversi

Comunicazione tra Processi

• Esistono diversi meccanismi per la comunicazione tra processi: – lettura/scrittura di files

• semplice ma inefficiente (e poco sicuro)

– porzione di memoria RAM condivisa • veloce ed efficiente • il kernel deve gestire in maniera sicura la separazione tra porzioni di

memoria condivise e private

– pipes e sockets • oggetti in RAM condivisi che fungono da canale virtuale tra due

processi

– signals • notifiche asincrone, il processore interrompe il flusso del processo

ricevente e verifica se esiste un gestore per la notifica (routine da eseguire)

Demoni e Servizi

• Linux: i daemons sono processi lanciati prima dell’autenticazione dell’utente, tipicamente dal processo init – possiedono permessi più alti di qualsiasi utente – sopravvivono al termine delle sessioni utente – sono indistinguibili dagli altri processi

• Windows: esistono processi analoghi chiamati services

– rispetto ai daemons sono distinguibili dagli altri processi – sono monitorati in modo specifico all’interno del

TaskManger (esistono due tab separati, uno per i processi e uno per i servizi)

Kernel

• Il kernel è il componente principale di un OS, inquanto gestisce direttamente l’hardware di basso livello (CPU, memoria, periferiche di I/O)

• Le periferiche di I/O (tastiera, mouse, scheda di rete,…) sono pilotate attraverso drivers – i drivers espongono alle applicazioni delle API

(Application Programmer Interface) al fine di consentire l’utilizzo della periferica ad alto livello

– un driver è specifico sia dal punto di vista dell'hardware che pilota, sia dal punto di vista del sistema operativo per cui è scritto

System Call

• I processi comunicano con il kernel per inoltrare le richieste verso l’hardware. La comunicazione avviene mediante librerie dette system call – ad ogni system call segue generalmente un interrupt

che vincola il processore a fermare l’esecuzione corrente e a gestire la chiamata

• Possibili attacchi: – contraffazione di una system call al fine di eseguire

codice malevolo ad ogni chiamata – danneggiamento di una system call al fine di

compromettere il funzionamento del sistema

System Call

• Sempre più spesso in realtà, i programmatori non usano direttamente le system call, ma delle API che fungono da strato intermedio tra le applicazioni e le system call, al fine di facilitare e migliorare la portabilità delle applicazioni

• Esistono API per i vari sistemi operativi: – API Win32 per i sistemi Windows

– API POSIX per le varie versioni di Unix, Linux e Mac OS X

System Call

• Le funzioni contenute in queste API invocano a loro volta opportune system call e spesso vi è una corrispondenza diretta tra una funzione API ed una corrispondente system call

• Ad esempio, la libreria C dell’ambiente Unix è una semplice forma di API. In questa libreria esiste la funzione per aprire un file:

FILE *fp;

// usa la system call ”open”

fp = fopen(”myfile”, ”W”);

//usa la system call “write”

fprintf(fp,”ciao”);

//usa la system call “close”

fclose(fp);

System Call

• Esistono tipi di System Call per ogni possibile operazione: – controllo dei processi:

• creazione, terminazione, esecuzione di codice specifico

• prelievo degli attributi di un processo

• attesa per un tempo indicato

• sincronizzazione con altri processi

– gestione dei file: • creazione, cancellazione, rinominazione

• apertura, chiusura, lettura, scrittura

• impostazione delle proprietà

System Call

– comunicazione fra processi:

• creazione e chiusura del canale di comunicazione

• invio e ricezione di messaggi

• informazione sullo stato della comunicazione

– gestione dei dispositivi

– gestione delle informazioni di sistema

Utenti

• Ogni processo è associato ad un utente

• Utenti specifici possono avere permessi maggiori rispetto agli utenti normali

– installare o rimuovere programmi

– modificare i permessi degli altri utenti

– modificare la configurazione del sistema

Utenti

• Nei sistemi Unix l’utente root non ha alcuna restrizione • Nei sistemi Windows esistono diversi utenti speciali

– SYSTEM, LOCAL SERVICE e NETWORK SERVICE associati direttamente al sistema operativo • SYSTEM non ha restrizioni • LOCAL SERVICE e NETWORK SERVICE agiscono con permessi ridotti e specifici

per i loro scopi

– uno o più administrator (con permessi minori rispetto all’utente SYSTEM)

• L’autenticazione come root/administrator può essere rischiosa – in caso di eliminazione accidentale di file di sistema – in caso di esecuzione accidentale di codice malevole che può agire con

gli stessi permessi

Linux

• Ad ogni processo sono associati 4 indici – un uid (user ID) che identifica l’utente che ha lanciato il processo – un gid (group ID) che identifica il gruppo a cui appartiene l’utente – un euid (effective user ID) che può differire dall’uid e identificare l’utente

proprietario del file eseguibile, il quale può avere permessi maggiori • l’euid prevale sull’uid solo nel caso in cui è settato il bit setuid

– Un egid (effective group ID) che può differire dall’gid e identificare il gruppo proprietario dell’applicazione, il quale può avere permessi maggiori • l’egid prevale sull’gid solo nel caso in cui è settato il bit setgid

• Tramite questi id OS è in grado di stabilire i permessi di un dato processo su una data risorsa

• I permessi del processo figlio sono automaticamente ereditati dal processo padre

Linux

• La decisione di attivare o meno il bit setuid/setgid dipende dal proprietario del file eseguibile (di default sono disattivati)

• Comandi: – chmod u+s <file_eseguibile>: attiva setuid – chmod u-s <file_eseguibile>: disattiva setuid – chmod g+s <file_eseguibile>: attiva setuid – chmod g-s <file_eseguibile>: attiva setuid

• Molti programmi che accedono risorse di sistema hanno il bit setuid settato e sono detti setuid programs (es: passwd, su) – Questo meccanismo può essere soggetto ad attacchi di scalata dei

privilegi, che vedremo più avanti

Linux – Esempio 1/2

• app: nome di un file eseguibile

• userA e groupA: UID e GID dell’utente proprietario del file app

• userB e groupB: UID e GID dell’utente che lancia app, producendo il processo P

• Se il bit SETUID di app è attivo: – l’ EUID di P è userA, il EGID di P è groupA – l’UID di P è userB, il GID di P è groupB

• Se il bit SETUID di app NON è attivo: – EUID e UID coincidono con userB – EGID e GID coincidono con groupB

Linux – Esempio 2/2

• Supponiamo ora che il processo P voglia accedere ad un file di nome info 1. se EUID di P coincide con il proprietario di info, il

processo acquisisce i diritti di accesso del proprietario di info

2. ALTRIMENTI se EGID di P e il gruppo di info coincidono, P acquisisce i diritti di accesso del gruppo di utenti associato a info

3. se NESSUNA delle due precedenti condizioni `e valida, valgono i normali diritti di accesso che vedremo più avanti (lettura/scrittura/esecuzione), l’accesso sarà consentito o meno a seconda della categoria di utenti nella quale ricadono UID e GID del processo P

Windows

• WUAC (Windows User Access Control):

– permessi standard per l’uso regolare

– possibilità di acquisire i permessi da amministratore solo temporaneamente, su richiesta esplicita dei programmi

Monitoraggio dei processi

• Il monitoraggio dei processi in esecuzione può rivelare la presenza di codice malevolo – verificare il nome dei processi

• è opportuno conoscere il nome dei processi considerati sicuri

• è importante notare anche piccole differenze nei nomi

– verificare inoltre (anche per i processi sicuri) • user • attività di rete (porte aperte, traffico,…) • immagine (file eseguibile associato al processo)

– path del file – autore – firma digitale (se presente e verificabile)

Comandi Linux

• pstree: mostra l’albero dei processi in esecuzione

• ps: mostra i processi in esecuzione

in forma tabulare – ps -ef: tutti i processi – ps -u<username>: solo i

processi dell’utente specificato

• top: lista dei processi in esecuzione ordinati per consumo di CPU

• kill<pid>: termina il processo con pid specificato

Strumenti Windows

• TaskManager: applicazione standard

– lista dei processi in esecuzione

– informazioni base per ogni processo

– possibilità di terminare processi

• ProcessExplorer: add-on gratuito

– informazioni dettagliate per ogni processo

– visualizzazione albero dei processi

– funzionalità aggiuntive

– scaricabile al seguente URL: http://technet.microsoft.com/en-us/sysinternals/bb896653

http://technet.microsoft.com/en-us/sysinternals/bb896653



Threads

• La necessità di ottimizzare al meglio il tempo di esecuzione di un processo ha portato all’introduzione della nozione di thread

• I thread sono delle sottoattività di un processo che godono della proprietà di poter essere eseguite tutte in “parallelo”

– i thread non sono dei nuovi processi!

Threads

Threads

• I thread all’interno di un processo condividono: – PID – address space – codice – variabili non locali – file descriptors aperti – user e group id

• Mentre non condividono: – Thread ID (TID) – l’insieme dei registri, compresi program counter e stack pointer – stack per le variabili locali e record di attivazione

Threads

• Operazioni comuni

– create

– exit

– suspend

– resume

– sleep

– wake

– join

Threads

• User-level threads – implementati attraverso librerie ad alto livello che consentono la creazione, lo

scheduling, e la sincronizzazione dei thread – OS ignora la presenza dei thread

• Vantaggi: – non è richiesto alcun supporto da parte del SO (maggiore portabilità) – possono essere predisposte politiche di scheduling adeguate all’applicazione – le operazioni su thread sono efficienti perché non richiedono l’esecuzione di

system call – la condivisione di memoria è facile e veloce

• Svantaggi: – l’intero processo si blocca quando si blocca un solo thread – gli accessi ai dati condivisi devono essere opportunamente sincronizzati per

evitare errori

Logging

• Un ulteriore tipo di analisi legato ai processi consiste nel monitoraggio degli eventi registrati dall’OS – tentativi di login, attività di rete,…

• Linux Logging

– diversi tipi di log (boot, I/O errors,…) – salvataggio in files di testo semplici – diversi file di log in base alla distribuzione

• Windows logging – eventi divisi in Sistema, Applicazioni e Sicurezza – ogni evento ha un id univoco – visualizzazione possibile solo con Windows Event Viewer

Linux Logging

• Formato standard linux

• File contenuto in /var/log/messages e accessibile solo all’utente root

Windows Event Viewer

Sequenza di Boot

• La sequenza di boot o booting si riferisce al caricamento del sistema operativo in memoria 1. inizialmente il processore esegue il codice

memorizzato nel componente firmware chiamato BIOS (Basic Input/Output System) • in questa prima fase vengono eseguite vari attività tra cui

un controllo dell’hardware chiamato POST

2. viene richiamato un boot loader secondario (second-stage boot loader o secondary loader) che a sua volta carica in memoria l’OS

3. il controllo passa all’OS

Sequenza di Boot

Sequenza di Boot

• In molti casi il boot loader secondario consente all’utente di specificare il dispositivo da cui caricare il sistema operativo (es: hard disk, DVD drive, USB controller)

• Un possibile scenario di attacco consiste nel dirottare il boot loader secondario verso un dispositivo esterno – Il processore carica l’OS dell’avversario che può essere una

contraffazione dell’OS della vittima

– Molti boot loader secondari richiedono una password al fine di effettuare modifiche

Ibernazione

• I calcolatori moderni offrono la possibilità di passare in modalità di ibernazione, in cui il consumo di energia elettrica è interrotto

– il contenuto della memoria primaria è copiato nella memoria secondaria

• tutte le informazioni sensibili (password, dati personali,…) sono memorizzate sul disco fisso

– al riavvio i dati vengono nuovamente caricati sulla memoria primaria

Vulnerabilità di Windows

• Windows memorizza questi dati nel file C:\hiberfil.sys compresso – alcuni ricercatori hanno dimostrato che è possibile decomprimere

questo file al fine di ricreare un’immagine della memoria primaria al momento dell’ibernazione

• Come ottengo una copia del file?

– è possibile estrarre il disco fisso da un computer ibernato – ancora più facilmente, Windows non elimina subito il file hiberfil.sys

che può restare salvato per diversi riavvii, permettendo una copia del file in un secondo momento

• come proteggersi?

– è possibile utilizzare algoritmi di cifratura robusti per criptare i file memorizzati sul disco rigido

SICUREZZA DEL FILESYSTEM

Filesystem

• Il filesystem è un altro componente fondamentale di un OS, in quanto fornisce un’astrazione sull’organizzazione della memoria secondaria del calcolatore

• Gli OS organizzano tipicamente i file in una gerarchia – Ogni cartella può contenere file e/o sottocartelle

• In questo modo è possibile rappresentare la memoria secondaria attraverso una struttura ad albero radicato

Windows Explorer

Terminologia

• Principal: utente o gruppo di utenti

• Permission: azione possibile • read

• write

• execute

• list

Access Control Entries

• ACE (Access Control Entry): tripla <principal,type,permission> – type può avere due soli valori: ALLOW o DENY – definisce esplicitamente cosa è possibile fare e cosa

non per una specifica risorsa e per un dato principal

• ACL (Access Control List): lista ordinata di triple ACE

• Ad ogni file e directory viene associata un ACL che definisce la politica di accesso alla risorsa

Discretionary Access Control

• DAC (Discretionary Access Control): il creatore (owner) di un file o directory ha il potere di modificare i permessi ad esso associati (ACE)

– Closed policy o default sicuro: solo ACE di tipo allow, tutti i permessi non esplicitamente concessi sono automaticamente negati

– Open policy: ACE tipo sia ALLOW che DENY

Linux Access Control

• DAC con default sicuro

• L’accesso a un file dipende da ACL del file e di tutte le directory antenate:

– partendo dalla directory root

• tutte le directory antenate devono avere il permesso execute per l’utente specificato

– il file deve avere il permesso per l’accesso richiesto (es. read) per l’utente specificato

Permessi Linux

• File permission matrix: matrice di permessi associata ad ogni file e directory

– standard per tutti i sistemi Unix

– 3 classi di permessi

• owner: permessi per l’utente creatore del file

• group: permessi per gli utenti appartenenti allo stesso gruppo del file

• others: permessi per gli utenti che non sono il creatore del file né appartengono allo stesso gruppo

Permessi Linux

• I permessi di ognuna delle 3 classi sono definiti da 3 bit: – read bit:

• file: l’utente può leggere il file

• directory: l’utente può leggere la lista dei file in essa contenuti

– write bit: • file: l’utente può modificare il contenuto del file

• directory: l’utente può creare ed eliminare i file in essa contenuti

– execute bit: • file: l’utente può eseguire il file come un programma

• directory: può cambiare la sua cartella corrente con essa

Esempi

Comandi Linux

• ls –l: restituisce la matrice dei permessi per tutti i file e le directory contenuti nella directory di lavoro corrente

Permessi Speciali Linux

• Set-user-ID (suid o setuid) bit – su file eseguibili, causa l’esecuzione del processo con i

diritti dell’utente owner

• Set-group-ID (sgid o setgid) bit – su file eseguibili, causa l’esecuzione del processo con i

diritti del gruppo del file

• Sticky bit

– sulle directory, vieta a tutti gli utenti di eliminare o rinominare file di cui non sono i creatori

Notazione Ottale

• Permessi espressi con un numero di 3 o 4 cifre in base 8

• Cifre da sx a dx: – [special bits][user bits][group bits][others bits]

• Bits speciali:

– 4 (se setuid) + 2 (se setgid) + 1 (se sticky)

• User/Group/Others bits:

– 4 (se readable) + 2 (se writable) + 1 (se executable)

Esempi

Accesso Senza Privilegi

• Il bit setuid risolve il problema dell’accesso senza privilegi

• Esempio: – sappiamo che un processo eredita i permessi dal

processo padre – se un utente volesse modificare la propria password

attraverso il programma di sistema passwd non potrebbe farlo inquanto non avrebbe i permessi per accedere al file etc/passwd

– In realtà passwd viene eseguito con i privilegi dell’utente root grazie al bit setuid

Scalata dei Privilegi

• Se un attaccante riesce a forzare un programma setuid a eseguire codice arbitrario (ad esempio tramite un attacco di tipo buffer overflow) può compromettere il sistema, realizzando uno scenario di attacco chiamato scalata dei privilegi (o privileges escalation)

• Questo meccanismo va gestito attraverso tecniche di programmazione sicura

Esempio di Codice C #include <stdio.h>

#include <sys/types.h>

#include <unistd.h>

#include <stdlib.h>

static uid t euid, uid;

int main(int argc, char * argv[ ])

{

FILE *file;

/* Store real and effective user IDs */

uid = getuid();

euid = geteuid();

/* Drop priviliges */

seteuid(uid);

/* Do something useful */

/* . . . */

/* Raise privileges */

seteuid(euid);

/* Open the file */

file = fopen("/home/admin/log", "a");

/* Drop privileges again */

seteuid(uid);

/* Write to the file */

fprintf(file, "Someone used this program.\n");

/* Close the file stream and return */

fclose(file);

return 0;

}

Nautlius

• Nautilus è il file manager

ufficiale dell'ambiente

desktop GNOME

Windows Access Control

• DAC con open policy • Se non c’è una regola per un particolare principal o

permesso allora l’accesso è negato di default

• Se non c’è una regola per un particolare principal o permesso allora l’accesso è negato di default

• A differenza di Linux, al fine di accedere ad un file o ad una directory, è sufficiente avere i permessi per l’azione richiesta sul dato file o directory – in questo modo è possibile negare l’accesso ad una data

directory pur consentendo l’accesso alle directory figlie

Permessi Espliciti

• Explicit permissions – standard permissions

• modify • read and execute • read • write • full control

– advanced permissions

• è possibile comporre i permessi standard per creare permessi più complessi – Es: read data, read attributes,…

Permessi Ereditati

• Inherited permissions: ogni permesso applicato ad una directory può essere esteso alle directory figlie

• Controllo dei permessi: – Il permesso DENY ha precedenza sul permesso ALLOW

– I permessi espliciti hanno precedenza sui permessi ereditati

– I permessi ereditati hanno precedenza tra di loro in base alla distanza dalla risorsa

Windows Explorer

NTFS

• NTFS (New Technology File System): sostituisce il filesystem FAT (File Allocation Table) nei moderni OS Microsoft

• Filesystem chiuso e proprietario, utilizzabile solo dagli OS Microsoft

• Supporta meccanismo ACL appena descritto

File Descriptors

• Un file descriptor o file handle è un identificatore per un file o per una cartella

• I file descriptor sono memorizzati in una tabella che li mappa con il percorso del file a cui si riferiscono, chiamata file descriptor table

• Operazioni possibili – open: ritorna un file handle – read/write/execute file – close file: invalida il file handle

File Descriptors

• Quando un processo (programma) necessita di accedere ad un file in lettura o scrittura: – viene richiamata una open system call – il kernel verifica se il processo possiede i permessi necessari per

accedere al file con l’azione richiesta – se la verifica è positiva, il kernel crea un nuovo file descriptor e

una nuova entry nella file descriptor table, quindi ritorna il file descriptor al processo

– il processo può leggere/scrivere sul file richiamando le relative read/write system call, il kernel (attraverso la file descriptor table) effettua le letture/scritture direttamente sul file originale

– Al termine il processo dovrebbe richiamare una close system call per rimuovere il file descriptor

File Descriptors Leaks

• Quando un processo crea un processo figlio (forking), quest’ultimo eredita una copia di tutti i file descriptors aperti dal processo padre

• L’OS verifica i permessi soltanto al momento della creazione del file descriptor – Al momento della lettura/scrittura sul file, i controlli

effettuati si basano sui permessi associati al file descriptor (ad esempio un processo può sfruttare un file descriptor in lettura solo per leggere il file e non per scrivere)

File Descriptors Leaks

• Scenario pericoloso: – un processo con alti privilegi apre un file

descriptor per un file protetto

– prima di chiudere il file descriptor crea un nuovo processo con privilegi minori, il quale eredita comunque il file descriptor (inquanto ancora aperto)

– il processo figlio può usare il file descriptor pur non avendo i permessi necessari per operare sul file protetto!

Esempio di Codice C

#include <stdio.h>

#include <unistd.h>


{

/* Open the password file for reading */

FILE *passwords;

passwords = fopen("/home/admin/passwords", "r");

/* Read the passwords and do something useful */

/* . . . */

/* Fork and execute Joe’s shell without closing the file */

execl("/home/joe/shell", "shell", NULL);

}

• Per rimuovere questa vulnerabilità la funzione fclose() va richiamata prima del comando execl()

Symbolic Links

• Nei sistemi Unix un link simbolico (symlink) è un file che contiene le informazioni utili a referenziare un altro file presente nel filesystem

• Più symlink possono essere concatenati (l’ultimo symlink della catena deve comunque puntare ad un file fisico)

• Per le applicazioni un symlink è trasparente – è compito dell’OS risalire al file partendo dal symlink usato

dall’applicazione – Questo approccio può creare problemi di sicurezza inquanto vano

verificati i permessi sia sul symlink (o sulla catena di symlink) sia sul file che esso punta

Shortcuts

• I sistemi Windows utilizzano invece le shortcuts, che in maniera simile ai symlink puntano ad altri file

• Le shortcuts non sono trasparenti alle applicazioni ma sono trattate come file normali – solo i programmi che le riconoscono come shortcuts

possono risalire al file puntato

– approccio più sicuro

SICUREZZA DELLA MEMORIA

Address Space

• Un ulteriore servizio offerto dagli OS è l’organizzazione e l’allocazione della memoria primaria

• Quando un processo viene lanciato l’OS alloca una regione di memoria detta address space del processo – la gestione della memoria è trasparente per il processo

– il processo “vede” a sua disposizione l’intera memoria

• Generalmente un processo non può avere accesso all’address space di un altro processo, se non per risorse esplicitamente condivise

Unix Address Space

• Modello address space diviso in 5 settori: – Text: memorizza il codice macchina del programma – Data: memorizza le variabili statiche del programma

inizializzate prima dell’esecuzione – BSS (Block Started By Symbol): memorizza le variabili

statiche del programma non inizializzate – Heap: settore dinamico, memorizza i dati generati

durante l’esecuzione del programma (es: oggetti Java/C#/C++)

– Stack: memorizza una struttura dati a pila, che tiene traccia delle chiamate a metodi e routine con i relativi argomenti e punti di ritorno

Unix Address Space

Lo stack cresce verso il basso

Unix Address Space

• Ogni settore ha il suo set di permessi

– readable/writable/executable

– il settore text è read-only inquanto il codice macchina del programma in esecuzione non deve essere modificato

– gli altri settori necessitano di essere writable inquanto i loro dati devono poter essere modificati durante l’esecuzione

Exploit

• Un exploit è un input che sfrutta una vulnerabilità, un bug o un guasto di un sistema al fine di eseguire un attacco

• Attacco tipico:

– ricerca di una vulnerabilità

– reverse engineering del codice

– costruzione dell’exploit

Disassemblers e Decompilatori

• Un disassembler è un programma che traduce dal linguaggio macchina al linguaggio assembly (operazione inversa di un assembler)

• L'output di un disassembler (disassembly) è spesso fatto in modo da poter essere facilmente compreso dall'uomo piuttosto che per essere utilizzato come input per un assembler

• I disassembler sono tra gli strumenti più comunemente utilizzati per il reverse engineering del software

• Un decompilatore traduce il linguaggio macchina in un linguaggio ad alto livello

Disassemblers e Decompilatori

• Le costanti simboliche e i commenti vengono generalmente rimossi dall'assembler – la perdita di queste informazioni rende più difficile la

comprensione del codice rispetto al codice sorgente originario

• Sulle piattaforme con le istruzioni CISC di larghezza variabile, o in presenza di codice auto-modificante, è possibile per un unico programma per avere due o più assembly plausibili – determinare quali istruzioni si incontreranno durante

un’esecuzione del programma si riduce al problema della fermata (dimostrato irrisolvibile)

Interactive Disassembler

• Interactive DisAssmbler (IDA) è un disassembler largamente usato per il reverse engineering. Supporta numerosi formati di file eseguibili per diversi processori e OS

• Caratterizzato soprattutto dall'interattività – un tipico utente di IDA inizierà con un listato generato

automaticamente per poi rinominare, commentare, o aggiungere in altri modi informazioni al codice disassemblato

• Approfondimento: http://www.hex-rays.com/idapro/

http://www.hex-rays.com/idapro/





Buffer Overflow

• Buffer: blocco di memoria contiguo che contiene più istanze dello stesso tipo – in C e in molti altri programmi i buffer sono chiamati array

– i buffer più comuni sono gli array di caratteri (stringhe)

• In C i buffer, come tutte le variabili, possono essere dichiarati statici o dinamici – le variabili statiche sono allocate al momento del

caricamento del programma sul segmento data

– le variabili dinamiche sono allocate in fase di esecuzione sullo stack

Buffer Overflow

• Scenario: – un programma alloca in memoria un buffer (array) di

dimensione fissata – nel buffer viene poi copiato un input proveniente dall’utente – la dimensione di tale input non viene controllata prima

dell’operazione di copia

• Attacco: – un attaccante può confezionare un input malevolo di

dimensione superiore a quella del buffer – il programma copia l’input e sovrascrive regioni di memoria

oltre al buffer – l’attaccante riesce a eseguire codice malevolo (shellcode) con i

privilegi del programma attaccato

Shellcode

• Codice malevolo iniettato sfruttando un attacco buffer overflow – buffer riempito di codice malevolo = payload

• L’attaccante solitamente inietta codice in grado di aprire un

terminale (shell) attraverso cui eseguire altri comandi – Linux: /bin/sh – Windows: command.com

• Ad esempio in un sistema Linux è possibile iniettare codice che richiama la

funzione setuid() per poi aprire un terminale

• Il codice viene generalmente iniettato direttamente sullo stack o

sull’heap e pertanto deve essere scritto in codice operativo (opcodes) specifico per l’architettura della CPU attaccata

Morris Worm

• Primo worm a sfruttare una vulnerabilità di tipo buffer overflow – scritto da Robert Morris nel 1988 allo scopo dichiarato di

valutare le dimensioni di Internet – autoinstallante e autoreplicante, si è diffuso in maniera

estremamente veloce, oltre le aspettative di Morris

• Il target è la funzione gets() appartenente alle librerie C

standard e utilizzata nel servizio finger dell’Università di Berkley – gets() legge una riga dallo standard input e la memorizza in

un buffer di 512 byte senza verificare le dimensioni effettive della riga letta

Morris Worm

• Attacco:

– input di dimensione pari a 536 byte che causa il buffer overflow

– indirizzo di ritorno della routine sovrascritto con l’indirizzo dello shellcode (codice macchina per architettura VAX)

– lo shellcode lancia una shell e richiama il processo di bootstrap della macchina al fine di installarsi

– attacco di tipo Denial Of Service

Morris Worm

• Morris fu condannato ad una pena di tre anni di libertà condizionata, 400 ore di servizi socialmente utili e 10.050 dollari di multa

• Oggi insegna al MIT Lab for Computer Science

• Nel 1998 ha venduto a Yahoo!, al prezzo di 49 milioni di dollari, una start-up da lui fondata, Viaweb Inc. (oggi Yahoo! Store)

Arithmetic Overflow

• Caso più semplice di attacco, sfrutta la rappresentazione di numeri interi

• La maggior parte delle architetture a 32 bit gli interi con segno sono rappresentati in complemento a due – il bit iniziale (più a sinistra) del numero ha peso negativo o

positivo: tutti i numeri che cominciano con un "1" sono numeri binari negativi, mentre tutti i numeri che cominciano con uno "0" sono numeri binari positivi e se ne ottiene il valore assoluto invertendo il valore dei singoli bit e aggiungendo 1 al numero binario risultante

– un numero binario di n cifre può rappresentare con questo metodo i numeri compresi fra -2n-1 e +2n-1-1

Arithmetic Overflow

• In esadecimale gli interi con segno da 0x00000000 a 0x7ffffff sono numeri positivi, mentre da 0x80000000 a 0xffffffff sono numeri negativi

• La soglia tra questi due range consente situazioni di overflow e underflow – Es: la somma di numeri molto grandi può portare ad

un overflow, dando come risultato un numero negativo

Stack-Based Buffer Overflow

• Perché viene usato lo stack?

• I moderni computer sono progettati tenendo in mente la necessità di poter usufruire di linguaggi di alto livello (come C e C++). – la tecnica più importante per la strutturazione dei programmi

introdotta dai primi linguaggi di alto livello è la routine (function) – una chiamata a una procedura altera il flusso di controllo proprio

come fa un salto, ma a differenza di un salto, al suo termine il controllo ritorna alla dichiarazione o istruzione successiva alla chiamata

– questo alto livello di astrazione è implementato con l'aiuto dello stack

• Lo stack è usato nell’ambito delle routine per allocare dinamicamente le variabili locali, per il passaggio dei parametri, e per la restituzione di valori


• Lo stack è un settore dell’address space contenente dati. La sua dimensione è regolata dinamicamente dal kernel in fase di esecuzione – politica LIFO (Last In First Out)

• la CPU esegue le istruzioni di PUSH e POP

– ogni chiamata ad una routine è associata ad un frame che memorizza le variabili locali, gli argomenti, e l’indirizzo di ritorno verso la chiamata padre

– alla base dello stack c’è il frame relativo alla chiamata main()

• Un buffer overflow che coinvolge una variabile locale può causare la sovrascrittura di parte della memoria allocata nello stack, con conseguenze pericolose


• Return address: puntatore all’indirizzo di memoria in cui la routine in questione è stata chiamata

• Stack pointer (ESP): registro dedicato che contiene l'indirizzo dell'ultima locazione di memoria occupata sullo stack (ovvero il top dello stack vista la politica LIFO di inserimento) – viene aggiornato continuamente vista la dinamicità dello stack

• Frame pointer (EBP): registro per tenere traccia della prima

locazione di memoria del record di attivazione di una routine


• Gli indirizzi delle variabili locali di una routine sono specificati rispetto al frame pointer poiché il suo valore rimane invariato per tutta la durata della routine stessa

Esempio

void function(int a, int b, int c)

{

char buffer1[5];

char buffer2[10];

}

void main()

{

function(1,2,3);

}

c

b

a

Return Address

Frame Pointer

buffer1 (8 bytes)

buffer2 (12 bytes)

Esempio di Codice C (1/2)

• La funzione strcpy(dest,src) (appartenente alle librerie C standard) copia la stringa src in dest senza verificare se la dimensione di src eccede quella di dest

Main(int argc, char *argv[])

/* get user_input */

{

char var1[15];

char command[20];

strcpy(command, “whois ");

strcat(command, argv[1]);

strcpy(var1, argv[1]);

printf(var1);

system(command);

}

Esempio di Codice C (2/2)

• La funzione strncpy(dest,src,n) consente di specificare il numero di caratteri da copiare, se la lunghezza di src supera quella di dest i caratteri in eccesso vengono scartati

Main(int argc, char *argv[])

/* get user_input */

{

char var1[15];

char command[20];

strcpy(command, “whois ");

strcat(command, argv[1]);

strcpy(var1, argv[1]);

printf(var1);

system(command);

}

Stack Smashing Attack

• Stack smashing attack: l’attaccante sfrutta una vulnerabilità buffer overflow per sovrascrivere l’indirizzo di ritorno della routine corrente

– quando la routine termina il programma segue il codice malevolo iniettato dall’attaccante, anziché riprendere il normale flusso di esecuzione

• Difficoltà: l’attaccante deve conoscere l’esatta posizione sullo stack dell’indirizzo di ritorno


• Al fine di confezionare un attacco efficace l’attaccante deve: – assicurarsi che il codice malevolo iniettato risieda

nell’address space del processo attaccato (altrimenti non sarebbe eseguito) • il codice può essere tenuto nel buffer stesso (payload)

– Conoscere l’indirizzo dello shellcode (buffer) • NOP Sledding

• Trampolining

• Return-to-libc

NOP Sledding

• NOP (No-op): istruzione che non fa nulla, il processore esegue semplicemente l’istruzione seguente

• L’attaccante confeziona un input che contiene: – una quantità di dati appropriata da eccedere le dimensioni del buffer – una stima dell’indirizzo di ritorno – una grande quantità di istruzioni NOP – lo shellcode

• Semplifica il problema di dover conoscere esattamente la posizione dello shellcode – la dimensione del payload aumenta grazie al gran numero di istruzioni

NOP

NOP Sledding

• Se l’attacco funziona il processo salterà al punto di ritorno stimato (sovrascritto da qualche istruzione NOP) e “slitterà” verso il codice malevolo attraverso la catena di istruzioni NOP

NOP Sledding

• Il NOP Sledding aumenta le probabilità di riuscita per un attacco buffer overflow

– attacco molto utilizzato

– difficile da automatizzare

– serve molto spazio per il payload

– bisogna ancora stimare in qualche misura l’indirizzo dello shellcode

Trampolining

• Al momento della loro inizializzazione molti processi caricano nel loro address space delle librerie esterne

• Queste librerie sono caricate in zone protette dell’address space e la loro locazione è prevedibile

• Un attaccante può sfruttare la conoscenza di una libreria di sistema per eseguire un attacco senza dover conoscere l’indirizzo dello shellcode

Esempio

• Un attaccante sa che una DLL di sistema di Windows richiede al processore di saltare all’indirizzo del registro ESP che punta ad un buffer

• L’attaccante inserisce il codice malevolo nel buffer indirizzato dal registro e sovrascrive il punto di ritorno della funzione corrente con quello dell’istruzione nota della DLL

• Attacco difficile ma estremamente pericoloso inquanto automatizzabile

Return-to-libc

• Anche questa tecnica sfrutta librerie esterne caricate in fase di esecuzione

• libc: librerie C

• Un attaccante può determinare l’indirizzo di una funzione presente nelle librerie C all’interno dell’address space da colpire e forzare il programma a chiamare questa funzione

Return-to-libc

• Attacco:

– buffer overflow causa la sovrascrittura dell’indirizzo di ritorno con l’indirizzo della funzione C da richiamare (es: exec())

– oltre all’indirizzo di ritorno l’attaccante sovrascrive il buffer con gli argomenti per la funzione (es: “bin/sh”)

Esempio

args

ret-addr

sfp

local buf

stack

exec()

printf()

“/bin/sh”

libc.so

Vantaggi

• Non viene eseguito alcun codice sullo stack

– attacco utilizzabile anche in caso di stack non eseguibile

– le librerie C offrono diverse funzioni target exec(), system()

Approfondimento

• How To Write A Buffer Overflow – http://insecure.org/stf/mudge_buffer_overflo

w_tutorial.html

• Peiter C. Zatko, meglio conosciuto come

Mudge (Boston, 1970), è un hacker statunitense – nel 1995 scopre la vulnerabilità buffer

overflow – nel 2000 sviluppa un software per il cracking

delle password in ambiente Windows (lo vedremo più avanti)

http://insecure.org/stf/mudge_buffer_overflow_tutorial.html



Contromisure per Stack-Based BO

• Scrivere codice sicuro che verifica sempre le dimensioni dell’input proveniente dall’utente

• Utilizzare linguaggi di programmazione che non consentono questo tipo di attacchi – C,C++ sono suscettibili a questi attacchi – Java e C# (e altri) non lo sono inquanto gli oggetti vengono allocati

dinamicamente sullo heap

• Meccanismi di protezione a livello di OS

– NX bit – ASLR – Stack-Smashing Protection – Canary

Canary

No eXecute Bit

• NX (No eXecute) bit: bit che marca come non eseguibile i segmenti di memoria relativi allo stack e all’heap

• In questo modo non è possibile eseguire shellcode direttamente sullo stack e sull’heap

– contromisura non efficace per attacco return-to-lib

Address Space Layout Randomization

• ASLR (Address Space Layout Randomization): l’address space di un processo viene arrangiato randomicamente – supportata dai sistemi Windows a partire da Vista (2007)

– supportata anche dai sistemi Linux e Apple

• Tecnica suscettibile ad attacchi brute-force: l’attaccante può sfruttare un generatore di numeri pseudo-random e ripetere l’attacco più volte – poco efficace in sistemi a 32 bit (pochi bit disponibili per la

randomizzazione)

– più efficace per sistemi a 64 bit

Esempio

• Due boot di Vista diversi portano a locazioni delle librerie in memoria diversi

Stack-Smashing Protection

• Controllo in fase di esecuzione

• Nel momento in cui una routine chiama l’indirizzo di ritorno l’OS verifica se lo stack sia stato modificato rispetto al momento in cui la funzione è stata chiamata

• Se lo stack è stato modificato viene lanciato un errore di tipo segmentation fault e il programma termina forzatamente

Canary

• Controllo in fase di esecuzione

• Canary: valore di controllo (spesso random) inserito dall’OS dopo un buffer o prima dell’indirizzo di ritorno

– l’OS verifica regolarmente l’integrità di questo valore

– In caso di buffer overflow e di sovrascrittura dell’indirizzo di ritorno anche il canarino viene sovrascritto

Heap-Based Buffer Overflow

• I programmi possono allocare memoria dinamica e persistente sull’heap – possono verificarsi leak memory se questa memoria non

viene liberata • in Java e C# esiste il Garbage Collector

• Con un heap overflow non è possibile alterare direttamente l’esecuzione del programma

• Gli heap overflows sono invece sfruttati per manipolare

le funzioni che gestiscono la memoria dell’heap al fine di eseguire codice arbitrario

Esempio di Codice C

#include <stdio.h> #include <stdlib.h> #include <string.h> int main(int argc, char *argv[ ]) { // Allocate two adjacent blocks on the heap char *buf = malloc(256); char *buf2 = malloc(16); // Does not check length of buffer before copying argument strcpy(buf, argv[1]); // Print the argument printf("Argument: %s\n", buf); // Free the blocks on the heap free(buf); free(buf2); return 1; }

Esempio 1/2

• La funzione malloc(), implementata dalle vecchie versioni del compilatore GNU (gcc), alloca blocchi di memoria sull’heap

• I blocchi sono mantenuti in una linked list, ogni blocco punta al blocco successivo e al precedente

• Quando un blocco è marcato come free, la routine unlink() aggiorna i puntatori dei blocchi ad esso adiacenti al fine di rimuoverlo dalla linked list

Esempio 2/2

• Un attacante può

– eseguire un overflow su un blocco

– sovrascrivere il blocco successivo modificando i suoi puntatori e marcandolo come free

– forzare la routine di unlink a scrivere l’indirizzo dello shellcode in una locazione di memoria che determinerà successivamente un salto verso il codice malevolo

Format String Attack

• printf: famiglia di funzioni C usate per gestire I/O (es: stampa a video di messaggi)

• formati stringa (format strings): stringa che denota come il messaggio dovrà essere stampato

// Stampa la variabile messaggio come una stringa

printf(“%s”,message)


• I formati stringa possono anche scrivere in memoria, ad esempio il formato “%n” specifica che la funzione print dovrebbe scrivere il numero di byte dell’output fin qui stampato sull’indirizzo di memoria del primo argomento della funzione

• Quando non viene definito alcun formato per la stringa, l’argomento in input alla funzione definisce il formato dell’output


• Se questo argomento è fornito dall’utente allora un attaccante può scrivere un input che utilizza formati stringa, incluso “%n”, per leggere e scrivere in zone di memoria arbitrarie – ad esempio è possibile sovrascrivere l’indirizzo di ritorno

della funzione e avviare un attacco di tipo return-to-libc

– più semplicemente è possibile far crashare il programma (attacco DOS)

• Contromisura: fornire un formato stringa (es: “%s”)

Esempio di Codice C

//CODICE INSICURO

#include <stdio.h>


{

printf("Your argument is:\n");

// Does not specify a format string, allowing the user to supply one

printf(argv[1]);

}

//CODICE SICURO

#include <stdio.h>


{

printf("Your argument is:\n");

// Supplies a format string

printf("%s",argv[1]);

}

Race Conditions

• Una race condition è una situazione in cui il comportamento del programma è (involontariamente) dipendente dalla tempistica in cui si verificano certi eventi

• Un classico esempio fa uso funzioni C access() e open() – la funzione open() apre il file specificato utilizzando l’userID effettivo

(piuttosto che l’userID reale) del processo chiamante per verificarne i permessi

– in altre parole, se un programma setuid di proprietà dell'utente root è lanciato da un utente normale, il programma può chiamare con successo open() sui file che solo l'utente root ha il permesso di accedere

– la funzione access() controlla se l'utente reale (in questo caso l'utente che esegue il programma) ha permesso di accedere al file specificato

Esempio 1/6

• Supponiamo che un semplice programma: – richiede il nome di un file come argomento – controlla se l'utente che esegue il programma ha il

permesso di aprire il file – in caso affermativo legge i primi caratteri del file e li

stampa

• C'è una race condition in questa implementazione: – vi è un piccolissimo ritardo tra le chiamate access() e

open() – un utente malintenzionato potrebbe sfruttare questo

piccolo ritardo, modificando il file in questione tra le due chiamate

Esempio 2/6

#include <stdio.h>

#include <string.h>

#include <stdlib.h>


#include <fcntl.h>


{

int file;

char buf[1024];

memset(buf, 0, 1024);

if(argc < 2) {

printf("Usage: printer [filename]\n");

exit-1);

}

if(access(argv[1], R_OK) != 0) {

printf("Cannot access file.\n");

exit(-1);

}

file = open(argv[1], O_RDONLY);

read(file, buf, 1023);

close(file);

printf("%s\n", buf);

return 0;

}

Esempio 3/6

• Ad esempio, supponiamo che l'attaccante richieda /home/joe/dummy come argomento, un file di testo innocente che il malintenzionato può accedere

• Dopo che la chiamata access() restituisce 0, indicando che l’utente dispone dell'autorizzazione per accedere al file, l'utente malintenzionato può sostituire rapidamente /home/joe/dummy con un link simbolico a un file di cui non ha l'autorizzazione in lettura, come /etc/passwd

• Successivamente, il programma chiamerà open() sul link simbolico, che avrà successo perché il programma setuid ha come proprietario root

Esempio 4/6

• Si noti che questo tipo di attacco non potrebbe essere fatto manualmente – la differenza di tempo tra due chiamate di funzione è

abbastanza piccolo che nessun essere umano sarebbe in grado di modificare il file abbastanza velocemente!

• E’ invece possibile avere un programma in esecuzione in background che scambia più volte i due file, ed esegue il programma vulnerabile finché lo scambio non siverifica esattamente tra le due istruzioni open() e access()

Time of Check/Time of Use Problem

• In generale, questo tipo di vulnerabilità è conosciuto come Time of Check/Time of Use (TOCTOU) problem

• Ogni volta che un programma controlla la validità e la le autorizzazioni per un oggetto, sia esso un file o di qualche altra proprietà, prima di eseguire un'azione su tale oggetto, occorre fare attenzione che queste due operazioni siano eseguite atomicamente (dovrebbero essere eseguite come una operazione unica) – in caso contrario, l'oggetto può essere modificato tra il

momento in cui viene controllato e il tempo viene utilizzato

Esempio 5/6

• Per rendere sicuro il codice dell’esempio la chiamata di access() dovrebbe essere completamente evitata

• Il programma dovrebbe invece ritirare i propri privilegi usando seteuid () prima di chiamare open() – In questo modo, se l'utente che esegue il programma

non ha il permesso di aprire il file specificato, la chiamata open() fallirà

Esempio 6/6

#include <stdio.h>

#include <string.h>

#include <stdlib.h>


#include <fcntl.h>


{

int file;

char buf[1024];

uid t uid, euid;

memset(buf, 0, 1024);

if(argc < 2) {

printf("Usage: printer [filename]\n");

exit(-1);

}

euid = geteuid();

uid = getuid();

/* Drop privileges */

seteuid(uid);

file = open(argv[1], O RDONLY);

read(file, buf, 1023);

close(file);

/* Restore privileges */

seteuid(euid);

printf("%s\n", buf);

return 0;

}

Memoria Virtuale

• Teoricamente ogni address space dovrebbe essere allocato in una regione di memoria continua – il codice macchina deve poter eseguire dei salti del tipo

“salta in avanti di 10 istruzioni”

– gli array sono indicizzati come blocchi di memoria adiacenti tra loro

• In realtà questo approccio risulta essere inefficiente e impraticabile – in alcuni casi la memoria totale potrebbe non essere

nemmeno sufficiente per ospitare tutti gli address space

Principi di Località

• Durante la loro esecuzione i programmi godono di due importanti proprietà:

– Località temporale: se un elemento x viene referenziato all’istante t, la probabilità che x venga referenziato anche all’istante t+t’cresce al tendere di t’0

– Località spaziale: se un elemento x in posizione s viene referenziato all’istante t, la probabilità che venga referenziato un elemento x’ in posizione s’, con |s-s’| ≤ Δ, all’istante t+t’cresce al tendere di t’0

Principi di Località

• I principi di località suggeriscono un importante accorgimento nella gestione della memoria: non è necessario caricare un programma interamente in memoria per poterlo eseguire, è sufficiente caricarlo località per località – memoria cache: velocizza esecuzione del

programma

– memoria virtuale: ottimizza la gestione della memoria

Memoria Virtuale

• Meccanismo di mappatura di indirizzi di memoria virtuali (virtual memory) in indirizzi reali – I programmi continuano a vedere un regione di

memoria contigua

• Un componente HW chiamato MMU (Memory Management Unit) si occupa di tradurre gli indirizzi virtuali in indirizzi fisici

Memoria Virtuale

Paging

• Attraverso questo meccanismo è inoltre possibile mettere a disposizione dei programmi una quantità di memoria superiore alla reale capacità fisica del calcolatore – è infatti possibile sfruttare porzioni di memoria secondaria su

cui memorizzare dati attualmente non utilizzati dai processi (es: processi idle)

– un’area della memoria primaria non acceduta per un certo periodo di tempo può essere spostata sulla memoria secondaria (paged out)

– se un processo richiama un indirizzo di memoria inattivo (page fault) il sistema provvede a recuperare il blocco di memoria richiesto dalla memoria secondaria e, possibilmente, a sostituirlo con un’altro

Page Fault

Indirizzo non in memoria:

PAGE FAULT

Paging Supervisor:

1 Richiama il blocco di memoria dalla memoria secondaria e lo carica sulla

memoria primaria

2 Aggiorna il mapping degli indirizzi fisici e virtuali

3 tenta di paginare una zona di memoria non utilizzata recentemente

Processo:

richiesta di un indirizzo di memoria

Linux e Windows

• In Linux è solitamente necessario destinare un’intera partizione logica del disco fisso per la memoria virtuale, chiamata swap partition

• Windows memorizza i dati relativi alla memoria virtuale in un file, chiamato page file (C:\pagefile.sys)

Attacco alla Memoria Virtuale

• Un attaccante può: – spengere brutalmente un calcolatore

– effettuare il boot di un altro OS (attraverso un media esterno)

– ricostruire la memoria virtuale accedendo ai relativi file

• Possibile contromisura: crittografare i dati memorizzati su hard disk

Fonti

• Introduction to Computer Security, Michael T. Goodrich and Roberto Tamassia, Addison Wesley, 2011

• www.cs.brown.edu/courses/csci1660/

• www.wikipedia.org

• Smashing the Stack for Fun and Profit, Aleph One, Phrack Magazine Vol. 49(14), 1996

http://www.cs.brown.edu/courses/csci1660/

http://www.wikipedia.org/

Sicurezza dei programmi

Introduzione

• I programmi costituiscono gran parte di un sistema informativo

• La protezione dei programmi è perciò al cuore della sicurezza informatica

• Due domande fondamentali:

– Come è possibile prevenire la presenza di difetti in un programma?

– Come è possibile proteggere le risorse informatiche da programmi che contengono difetti?

PROGRAMMI SICURI Sicurezza dei programmi

Cos’è un programma?

• Un insieme di istruzioni per il calcolatore.

• Esempi:

– Il sistema operativo

– I driver delle periferiche

– L’infrastruttura di rete

– I sistemi di gestione delle basi di dati (DBMS)

– Gli applicativi (il browser Web, programmi di videoscrittura, programmi di calcolo e simulazione, …)

– …

Cos’è un programma sicuro?

• Un programma è sicuro se abbiamo “un certo grado di fiducia nel fatto che il programma garantisca la riservatezza, l’integrità e la disponibilità che ci si aspetta”

• Valutare la sicurezza del programma è un procedimento analogo a valutarne la qualità “in generale”.

Terminologia: difetto e malfunzionamento

• Innanzi tutto è importante definire una terminologia condivisa.

– Difetto (fault): passaggio, comando, o definizione dei dati non corretto in un programma per computer.

– Malfunzionamento: deviazione dal comportamento richiesto del sistema.

– Quindi un difetto rappresenta il punto di vista interno, quello dello sviluppatore: è la causa.

Terminologia: difetto e malfunzionamento

– Il malfunzionamento rappresenta il punto di vista esterno (utente): è l’effetto del difetto.

– Non sempre un difetto si traduce in (uno o più) malfunzionamenti.

• Esempio: il codice difettoso non viene mai eseguito.

La qualità dipende dal punto di vista

– L’importanza delle caratteristiche di qualità (sicurezza) dipende da chi sta analizzando il software.

• È possibile avere divergenze nelle accezioni.

– Il programma è sicuro perché è necessario troppo tempo per la violazione dei controlli di protezione;

– Il programma è sicuro perché è stato eseguito per un certo periodo di tempo senza malfunzionamenti;

– Atteggiamento estremista: qualsiasi potenziale errore nel raggiungimento dei requisiti di sicurezza rende il codice insicuro.

La qualità dipende dal punto di vista

• È possibile avere divergenze negli obiettivi:

– Punto di vista del responsabile del progetto: il sistema è sicuro se soddisfa i requisiti di sicurezza, indipendentemente dal fatto che questi siano efficaci.

• Esempio: tutte le macchine dotate di lucchetto, ma la chiave è la stessa per tutti i lucchetti!

La sicurezza è complessa

• Non esistono tecniche per eliminare o gestire tutte le falle di sicurezza

• La sicurezza è per sua natura una questione complessa, che spesso entra in conflitto con usabilità e prestazioni

La sicurezza è complessa: motivazioni

1. Complessità del sistema:

– I requisiti vengono definiti in termini di “cosa fare”

– La sicurezza riguarda la prevenzione: necessario definire “cosa non fare”

– È quasi impossibile definire tutti i requisiti

• Anche se fosse possibile definire tutti i requisiti, in un sistema grande e articolato le interazioni tra i vari moduli accadono in un numero di modi che non è gestibile.

• L’esame e la verifica vengono allora fatti per i casi più probabili, non esaustivamente.

La sicurezza è complessa: motivazioni

– In sintesi la dimensione e la complessità del sistema software impediscono una prevenzione e mediazione completa delle falle.

2. Evoluzione tecniche di programmazione: la programmazione e le tecniche di ingegneria del software cambiano e si evolvono molto più rapidamente delle tecniche di sicurezza informatica.

Non tutto è perduto

• La sicurezza informatica ha molto da offrire ai programmi.

• Comprendendo cosa può andare storto e come proteggersi da tale evento, possiamo ideare strumenti e tecniche di protezione.

ERRORI DI PROGRAMMA NON MALEVOLI

Sicurezza dei programmi

Errare humanum est

– I programmatori e gli analisti commettono degli errori, spesso né intenzionali, né malevoli.

– Molti di essi provocano malfunzionamenti, ma non portano a vulnerabilità serie.

– Alcune classi di errori hanno costituito comunque un grosso problema per la sicurezza e continueranno a costituirlo:

a) Buffer overflow

b) Mediazione incompleta

c) Errori dovuto allo scarto fra tempo di controllo e tempo di utilizzo

BUFFER OVERFLOW Errori di programma non malevoli

Buffer overflow

• Un buffer (o array o stringa) è uno spazio di memoria in cui possono essere memorizzati dei dati.

• La memoria è finita, quindi la capacità del buffer è finita.

• In molti linguaggi è necessario dichiarare la dimensione del buffer in modo che il compilatore possa riservare la memoria necessaria

Buffer overflow: esempio 1

• L’indice si trova fuori dai limiti.

• Il compilatore può rilevare il difetto in fase di compilazione

– gcc non lo rileva

– Java lo rileva

• Ciò nonostante …

int main()

{

char sample[10];

sample[10]='B';

return 0;

}

Buffer overflow: esempio 2

• L’indice si trova fuori dai limiti. • Questo difetto può essere rilevato

solo in fase di esecuzione (runtime). • L’ambiente di esecuzione potrebbe

rilevare l’errore ed impedire l’esecuzione della riga errata: – gcc non lo rileva – Java lo rileva

• Il modulo di rilevazione dell’errore utilizza risorse (memoria e tempo) per proteggersi da un problema che capita abbastanza di rado.

• In alcuni caso potremmo non permetterci il dispendio aggiuntivo di risorse (ad esempio, programmi in tempo reale).

• Anche se volessimo spendere risorse per questo controllo …

int main()

{

char sample[10];

int i;

for(i=0; i<11; i++)

sample[i]='B';

}

Buffer overflow: esempio 3 (1)

• Il codice di rilevazione limite di un array non può rilevare il seguente difetto.

int main()

{

char sample[] = "Hello

world!";

char* p;

int i;

p = sample;

for(i=0; i<40*1000; i++)

{

if(*p > 0)

putchar(*p);

p++;

}

}

Buffer overflow: esempio 3 (2)

• Posso potenzialmente leggere e scrivere da qualsiasi locazione di memoria!

• In realtà il sistema operativo non mi permette un accesso indiscriminato (Segmentation fault)

• Sistemi operativi “snelli” non effettuano il controllo

• In ogni caso ho ottenuto una serie di informazioni

Buffer overflow: implicazioni per la sicurezza

A A A A A A A A A B

Dati dell’utente

A A A A A A A A A B

Dati dell’utente Codice del programma utente

A A A A A A A A A B

Dati dell’utente Dati di sistema

A A A A A A A A A B

Dati dell’utente Codice del programma di sistema

• Supponendo che non venga eseguito un controllo, le implicazioni per la sicurezza potrebbero essere molteplici, a seconda delle informazioni che seguono lo spazio allocato.

Buffer overflow nel passaggio di parametri

– Se i parametri per la routine vengono passati da input, è possibile provocare un buffer overflow.

– Esempio:

http://www.somesite.com/subpage/userinput.asp?

parm1=(808)555-1212&parm2=2009Jan17

– Cosa accade se il numero di telefono fornito ha 1000 caratteri? Crash del programma?

– È possibile sfruttare il crash?

Buffer overflow: riassunto

– È possibile rilevarlo/prevenirlo attraverso il compilatore o l’ambiente di esecuzione (Java).

– I moduli di rilevazione e prevenzione hanno un costo (memoria, tempo).

– Se non rilevato/prevenuto può permettere la scrittura di dati a piacimento!

– I buffer overflow esistono da quando sono stati creati i linguaggi di programmazione di alto livello con gli array.

Buffer overflow: riassunto

– Per lungo tempo hanno rappresentato solo un picollo fastidio per utenti e programmatori, una causa di errori e di crash di sistema.

– Abbastanza di recente, però, gli aggressori li hanno utilizzati come veicoli per provocare prima un crash del sistema e poi un malfunzionamento controllato con serie implicazioni per la sicurezza.

MEDIAZIONE INCOMPLETA Errori di programma non malevoli

Mediazione incompleta

– Riprendiamo l’esempio del sito Web

• http://www.somesite.com/subpage/userinput.asp?

parm1=(808)555-1212&parm2=2009Jan17

– Cosa accadrebbe se fosse specificato 1800Jan01?

– O 1800Feb30?

– O 2048 Min32?

Mediazione incompleta

– Potrei anticipare il problema del buffer overflow, inserendo dei controlli lato client (il browser)

– La data potrebbe essere specificata solo selezionando controlli predefiniti

– Ciò non impedisce di realizzare una richiesta HTTP manuale, digitando l’indirizzo direttamente nel browser.

– In questo caso si dice che i valori dei dati non sono completamente mediati: i dati critici si trovano in una condizione esposta, non controllata.

Implicazioni per la sicurezza

– Per meglio comprendere le implicazioni per la sicurezza dovute alla mediazione incompleta, consideriamo il seguente esempio.

– Supponiamo che la richiesta HTTP per la conferma e pagamento di un ordine sia la seguente:

– http://www.things.com/order.asp?part=555&

price=10&quantity=5&total=50

– Normalmente l’utente utilizza il sito di e-commerce dell’azienda e non genera una richiesta manuale.

Implicazioni per la sicurezza

– Ciò però non impedisce di confezionare una richiesta malevola come:

– http://www.things.com/order.asp?part=5

55&price=10&quantity=5&total=20

– L’esempio è realmente accaduto!

– Come si risolve?

– Non è necessario avere il prezzo unitario, né il totale: è sufficiente avere il codice del prodotto e la quantità!

SCARTO FRA TEMPO DI CONTROLLO E TEMPO DI UTILIZZO

Errori di programma non malevoli

Falla TOCTTOU

– Per migliorare l’efficienza, i processori e i sistemi operativi moderni possono cambiare l’ordine di esecuzione di istruzioni e procedure.

• Ad esempio, l’esecuzione di istruzioni consecutive di una procedura possono essere inframezzate da istruzioni di altre procedure (multi-tasking).

– La falla Time-Of-Check To Time-Of-Use (TOCTTOU, “tock too”) è dovuta allo scarto di tempo tra la verifica dell’autorizzazione a compiere un’azione e l’esecuzione dell’azione stessa.

Falla TOCTTOU

– Se i dati di autorizzazione non vengono utilizzati direttamente e, nell’attesa di essere utilizzati, sono disponibili per la modifica, allora si verifica la falla.

– Esempio: una persona compra una statua che costa 100€ 1. L’acquirente estrae 5 banconote da 20€, le conta davanti al

venditore e le lascia sul tavolo.

2. Il venditore si gira e prende la statua.

3. L’acquirente riprende una banconota mentre il venditore è girato.

4. Il venditore si gira, prende il denaro e porge la statua all’acquirente, che esce dal negozio.

TOCTTOU: esempi

• Esempio: accesso ad un file

1. L’utente X vuole leggere il file file_di_X

2. Viene confezionata una richiesta di accesso [X, file_di_X, lettura, ?] e sottoposta a controllo

3. L’accesso viene permesso [X, file_di_X, lettura, OK]

4. Prima di essere utilizzata, la richiesta di accesso viene modificata [X, file_nascosto, modifica, OK]

5. La richiesta di accesso viene utilizzata nella versione modificata, permettendo operazioni negate.

Come evitarla?

– Per evitare la falla sarebbe necessario utilizzare i dati di permesso immediatamente o evitare di esporli durante l’attesa dell’utilizzo.

– Se ciò non fosse possibile (multi-tasking), si potrebbe aggiungere un checksum ai dati di permesso, che l’entità emittente possa verificare in modo da poterne rilevare la modifica.

Combinazione di falle

– Ognuna delle tre falle precedenti è abbastanza grave singolarmente.

– Tuttavia l’aggressore intelligente utilizza le falle come mattoni per la costruzione di un attacco complesso.

– Per questo motivo occorre conoscere e proteggersi anche dalle falle più semplici.

– Le falle di programma all’apparenza innocue possono essere sfruttate da aggressori malevoli per introdurre codice dannoso! (virus)

VIRUS E ALTRO CODICE MALEVOLO Sicurezza dei programmi

Attività silente

– La maggior parte del lavoro svolta da un programma è invisibile agli utenti. Ad esempio: • Conoscete la forma in cui viene memorizzato un

documento?

• Quali file vengo creati e modificati da un elaboratore di testi quando create un documento?

– Per questa ragione, poiché l’utente non vede direttamente i dati utilizzati dal computer, gli eventuali aggressori informatici possono utilizzare programmi come veicoli per la modifica di dati o di altri programmi.

Come avviene l’”infezione”?

– Quando si installa un pacchetto software

• elaboratore di testi, plug-in da Internet, giochi, …

– si esegue un comando generalmente chiamato INSTALL o SETUP.

– Da qui in poi il programma di installazione prende il controllo

• crea, modifica, elimina e rinomina i file che gli sono necessari.

– A parte la (generica) documentazione di installazione fornita, l’utente non ha idea di quali “regalini” abbia ricevuto in seguito all’installazione.

Come avviene l’”infezione”?

– Si spera che siano tutti buoni, ma tra di essi è possibile nascondere del codice malevolo che viene installato senza che l’utente ne abbia percezione.

– È importante conoscere la fonte del software che installiamo!

Cosa può fare il codice malevolo?

– Il codice malevolo è di fatto un programma e può quindi fare qualsiasi cosa è in grado di fare un programma • Scrivere un messaggio sullo schermo

• Terminare l’esecuzione di un programma

• Modificare/cancellare un file archiviato

• …

– Può anche insediarsi e rimanere inattivo fino a che non si verifica una condizione di innesco: • Un orario o data predefinita

• Un evento (per esempio, l’esecuzione di un programma)

• Un conteggio

• Una combinazione di eventi

Cosa può fare il codice malevolo?

– Il codice malevolo inoltre viene eseguito sotto l’autorità dell’utente corrente:

• Può entrare in contatto con tutto ciò con cui è a contatto l’utente e nello stesso modo.

• Può quindi aggiungere, modificare o eliminare qualsiasi dato dell’utente, senza che sia necessario il suo esplicito consenso (una volta avviato).

Da quanto tempo esiste il codice malevolo?

– I riferimenti ai comportamenti dei virus risalgono almeno al 1970

• Lo studio di Ware nel 1970 (pubblicato nel 1979) e quello di Anderson per l’aeronautica militare statunitense descrivono in maniera ancora accurata minacce, vulnerabilità e falle di protezione dei programmi.

– La novità oggigiorno è il numero di istanze distinte e di copie di virus che sono comparse e scomparse, nonché la velocità con cui nasce il codice per il loro sfruttamento.

“Zero day”

• Il rilascio di una patch di una vulnerabilità avviene secondo le seguenti fasi:

1. Una nuova vulnerabilità viene scoperta.

2. Il produttore viene a conoscenza della vulnerabilità.

3. Viene sviluppata la prova di concetto per dimostrare la vulnerabilità in una situazione controllata.

4. Il produttore sviluppa e distribuisce un rimedio (patch).

5. Gli utenti implementano la difesa.

“Zero day”

– Qualcuno può sferrare un attacco effettivo estendendo la prova di concetto o la definizione della vulnerabilità.

– Fintanto che gli utenti implementano la difesa prima dell’attacco effettivo, non si registra alcun danno.

– Viene definito “giorno zero” la data in cui il produttore viene a conoscenza della vulnerabilità.

“Zero day”

– Un attacco che avvenga prima che il produttore conosca la vulnerabilità è detto sfruttamento del giorno zero: “zero day attack”.

– In senso più generale, un “zero day attack” avviene prima della disponibilità della patch relativa.

TIPI DI CODICE MALEVOLO Virus e altro codice malevolo

Tipi di codice malevolo

– Virus: si unisce ad un programma e propaga copia di se stesso in altri programmi. • transitorio: eseguito solamente in associazione al

programma ospite.

• residente: rimane sempre attivo e può essere attivato come programma autonomo, dopo il termine del programma ospite.

– Cavallo di Troia: codice che oltre al suo effetto primario presenta un secondo effetto malevolo non evidente. • esempio: script di login che, oltre alle operazioni standard,

conserva una copia di nome utente e password per un utilizzo successivo.


– Bomba logica: codice malevolo che scatta al verifica di una particolare condizione.

– Trapdoor o backdoor: caratteristica di un programma per accesso diverso dalla chiamata diretta.

• esempio: programma bancario che, digitando il numero 990099 sul tastierino, mostra la registrazione delle operazioni effettuate sulla macchina.

– Worm: come il virus, ma si diffonde solo attraverso la rete, mentre il virus può utilizzare qualsiasi supporto. Il worm si diffonde come programma autonomo.


– Coniglio (rabbit): virus o worm che si replica automaticamente senza limiti per esaurire le risorse.

• Nel seguito utilizzeremo “virus” come termine generico per intendere qualsiasi codice malevolo.

Come si diffondono i virus?

– Un virus eseguibile semplicemente residente su un disco non produce effetti.

– Affinché un virus inizi il suo lavoro malevolo e si diffonda deve essere attivato attraverso la sua esecuzione.

– Il virus viene quindi associato ad un programma “normale” (il programma ospite) in modo tale da essere eseguito quando il programma ospite è lanciato. • Esempio: virus nel CD di installazione di un programma:

• L’utente avvia il programma SETUP.EXE residente sul CD;


• Da questo momento l’infezione prosegue autonomamente.

– Per avviare il processo di infezione è necessario l’intervento umano:

• Un essere umano inserisce il virus nel supporto di distribuzione;

• Un essere umano avvia l’esecuzione del programma a cui è associato il virus.


– Un mezzo comune per la diffusione del virus è l’allegato di posta elettronica.

• In questo attacco l’aggressore deve convincere il destinatario del messaggio ad aprire l’allegato. Una volta aperto, l’allegato infetta il computer.

• Alcuni gestori di posta elettronica, nel tentativo di “aiutare” l’utente, aprivano direttamente gli allegati alla sola lettura del messaggio, creando invece una falla di sicurezza.

Dove si posizionano nel programma ospite? Virus accodati

• Il virus inserisce copia di sé stesso prima della prima istruzione del programma ospite

• All’avvio del programma originale tutte le istruzioni del virus vengono eseguite per prime. Poi l’esecuzione prosegue normalmente col programma originale.

• Semplice ed efficace: – l’autore non deve sapere nulla del

programma ospite – Il programma ospite spesso serve

solo da vettore per l’infezione – L’utente non percepisce la

presenza del virus (il programma originale funziona normalmente)

Codice virale

Programma originale

Virus che circondano il programma

• Il virus viene eseguito prima e dopo il programma originale.

• Questo permette al virus di intervenire sull’output del programma originale.

• Ad esempio, un virus che infetta il programma che costruisce l’elenco dei file su disco potrebbe intercettare l’output in modo da eliminare i riferimenti a se stesso e quindi non comparire all’utente.

Codice virale

Parte (a)

Programma originale

Codice virale

Parte (b)

Virus integrati e sostituzioni

• Il virus si integra nel codice originale del programma ospite.

• In questo modo diventa più difficile da rilevare, ma l’autore del virus deve conoscere l’esatta struttura del programma ospite.

Codice virale Programma

originale

Programma modificato + =

Virus di documento

– Si trova all’interno di un documento formattato (cioè con una struttura) come:

• Documento scritto (Word, Open Office Writer, …)

• Un database

• Una presentazione

– Questi documenti sono infatti altamente strutturati e contengono:

• dati (parole o numeri) e

• comandi (formule, controlli di formattazione, collegamenti, …)

Virus di documento

– I comandi sono parte di un ricco linguaggio di programmazione che comprende macro, variabili e procedure, accesso ai file e persino chiamate al sistema.

– Sebbene quindi il virus di documento non sia codice direttamente eseguibile, sfrutta l’ambiente fornito dal programma di lettura del file per eseguire operazioni malevole.

Modifica dei puntatori

• Negli esempi precedenti il virus si “unisce” ad un programma legittimo (modificandone il file)

• Un virus può anche modificare i puntatori nella tabella dei file per essere invocato al posto del programma legittimo

LUOGHI IN CUI PUÒ RISIEDERE UN VIRUS

Virus e altro codice malevolo

Introduzione

– Dal punto di vista del suo creatore, un virus dovrebbe

• Essere difficile da rilevare;

• Non essere distrutto o disattivato facilmente;

• Diffondersi in modo ampio;

• Reinfettare il programma in cui si trova o altri programmi;

• Semplice da creare;

• Indipendente dalla macchina o dal sistema operativo.

– Pochi virus soddisfano tutti questi criteri.

Introduzione

– Inizialmente la sfida per l’autore del virus era scrivere un codice che sarebbe stato eseguito ripetutamente per garantirne la diffusione.

– Ora è sufficiente un esecuzione singola per garantire la diffusione (i computer sono sempre connessi). • il virus spesso giunge come allegato di posta elettronica che

l’utente deve eseguire

– Esaminiamo i luoghi in cui è possibile che un virus risieda (dopo l’installazione) per procedere con l’infezione.

Virus del settore di avvio

• Il sistema operativo è un software memorizzato su disco.

• All’avvio: 1. il firmware copia (da una posizione

fissa del disco, detta “settore di avvio”) il bootstrap loader in memoria;

2. Il firmware passa il controllo al bootstrap loader;

3. Il bootstrap loader continua il caricamento del sistema operativo.

• Il settore di avvio dispone di 512 byte. Per permettere bootstrap loader più grandi è possibile il “concatenamento”.

• Se il virus riesce ad inserirsi nella catena, la sua esecuzione è garantita ad ogni avvio.

Bootstrap loader

Inizializzazione del sistema

Codice virale

Inizializzazione del sistema

Bootstrap loader

Prima dell’infezione

Dopo l’infezione

Virus del settore di avvio: (s)vantaggi

• Il virus acquisisce il controllo molto presto, prima che vengano attivati gli strumenti di rilevazione.

• I file nell’area di avvio sono parti fondamentali del sistema operativo:

– Il sistema operativo li nasconde e ne impedisce l’eliminazione: il virus risulta difficile da rilevare e da eliminare. Tipicamente è richiesto un avvio della macchina tramite “disco pulito”.

Virus residenti in memoria

– Per ridurre il tempo di esecuzione di un programma, alcune parti del sistema operativo o programmi utente rimangono in memoria, così da non richiedere lettura da disco e caricamento in memoria.

– Questo tipo di codice è definito “codice residente”.

– Esempi di codice residente:

• Routine per l’interpretazione dei tasti della tastiera;

• Codice di gestione delle eccezioni dei programmi;

• Timer.

Virus residenti in memoria

– Allegando un virus ad un codice residente, questo sarà eseguito più volte.

• Esempio: un virus associato ad un codice residente può essere eseguito più volte e controllare i dischi nelle unità rimovibili, provvedendo all’infezione.

– In maniera analoga un virus può modificare la tabella dei programmi del sistema operativo, ad esempio la lista dei programmi da eseguire all’avvio.

Altri luoghi

– Abbiamo parlato della possibilità di eseguire operazioni attraverso macro. Alcuni programmi hanno delle “Macro di avvio” che permettono, ad esempio, l’esecuzione di operazioni ricorrenti interessanti per l’utente.

– Un luogo in cui un virus può risiedere e quindi la macro di avvio.

– Le librerie di codice (ad esempio le Dynamic Linked Library, DLL) sono utilizzate da numerosi programmi e vengono eseguite da ognuno di essi.

– Un virus che infetta una libreria si garantisce numerose esecuzioni.

DEFINIZIONE DEI VIRUS Virus e altro codice malevolo

Introduzione

• Un virus non può essere completamente invisibile: – Il codice deve essere memorizzato da qualche parte e deve

trovarsi in memoria per poter essere eseguito;

– Il virus viene eseguito in modo particolare, con particolari metodi per la sua diffusione.

• Ognuna di queste caratteristiche porta ad uno schema eloquente: la definizione o firma.

• La definizione del virus viene utilizzata dagli analizzatori (virus scanner) per rintracciarlo.

• Il virus viene rilevato solo con la relativa definizione: ecco l’importanza dell’aggiornamento delle definizioni.

Schemi di memorizzazione

• La maggior parte dei virus si associa a programmi archiviati su disco.

• Il virus allegato è invariabile, perciò l’inizio del codice è una definizione rilevabile.

• Un altro parametro da valutare può essere la dimensione del file a cui il virus si associa. Se il programma ospite non viene modificato internamente, la dimensione complessiva aumenta.

IF (--)

JUMP

Programma originale

Codice del virus allegato

Programma originale

Modulo del virus

separato

Schemi di memorizzazione

• Per non aumentare la dimensione è possibile sostituire delle parti del programma, ma in questo caso il comportamento dell’ospite sarebbe modificato dal virus.

• Ancora, l’analizzatore di virus può utilizzare un codice o una checksum per rilevare le modifiche a un file.

• Può anche cercare schemi sospetti – Esempio: rilevare un’istruzione

JUMP come prima istruzione di un programma di sistema.

IF (--)

JUMP

Programma originale

Codice del virus allegato

Programma originale

Modulo del virus

separato

Virus polimorfico

– Per rendere difficoltoso il rilevamento, l’autore del virus può far sì che lo schema di memorizzazione cambi.

– In questo caso si parla di virus polimorfico.

• Seguono alcune tecniche che permettono di rendere un virus polimorfico: – Inserire istruzioni che non producono alcuna

operazione (no-ops), come: • Aggiunta di uno 0 ad un numero;

• Confronto di un numero con se stesso;

• Salto all’istruzione successiva.

Virus polimorfico

– Cambiare la posizione delle parti di codice rispetto a quelle dei dati. • Supponendo che un codice malevolo sia composto da 100

byte di programma e 50 byte di dati, varianti del virus polimorfico potrebbero essere:

• 10 byte di programma, seguiti da 50 byte di dati, seguiti da i restanti 90 byte di programma;

– Crittografare parte del codice (virus crittografici). La chiave e la routine di decrittazione devono essere in chiaro, per poter riottenere il codice in chiaro. • Non appena il virus viene eseguito, questi effettua la

decifratura ottenendo la parte restante del suo codice eseguibile

PREVENIRE L’INFEZIONE VIRALE Virus e altro codice malevolo

Codice eseguibile da fonte infetta

• Un modo per prevenire l’infezione consiste nell’evitare di ricevere del codice eseguibile da una fonte infetta.

• È possibile riconoscere cosa sia codice eseguibile?

• È possibile rilevare quale sia una fonte infetta?

Riconoscere codice eseguibile (1)

– Individuare chiaramente quale sia codice eseguibile non è semplice.

– Oggi i file sono più complessi e anche quelli non direttamente eseguibili (.exe) possono contenere del codice eseguibile (macro). • Documenti di testo;

• Fogli elettronici;

• Presentazioni;

• …

– Le applicazioni che utilizzano questi file possono cercare di aiutare l’utente invocando automaticamente il codice eseguibile, senza esplicito consenso.

Riconoscere codice eseguibile (1)

• Ad esempio, i gestori della posta elettronica (Thunderbird, Outlook, Outlook Express, …) potevano essere impostati per aprire automaticamente gli allegati o il codice incorporato,

• in modo che i messaggi di posta elettronica visualizzino, per esempio, degli orsetti animati che ballano.

• Questi falle sono eliminate nelle ultime versioni.

Riconoscere fonti infette

– Poiché non è possibile sapere quali fonti siano infette, si dovrebbe presumere che qualsiasi fonte esterna sia infetta.

– Non è però possibile tagliare tutti i contatti con il mondo esterno.

– Kephart et al. osservano che gli sforzi dei singoli per mantenere i loro computer privi di virus porta alla creazione di comunità non infette.

Riconoscere fonti infette

– La trasmissione è contenuta non a causa del limitato contatto del singolo col mondo esterno, ma grazie al limitato contatto con persone esterne alla comunità.

– I governi, per i segreti militari o diplomatici, spesso sfruttano comunità di rete disconnesse.

– In sintesi, il segreto è nella scelta prudente della comunità.

– Tuttavia con la diffusione di Internet questa possibilità è sempre più difficile.

Per costruire una comunità sicura si dovrebbe…

• Usare software commerciale acquistato da rivenditori solidi ed affidabili.

• Provare tutto il nuovo software su un computer isolato.

• Aprire gli allegati solo quando si è certi che siano sicuri.

• Creare un’immagine di ripristino del sistema e archiviarla in un luogo sicuro.

• Creare copia di backup dei file di sistema eseguibili.

• Utilizzare regolarmente i rilevatori di virus e tenerli regolarmente aggiornati.

Verità e malintesi sui virus (1)

– I virus possono infettare solo i sistemi operativi Microsoft.

– Falso. • I sistemi Microsoft sono molto popolari, esistono

pertanto più persone che scrivono software per questi sistemi.

• Di conseguenza questi sistemi sono spesso l’obiettivo prescelto dagli autori di virus.

• In realtà qualsiasi dispositivo contenente codice informatico (computer, palmari, cellulari, automobili, …) e che sia connesso con altri dispositivi, può essere infettato da virus.


– I virus possono modificare i file nascosti e di sola lettura.

– Vero.

• L’occultamento o l’impostazione di un file in sola lettura sono operazioni eseguite via software, attraverso un sistema a strati: intervenendo a livello degli strati inferiori è possibile aggirare questi ostacoli.


– I virus possono apparire solo nei file di dati, oppure solo in documenti di Word, oppure solo nei programmi.

– Falso.

• Che cosa sono i dati? Che cos’è un file eseguibile?

• La distinzioni non è sempre chiara.

• In ogni caso è sempre necessario che ci sia un’esecuzione. La stringa di bit, che sia essa stessa direttamente un comando, o che agisca attraverso l’ambiente di esecuzione di un’applicazione, deve scatenare l’esecuzione di operazioni.


– I virus si diffondono solo sui dischi o solo tramite email.

– Falso.

– Qualsiasi mezzo che metta in contatto due dispositivi è un vettore di virus:

• Un pagina Web che permette lo scaricamento di file;

• Un archivio su server FTP;

• Reti di condivisione di file;

• …


– I virus non possono rimanere in memoria dopo un completo spegnimento e riavvio del sistema.

– Vero

• La memoria è volatile: non mantiene informazione senza alimentazione.

• Tuttavia il virus può essere riavviato automaticamente ad ogni avvio (ad esempio, virus del settore di avvio).

• Nota: l’ibernazione e la sospensione non sono riavvii del sistema. Il contenuto della memoria viene salvato su disco.


– I virus non possono infettare l’hardware.

– Vero.

• Il virus presuppone la possibilità di modifica (non volontaria dell’utente) di codice eseguibile.

• Se l’hardware non ha codice modificabile oppure non è possibile modificarlo, l’infezione non può aver luogo.

• Un virus (software) potrebbe però danneggiare il dispositivo hardware se il driver permette operazioni (potenzialmente) dannose.

ESEMPI DI CODICE MALEVOLO Sicurezza dei programmi

IL VIRUS BRAIN Esempi di codice malevolo

Introduzione

– È uno dei primi virus ad essere comparsi.

– Deve il suo nome al fatto che modifica l’etichetta dei dischi attaccati in BRAIN.

– Sembra non avere effetti diversi dalla trasmissione

• era verosimilmente una prova di concetto …,

– tuttavia alcune varianti cancellano il contenuto del disco o distruggono la tabella di allocazione dei file.

Virus Brain – Cosa fa

– Cerca di diffondersi il più possibile.

1. Si posiziona nella memoria superiore.

2. Esegue una chiamata di sistema per reimpostare il limite della memoria superiore al di sotto di sé e quindi non essere disturbato.

3. Si appropria dell’indirizzo dell’interrupt 19 (lettura del disco), reimpostando l’indirizzo a se stesso.

4. Utilizza l’interrupt 6 (inutilizzato) per memorizzare l’indirizzo originale del 19.

Virus Brain – Cosa fa

– In questo modo il virus analizza tutte le chiamate di lettura dal disco, gestendo tutte quelle relative al settore di avvio.

– Per nascondersi restituisce il contenuto originale del settore di avvio del disco che ha provveduto a memorizzare in settori del disco contrassegnati come danneggiati.

– Altre chiamate al disco vanno al normale gestore della lettura, servito tramite l’interrupt 6.

Virus Brain – Come si diffonde

– Si posiziona nel settore di avvio e in altri sei settori del disco. 1. Contiene il codice di avvio originale;

2. Codice virale;

3. Codice virale;

4. Duplicato del settore 1;

5. Duplicato del settore 2;

6. Duplicato del settore 3.

– I settori vengono contrassegnati come danneggiati, in modo che il sistema operativo non li utilizzi • con le chiamate di basso livello è possibile obbligare l’unità a

leggere dai settori che il sistema operativo ha contrassegnato come danneggiati

Virus Brain – Come si diffonde

– Una volta stabilitosi in memoria, il virus intercetta le richieste di lettura del disco.

– A ogni lettura il virus legge il settore di avvio e cerca del quinto e nel sesto byte il valore esadecimale 1234.

• Se presente, deduce che il disco è infetto.

• Altrimenti provvede all’infezione.

IL WORM INTERNET Esempi di codice malevolo

Introduzione

• Il 2 novembre 1988 venne rilasciato su Internet un worm che provocò seri danni alla rete.

– Non solo molti computer furono infettati, ma quando la notizia si diffuse, molti altri sistemi non infetti disattivarono le proprie connessioni dalla rete per prevenire l’infezione.

Worm Internet – Obiettivi

• A giudicare dal codice, il worm era programmato per raggiungere tre obiettivi principali:

1. Determinare dove poteva diffondersi;

2. Diffondere la sua infezione;

3. Rimanere sconosciuto e introvabile.

Worm Internet – Effetti

– L’effetto principale è stato l’esaurimento delle risorse.

• Il worm avrebbe avuto il compito di determinare se un bersaglio fosse già stato infettato;

• in caso affermativo, il worm avrebbe negoziato in modo da terminare o l’infezione esistente o quella nuova.

• A causa di un difetto nel codice, molte nuove copie non terminarono.

• Come risultato una macchina infetta veniva presto gravata di molte copie del worm, tutte che tentavano incessantemente di diffondere l’infezione.

• Le prestazioni venivano fortemente degradate.

Worm Internet – Effetti

– Un secondo effetto è stata la disconnessione di molte macchine da Internet: • Quelle già infette, per non permettere la diffusione;

• Quelle non infette, per evitare che fossero infettate.

– Terzo effetto: isolamento e incapacità di eseguire il lavoro necessario. • La disconnessione non ha permesso l’esecuzione delle

normali attività è ha reso problematica la comunicazione per risolvere il problema.

– Ha provocato l’arresto o la disconnessione da Internet di circa 600 computer. • Diverse migliaia di sistemi disconnessi per diversi giorni.

Worm Internet – Come ha funzionato

– Sfruttava diversi difetti ed errori di configurazione della versione Berkley 4 del sistema operativo Unix.

– In questo modo raggiungeva i tre obiettivi visti in precedenza:

• Determinare dove potersi diffondere;

• Diffondere l’infezione;

• Rimanere sconosciuto e introvabile.

– Esaminiamo i difetti in dettaglio.

Determinare dove potersi diffondere

– Sfruttava tre falle di protezione ben note alla comunità Unix.

– La prima era dovuta ad un errore congiunto dell’utente e del sistema. • Il file delle password Unix è archiviato in forma cifrata,

ma il testo cifrato è leggibile da chiunque (errore del sistema).

• Il worm crittava varie password comuni (come “guest”, “password”, “help”, “caffè”, “coca”, “aaa”, …) e confrontava il testo cifrato con quello del file delle password (la scelta di una password riconoscibile è l’errore dell’utente). Se trovava la password, il worm poteva accedere.


– La seconda falla riguardava fingerd

• il servizio per rispondere alla richieste di informazioni da altri computer in merito alle informazioni sugli utenti di sistema.

– La falla consisteva in una vulnerabilità di tipo buffer overflow

• era possibile confezionare un input malevolo tale da sovrascrivere l’indirizzo di ritorno di un record di attivazione nello stack

– Al termine della chiamata finger, finger poteva quindi essere costretto a eseguire le istruzioni spinte al suo interno

• provocando la connessione del worm ad una shell remota.


– La terza falla riguardava una trapdoor nel programma sendmail.

• Normalmente sendmail rimane in attesa di chiamata da altri programmi per l’invio di posta elettronica.

• Il destinatario specificato viene verificato per poi procedere con la ricezione del messaggio.

• Tuttavia durante l’esecuzione in modalità di debug il worm obbligava sendmail a ricevere ed eseguire una stringa di comandi al posto dell’indirizzo di destinazione.

Diffusione dell’infezione

– Dopo aver trovato una macchina di destinazione adatta, il worm utilizzava uno dei precedenti tre metodi per inviare un bootstrap loader alla macchina bersaglio.

– Il loader consisteva in 99 righe di codice C da compilare ed eseguire sulla macchina di destinazione.

– Il bootstrap loader avrebbe poi analizzato il resto del worm dalla macchina host di invio.

Rimanere sconosciuti e introvabili

– Se si verificava un errore di trasmissione mentre il resto del worm veniva prelevato, il loader azzerava e poi eliminava tutto il codice già trasferito, quindi terminava la procedura.

– Non appena il worm riceveva il suo codice completo, trasferiva il codice in memoria, lo crittava ed eliminava le copie originali dal disco.

– Il worm cambiava periodicamente nome e identificativo del processo, in modo da non tenere in esecuzione nessun singolo nome per troppo tempo.

Cosa si è appreso

– Il worm Internet diede una scossa alla comunità Internet, che all’epoca era costituita principalmente da universitari e ricercatori. • I siti colpiti provvidero a risolvere le falle;

• Alcuni utente cambiarono le password;

• Vennero realizzati strumenti per la rilevazione automatica delle falle.

• Nonostante ciò gli analisti ritengono che molte delle stesse falle esistano tuttora.

– Il worm era benigno (non distruggeva dati, non salvava le password), ma avrebbe potuto compiere molti danni.

Cosa si è appreso

– Molte persone furono spinte all’azione.

• Gli Stati Uniti svilupparono un’infrastruttura per la comunicazione e la correzione dei difetti del codice, malevoli e non.

• Venne istituito il Computer Emergency Response Team (CERT) alla Carnegie Mellon University.

– Gli amministratori oggi si scambiano informazioni su problemi e soluzioni: la sicurezza deriva da azioni e protezione supportate dall’informazione, non dall’ignoranza e dall’inattività.

CODE RED Esempi di codice malevolo

Introduzione

• Apparve a metà del 2001 con effetti devastanti.

• Colpiti 750.000 server in tutto, compresi 400.000 computer nel solo periodo dal 1 al 10 agosto.

• Danno stimato in oltre due miliardi di dollari.

Code Red – Che cosa ha fatto

• Si propaga sui server Web che girano su Internet Information Server (IIS) di Microsoft.

• Funziona in due passaggi:

– Infezione, tramite buffer overflow nella libreria a collegamento dinamico idq.dll.

– Propagazione, controllando indirizzi IP sulla porta 80 per vedere se il server è vulnerabile.

Quali sono stati gli effetti

– La prima versione era facile da individuare, perché deturpava i siti Web con il seguente testo

HELLO!

Welcome to

http://www.worm.com !

Hacked by Chinese

– Il resto delle attività era determinato dalla data. • Dal 1 al 19 del mese, il worm produceva altri 99 thread che

ricercavano altri computer vulnerabili.

• Dal 20 al 27, il worm lanciava un attacco distributed denial-of-service al sito www.whitehouse.gov.

• Dal 28 alla fine del mese rimaneva inattivo.

Quali sono stati gli effetti

– Altre varianti compivano differenti operazioni, fino a iniettare una cavallo di Troia nel server colpito per permettere l’esecuzione di comandi arbitrati sul server.

Che cosa si è appreso

– Microsoft ha rilasciato la patch per risolvere il problema, ma molti amministratori trascurarono l’applicazione della patch.

– La gestione degli aggiornamenti del software è una vera e propria attività che richiede delle risorse dedicate.

– Ora esistono gli aggiornamenti automatici!

WEB BUG Esempi di codice malevolo

Web Bug – Che cosa fanno

– Un Web bug (a volta chiamato tag pixel, clear gif, gif a singolo pixel, gif invisibile o beacon gif) è un’immagine nascosta in un qualsiasi documento che può visualizzare tag HTML:

• Una pagina web;

• Un messaggio di posta elettronica (in formato HMTL);

• Un foglio elettronico.

– Il creatore vuole che il bug sia invisibile all’utente, ma che possa tenere traccia delle attività sul web.

Web Bug – Che cosa fanno

– Ad esempio, visitando la home page di Blue Nile all’indirizzo www.bluenile.com, viene automaticamente scaricato il seguente bug da Avenue A, un’agenzia di marketing:

<img height=“1” width=“1”

src=“http://switch.avenuaa.com/action/bluenile_homepage/v

2/a/AD7029944”>

Web Bug – Quali effetti hanno

– Un Web bug inserisce un file chiamato cookie nel disco rigido del sistema.

• Il cookie tipicamente contiene un identificativo univoco assegnato all’utente.

• Consideriamo la società di marketing di cui all’esempio precedente.

• Le informazioni contenute nel cookie vengono reinviate al server ogni volta che viene fatta una richiesta al medesimo server.

• Se i Web bug di Avenue A sono utilizzati da molti siti, è possibile tracciare un profilo dell’utente, sebbene sia anonimo.

Come funzionano

– A prima vista i Web bug non sembrano essere malevoli, raccolgono dati numerici ma non tengono traccia di informazioni personali come il nome e l’indirizzo del navigatore.

– Tuttavia se l’utente effettua un acquisto o una registrazione al sito, questi dati verranno forniti e potranno completare il profilo.

– Inoltre, ogni richiesta al server Web contiene comunque informazioni come: • Indirizzo IP del computer;

• Il tipo di browser usato;

Come funzionano

• La risoluzione del monitor;

• Altre impostazioni del browser, per esempio se è abilitata la tecnologia Java;

• Il tempo di connessione;

• Valori precedenti dei cookie;

• …

– Queste informazioni possono essere utilizzate per tenere traccia dell’utente.

– In modo più malevolo, il bug può essere utilizzato in maniera astuta per determinare degli indirizzi IP con determinate caratteristiche che potrebbero permettere un attacco di successo.

Cosa si è appreso

– I Web bug sollevano interrogativi sulla privacy e alcune nazioni stanno prendendo in considerazione leggi per la protezione specifica dai bug web.

– I browser attuali permettono un’alta granularità di configurazione per le regole di gestione dei cookie.

CODICE MALEVOLO SPECIALIZZATO Sicurezza dei sistemi operativi

Introduzione

– Finora abbiamo analizzato del codice (malevolo) anonimo, scritto per influire su utenti e macchine in modo indiscriminato.

– In questa sezione analizzeremo del codice malevolo scritto per un sistema particolare, per un’applicazione specifica o per uno scopo determinato.

TRAPDOOR Codice malevolo specializzato

Introduzione

• Una trapdoor è un punto di ingresso non documentato ad un modulo.

• Vengono utilizzate di norma per lo sviluppo del codice: – Per provare il modulo;

– Per fornire “agganci” con cui connettersi a futuri perfezionamenti o modifiche;

– Per consentire l’accesso al modulo in caso di malfunzionamenti.

• Oltre all’utilizzo durante lo sviluppo, le trapdoor possono però consentire l’accesso al programma una volta che questo viene messo in produzione.

Stub

– I sistemi informatici sono strutture complesse. Per questa ragione i programmatori spesso sviluppano e provano i sistemi in modo metodico, organizzato e modulare, sfruttando il fatto che il sistema è composto da moduli e componenti.

– I moduli vengono prima verificati singolarmente, nella fase di verifica dell’unità.

– Successivamente vengono verificati nel funzionamento integrato, nella verifica dell’integrazione.

Stub

– Per la verifica dei singoli moduli e dei loro aggregati, potrebbero non essere ancora disponibili i moduli che generano l’input e gestiscono l’output.

• Per questo motivo i programmatori realizzano delle routine aggiuntive che ricreano l’ambiente di esecuzione del modulo in esame (creazione dell’input e gestione dell’output, chiamati “stub” (“troncone”, “mozzicone”) o “driver per prove”.

– Gli stub verranno poi sostituiti, più avanti nella realizzazione del software, dai moduli di cui emulano le funzionalità.

Codice di debug

– A volte, quando l’origine di un problema di un modulo non è evidente, il programmatore aggiunge del codice di debug.

– Il codice serve per evidenziare che cosa accade durante l’esecuzione, stampando valori di interesse o eseguendo speciali comandi.

Disattivare le funzionalità di debug in produzione

– Per controllare gli stub ed il codice di debug, il programmatore include sequenze di controllo speciali nella struttura del componente. • Ad esempio, particolari valori dell’input potrebbero essere

utilizzati come comandi per gestire il debug.

– L’inserimento dei comandi è una pratica di verifica riconosciuta, ma, se vengono lasciati in posizione dopo i test, i comandi aggiuntivi possono divenire un problema. • Il worm Internet ha diffuso la sua infezione utilizzando

proprio questo tipo di trapdoor di debug in un programma di posta elettronica.

Controllo degli errori

– Un’altra fonte di trapdoor è uno scarso controllo degli errori. • Un buon sviluppatore progetta il sistema in modo che

qualsiasi valore dei dati sia controllato prima del suo utilizzo.

• Il controllo comporta la verifica della correttezza del dato e della sua appartenenza all’intervallo previsto.

– In sistemi progettati in modo scadente il controllo potrebbe non essere realizzato e un dato fuori specifica potrebbe causare errori imprevisti. • La falla di fingerd sfruttata dal worm Morris era di questo

tipo. La routind di I/O di una libreria di C non controlla se rimangono caratteri nel buffer di input prima di restituire il puntatore a un carattere successivo.

Necessario documentare le trapdoor

– Come i virus, le trapdoor non sono sempre cattive: possono rivelarsi utili anche per rilevare falle di sicurezza.

– Affinché siano utili è indispensabile:

• Che siano documentate;

• Che l’accesso sia fortemente controllato;

• Che siano progettate ed utilizzate con la piena consapevolezza delle potenziali conseguenze.

Cause delle trapdoor

– Le trapdoor possono rimanere nei programmi di produzione perché gli sviluppatori:

1. Dimenticano di rimuoverle;

2. Le lasciano intenzionalmente nel programma a scopo di test;

3. Le lasciano intenzionalmente nel programma per la manutenzione dello stesso;

4. Le lasciano intenzionalmente nel programma come mezzi nascosti di accesso dopo che questo è diventato parte accettata di un sistema di produzione.

Cause delle trapdoor

– Il primo è un errore grossolano, il secondo e il terzo costituiscono un serio problema per la sicurezza, il quarto è il primo passo di un attacco.

– In generale le trapdoor rappresentano una vulnerabilità quando espongono il sistema a modifiche durante l’esecuzione.

– Un sistema non è sicuro quando qualcuno ritiene che nessun altro saprà individuarne il varco.

SALAMI ATTACK Codice malevolo specializzato

Introduzione

– Deve il suo nome al modo in cui pezzettini di carne e grasso vengono mischiati in una salsiccia o in un salame.

– Con la stessa tecnica un salami attack unisce bit di dati apparentemente non sequenziali per ottenere risultati non significativi.

Esempio di salami attack (2)

– Il classico esempio di salami attack riguarda il calcolo degli interessi.

– Supponiamo che: • Una banca paghi il 6.5% di interesse annuo;

• L’interesse viene calcolato su base mensile -> 6.5%/365*31 = 0.5520…%

• Considerando un saldo di 100€, l’interesse mensile risulta allora di 0.5520…€

• Le banche effettuano i calcoli al centesimo di euro: cosa accade alle frazioni di centesimo?

• Una popolare leggenda sulla sicurezza informatica narra di un programmatore che raccoglieva le frazioni di centesimo e le accreditava sul suo conto …

Esempi di salami attack (2)

– In realtà, poiché alcuni arrotondamenti avvengono per difetto, mentre altri per eccesso, il saldo complessivo non dovrebbe discostarsi molto dallo zero.

– Situazione differente (e redditizia) potrebbe essere ottenuta scalando qualche centesimo da ogni conto.

• Il correntista che vedrebbe accreditarsi 0.53€ invece di 0.55€ probabilmente lo imputerebbe ad un errore proprio sul calcolo, o comunque ad una questione di poco conto.

• Oppure il programma potrebbe registrare un canone di 20€ per un servizio che costa in realtà 15€, ed accreditare la differenza su un conto speciale.

Perché esistono ancora?

– I calcoli informatici sono notoriamente soggetti a piccoli errori relativi ad arrotondamento e troncamento.

– Anziché documentare i (numerosi) errori esatti, è più semplice per programmatore ed utenti accettare una piccola percentuale di errore come naturale ed inevitabile.

– Per far quadrare i conti, il programma include una correzione degli errori nei calcoli.

• Una verifica inadeguata di queste correzioni è il motivo per cui un salami attack può passare inosservato.

Perché esistono ancora?

– Di solito il codice sorgente di un sistema è troppo grande o complesso per poter scovare attacchi di questo tipo, a meno che non vi sia un motivo per sospettarne la presenza.

• La dimensione ed il tempo sono punti a favore del programmatore malevolo.

I ROOTKIT E LA TECNOLOGIA SONY XCP

Codice malevolo specializzato

Introduzione

– Il nome rootkit si riferisce al tentativo da parte del codice di operare come utente root

• ossia come utente che gode dei massimi privilegi nei sistemi operativi Unix.

– Un rootkit tipico si insinua nella normale interazione tra utente e sistema operativo nel modo seguente:

• Ogni volta che l’utente esegue un comando che mostrerebbe la presenza del rootkit, per esempio mediante l’elencazione dei file o dei processi in memoria,

• il rootkit intercetta la chiamata e filtra il risultato che viene restituito, in modo che non risulti.

Introduzione

– Per esempio:

• una directory contiene sei file, uno dei quali è il rootkit;

• Il rootkit passa il comando di directory al sistema operativo;

• Il rootkit intercetta il risultato, cancella la voce che lo riguarda dall’elenco e aggiusta l’occupazione di spazio;

• All’utente sono mostrati solo cinque file.

– È possibile scrivere un rivelatore di rootkit che agisca a basso livello nel filesystem

– e che confronti il risultato delle chiamata al sistema operativo (modificate dal rootkit), con il risultato delle interrogazioni a basso livello.

Sony XCP (1)

– La Sony ha creato XCP (eXtended Copy Protection) per impedire che un utente copi un CD musicale, permettendone invece la riproduzione.

– A questo scopo

• Include nel CD il suo specifico riproduttore che possiede l’autorizzazione per leggere il CD;

• Interferisce con ogni altro accesso non autorizzato al CD, alterando il risultato della lettura dal CD.

Sony XCP (2)

– Il rootkit deve autoinstallarsi quando il CD viene inserito

• utilizza la funzionalità “utile” di “autorun” di Windows.

– XCP deve nascondersi all’utente, in modo da non poter essere rimosso

• blocca la visualizzazione di ogni programma il cui nome inizia con $sys$ (il nome del rootkit stesso).

• Questo filtro si applica a qualsiasi nome. Un autore di virus potrebbe nascondere un virus chiamandolo semplicemente $sys$-1!

Sony XCP (2)

• La Sony ha commesso due errori:

1. Ha distribuito del codice che, senza avvisare, apre il sistema a possibili infezioni;

2. Ha installato il suo codice senza metterne a conoscenza l’utente, rendendo inoltre difficoltosa la sua rimozione.

Tappare la falla

• Di fronte alla pubblicità negativa che ha ricevuto da questo rootkit, la Sony ha deciso di rilasciare un disinstallatore.

• Sfortunatamente la pressione e la fretta hanno portato ulteriori problemi.

– Infatti il disinstallatore si presentava come una pagina Web che scaricava ed eseguiva il programma di disinstallazione.

– I programmatori però non avevano previsto il controllo di quale codice venisse eseguito • la pagina Web poteva eseguire codice di qualsiasi fonte, non

solo della Sony.

– Il codice permaneva anche dopo la disinstallazione, lasciando quindi la vulnerabilità nel sistema.

Numeri

– Quanti computer sono stati infettati dal rootkit? Nessuno lo sa con certezza.

• Sono stati trovati 500.000 riferimenti nelle tabelle DNS al sito contattato, ma alcune voci avrebbero potuto supportare l’accesso di centinaia o migliaia di computer.

– Quanti utenti infetti ne erano a conoscenza? Non è possibile rispondere, come non è possibile sapere quanti computer siano ancora infetti.

Digital Rights Management

– Alcune analisi mostrano come i sistemi di gestione dei diritti d’autore (DRM, Digital Rights Management) configurano requisiti simili a quelli dello sviluppo di codice malevolo.

– Per lo sviluppo la Sony aveva lavorato in collaborazione con i principali produttori di antivirus per trovare il modo di nascondere il proprio rootkit

– per la Sony la cosa migliore era che i consumatori ne rimanessero all’oscuro.

SCALATA DEI PRIVILEGI Codice malevolo specializzato

Contesto di esecuzione

– I programmi girano in un contesto che ne regola i diritti di accesso e i privilegi.

– La maggior parte dei programmi viene eseguita nel contesto dell’utente che li invoca: • Se i diritti di accesso sono impostati correttamente, è

possibile creare, modificare o cancellare gli elementi posseduti dall’utente, ma gli oggetti critici per il sistema sono protetti, essendo fuori dal contesto.

– Un attacco basato sulla scalate dei privilegi (privilege escalation) consente al codice malevolo di essere lanciato da un utente con privilegi bassi, ma di andare in esecuzione con privilegi superiori: • Può quindi agire sugli oggetti di sistema.

Esempio: Live Update (1)

– La Symantec produce software per la sicurezza.

– Per consentire che i prodotti siano sempre aggiornati, l’azienda ha previsto l’opzione Live Update (LU)

– Si tratta di una funzionalità ricerca ad intervalli regolari aggiornamenti per il software e li installa.

– Poiché deve installare gli aggiornamenti direttamente nella directory di sistema,

– è necessario che la funzionalità venga eseguita con privilegi elevati.


– Il processo coinvolgeva l’esecuzione dei seguenti programmi:

• LU1, componente di Live Update;

• LU2, componente di Live Update;

• Sys3, componente standard di sistema;

• Sys4, componente standard di sistema.


– Per avviare l’esecuzione di un programma i sistemi operativi utilizzano il “percorso di ricerca” path: • il path contiene un elenco di directory in cui ricerca il

programma che è stato chiamato.

• quando un programma A chiama un programma B, il sistema operativo cerca nella prima directory specificata nel path.

– Se il programma viene trovato, allora si passa all’esecuzione,

– altrimenti la ricerca procede nelle successive directory del path o termina con un errore se non viene trovata alcuna corrispondenza. • In caso di corrispondenze multiple, il programma eseguito è

quello che per primo viene trovato nel path.


– È comunque sempre possibile avviare un programma tramite percorso esplicito:

• C:\Programmi\Symantec\LU1.exe

– In alcune versioni di Macintosh, La Symantec consentiva l’avvio di programmi attraverso path:

• se l’utente aggiungeva le directory del proprio spazio nelle prime posizioni del path e aveva un programma Sys3,

• ecco che questo veniva eseguito con privilegi elevati, superiori a quelli dell’utente, al posto del programma originale.

FALSIFICAZIONE DELL’INTERFACCIA Codice malevolo specializzato

Descrizione

– L’attacco Interface Illusion (phishing) è di tipo spoofing in cui una pagina web o parte di essa è falsificata.

– Obiettivo dell’aggressore è convincere l’utente a compiere qualcosa di inappropriato, ad esempio:

• Inserire i propri dati bancari in un sito che non è quello della banca;

• Premere un pulsante Non accetto che invece significa Accetto;

• Scorrere lo schermo per attivare un evento che causa l’installazione di software malevolo sul computer.

REGISTRAZIONE DEI TASTI PREMUTI Codice malevolo specializzato

Descrizione

– Non esiste una canale diretto tra un tasto premuto sulla tastiera e il programma (ad esempio un elaboratore di testi) che lo utilizza.

– Quando si preme il tasto A:

1. Viene attivato un interruttore che genera un segnale;

2. Il segnale viene ricevuto da un driver di periferica;

3. Il driver analizza il segnale e genera il codice “A”;

4. Il codice passa attraverso altri livelli fino al programma che lo utilizza;

5. Altre elaborazioni e conversioni portano alla comparsa di “A” sullo schermo.

Descrizione

– In questo processo intervengono numerosi programmi, organizzati con un paradigma a livelli (come, ad esempio, lo stack TCP/IP).

– Uno dei programmi che intervengono può essere modificato per tenere traccia dei tasti premuti, da cui poi poter rilevare informazioni importanti, come codici di accesso, password.

Bibliografia






Dati Sensibili

Dati Sensibili

• Molti DB contengono quelli che si definiscono Dati Sensibili

• Come definizione pratica diciamo che i dati sensibili sono quelli che non dovrebbero essere resi pubblici

• Determinare quali dati siano sensibili dipende dal singolo DB e dalla specifica applicazione

Dati Sensibili

• Due casi estremi:

– Nessun dato sensibile (p.es. catalogo di una biblioteca)

– Tutti i dati sensibili (p.es. database militari)

• Questi casi sono i più semplici da gestire:

– Accesso consentito all’intero DB

– Accesso negato all’intero DB

Dati Sensibili

• Il caso più interessante è quello in cui alcuni dati sono sensibili mentre altri non lo sono

• Inoltre è possibile che dati diversi abbiano livelli di sensibilità diversi

Esempio Cognome Sesso Razza Aiuto Multe Droghe Dormitorio

Adams M C 5000 45 1 Holmes

Bailey M B 0 0 0 Grey

Chin F A 3000 20 0 West

Dewitt M B 1000 35 3 Grey

Earhart F C 2000 95 1 Holmes

Fein F C 1000 15 0 West

Groff M C 4000 0 3 West

Hill F B 5000 10 2 Holmes

Koch F C 0 0 1 West

Liu F A 0 10 2 Grey

Majors M C 2000 0 2 Grey

Studente

Esempio

• Campi non sensibili: Nome, Dormitorio

• Campi sensibili: Aiuto, Multe, Droghe

• Campi parzialmente sensibili: Sesso, Razza

Dati sensibili

– Sensibili per Contenuto: Il valore dell’attributo è sensibile

• es. località di postazioni missilistiche

– Sensibili per Provenienza: la fonte dei dati può necessitare di riservatezza

• es. messaggi di un informatore la cui identità segreta verrebbe compromessa se i dati venissero divulgati

– Dichiarati sensibili: l’amministratore ha dichiarato che i dati sono sensibili

• es. donatore anonimo

Dati sensibili

– Parti sensibili: attributo o record. • Un intero record o solo un certo attributo possono

risultare sensibili

• es. campo stipendio, record che descrive una missione segreta

– Sensibili in relazione a informazioni divulgate in precedenza: • Alcuni dati diventano sensibili in funzione di altri dati

• es. la latitudine di una postazione segreta diventa sensibile se si conosce anche la longitudine

Come proteggere i dati sensibili?

• Decidere come divulgare i dati sensibili può non essere semplice

• Si possono ottenere informazioni anche se i dati sensibili non vengono mostrati

• A volte anche alcune caratteristiche dei dati devono essere considerati sensibili

Esempio

• La seguente query non mostra il valore dell’attributo droghe …

• … ma tutti coloro presenti nel risultato fanno uso di droghe

• Può essere necessario proteggere un valore sensibile anche se questo non viene mostrato in modo esplicito

Cognome Sesso Razza Aiuto Multe Droghe Dormitorio

SELECT Cognome, Dormitorio FROM Studente WHERE Droghe>0

Studente

Tipi di divulgazione

• Dati esatti:

– Divulgazione del valore esatto di un dato sensibile

– La divulgazione potrebbe avvenire per una richiesta esplicita

– Oppure i dati sensibili potrebbero essere restituiti insieme ad altri dati non sensibili

– Oppure il sistema potrebbe restituire i dati sensibili per errore


• Limiti:

– Indicazione che un valore sensibile è compreso tra due valori L e H

– In questo caso con una ricerca dicotomica si potrebbe ottenere un valore molto prossimo a quello esatto

– In alcuni casi semplicemente sapere che un valore è al di sopra (o al di sotto) di un certo limite rappresenta una violazione della sicurezza


• Risultato negativo:

– A volte si può ottenere un informazione sapendo che il valore cercato non è pari ad un certo valore

– Ad es. se sappiamo che il numero di condanne penali di una certa persona non è zero sappiamo che la persona in questione è stata condannata (non sappiamo quante volte, ma …)


• Esistenza:

– A volte la sola esistenza di un attributo è sensibile

– Ad es. un responsabile del personale potrebbe desiderare che non si sappia che la durata delle interurbane dei dipendenti viene monitorata

– Quindi la scoperta del campo interurbane in una tabella con i dati del personale rivelerebbe dati sensibili


• Valore probabile: – A volte si può determinare la probabilità di un certo

evento

– Vogliamo sapere se Tizio è iscritto al partito X

– Facciamo due query: • Quante persone risiedono all’indirizzo ABC (indirizzo di

Tizio)? Risposta: 4

• Quante persone risiedono all’indirizzo ABC e sono iscritte al partito X? Risposta: 1

• Abbiamo il 25% di probabilità che Tizio sia iscritto al partito X

Protezione dei dati sensibili

• Per aumentare la protezione dei dati sensibili si potrebbe pensare di usare politiche sempre più restrittive in maniera da proteggere meglio i dati

– Ad esempio si potrebbe pensare di rifiutare qualunque query che faccia riferimento ad un campo sensibile

– Questo però limiterebbe anche le interrogazioni legittime

Protezione dei dati sensibili

• Abbiamo due esigenze contrastanti:

– Nascondere i dati per evitare di fornire dati sensibili (Sicurezza)

– Divulgare i dati non sensibili quanto più possibile per consentire l’utilizzo corretto dei dati da parte delle persone autorizzate (Precisione)

Sicurezza contro Precisione

Nascosto-non divulgato

Non può essere dedotto dalle query

Può essere dedotto dalle query

Divulgato liberamente

Rivelare per massima precisione

Nascondere per massima sicurezza

Inferenza

Inferenza

• L’inferenza è un metodo per dedurre o derivare dati sensibili da dati non sensibili

– Riconsideriamo l’esempio del database sugli studenti e consideriamo sensibili i campi

– Aiuto, Multe e Droghe

Esempio Cognome Sesso Razza Aiuto Multe Droghe Dormitorio









Koch F C 0 0 1 West

Liu F A 0 10 2 Grey


Studente

Attacco diretto

• La seguente query rappresenta un tentativo diretto di accedere ad un dato sensibile

– Tale query potrebbe essere rifiutata dal DB perché le tuple del risultato sono quelle con uno specifico valore su un attributo sensibile

SELECT Cognome

FROM Studente

WHERE Sesso=M AND Droghe=1

Attacco diretto

• La seguente query è meno ovvia:

– Apparentemente la query non seleziona solo tuple con uno specifico valore su un campo sensibile

– In realtà la seconda e la terza condizione non sono mai soddisfatte

SELECT Cognome

FROM Studente

WHERE (Sesso=M AND Droghe=1) OR

(SessoM AND SessoF) OR

(Dormitorio = “Ayres”)

Attacco diretto

• La seguente query è meno ovvia:

– Per capirlo il DBMS dovrebbe capire che ci sono due soli possibili valori per Sesso

– E che non c’è alcuna tupla con valore di Dormitorio pari Ayres

SELECT Cognome

FROM Studente

WHERE (Sesso=M AND Droghe=1) OR

(SessoM AND SessoF) OR

(Dormitorio = “Ayres”)

Attacco diretto

• Una regola a volte utilizzata per decidere se riportare i dati di una query è quella di “n elementi sul k percento”:

• I risultati non vanno divulgati se un piccolo numero di elementi costituisce più del k% del risultato

• Nell’esempio precedente una sola persona costituiva il 100% del risultato

Attacco indiretto

• Alcune organizzazioni che detengono dati sensibili, divulgano soltanto dati statistici

• Dati ottenuti come somme medie e conteggi

• L’attacco indiretto cerca di dedurre un dato sensibile sulla base di uno o più dati statistici intermedi

Attacco indiretto: Somma

• La seguente query sembra innocua poiché restituisce soltanto valori aggregati:

– Vediamo però il risultato

SELECT Sesso, Dormitorio, SUM(Aiuto)

FROM Studente

GROUP BY Sesso, Dormitorio

Attacco indiretto: Somma

– Il risultato ci rivela che nessuna donna nel dormitorio Grey riceve aiuti finanziari

– Divulgazione di tipo “risultato negativo”

Sesso Dormitorio SUM(Aiuto)

M Holmes 5000

M Grey 3000

M West 4000

F Holmes 7000

F Grey 0

F West 4000

Attacco indiretto: Conteggio

• Il conteggio può essere combinato con la somma per produrre risultati ancora più rivelatori:

SELECT Sesso, Dormitorio, COUNT(*)

FROM Studente

GROUP BY Sesso, Dormitorio

Attacco indiretto: Conteggio

– Questo risultato combinato con il precedente ci dice che i due uomini nei dormitori Holmes e West ricevono un aiuto finanziario rispettivamente di 5000 e 4000

Sesso Dormitorio COUNT(*)

M Holmes 1

M Grey 3

M West 1

F Holmes 2

F Grey 1

F West 3

Attacco indiretto: Media

– La media può permettere di ottenere informazioni esatte se utilizzata in combinazione con il conteggio

– Se riesco ad ottenere la media su un insieme formato da un solo elemento, riesco a conoscere il valore esatto per quell’elemento

– Usata opportunamente permette anche di aggirare eventuali controlli sulla numerosità dell’insieme su cui viene calcolata


• Supponiamo che la media non venga divulgata se il numero di elementi su cui è calcolata è 1

SELECT AVG(Aiuto)

FROM Studente

WHERE Dormitorio=“Holmes”

AVG(Aiuto)

4000

SELECT AVG(Aiuto)

FROM Studente


AND Sesso=‘F’

AVG(Aiuto)

3500


• Supponiamo che la media non venga divulgata se il numero di elementi su cui è calcolata è 1

SELECT COUNT(*)

FROM Studente


COUNT(*)

3

SELECT COUNT(*)

FROM Studente


AND Sesso=‘F’

COUNT(*)

2


COUNT(*)

3

COUNT(*)

2

AVG(Aiuto)

4000

AVG(Aiuto)

3500

Aiuto finanziario medio Aiuto finanziario medio alle donne

Numero di persone Numero di donne

40003

321 aaa

35002

21 aa

50003 a

Aiuto finanziario dell’unico uomo nel dormitorio Holmes

Attacchi di Tracker

– Abbiamo visto che uno delle tecniche di protezione dall’inferenza consiste nel non divulgare i dati se un piccolo numero di elementi fornisce molta informazione

– È possibile aggirare questa limitazione effettuando più query lecite

– La combinazione dei risultati delle query ci dà l’informazione sensibile

Attacchi di Tracker: esempio

• Consideriamo la seguente query

SELECT COUNT(*)

FROM Studente

WHERE Sesso=‘F’ AND Razza=‘C’

AND Dormitorio=‘Holmes’

Attacchi di Tracker: esempio Cognome Sesso Razza Aiuto Multe Droghe Dormitorio









Koch F C 0 0 1 West

Liu F A 0 10 2 Grey



• Il dato non viene divulgato in quanto dominato da una sola tupla

– Osserviamo però che il valore in questione può essere calcolato contando

– tutte le donne che non sono di razza C

– o che non risiedono nel dormitorio Holmes


SELECT COUNT(*)

FROM Studente

WHERE Sesso=‘F’

AND (Razza <> ‘C’

OR Dormitorio <> ‘Holmes’)

SELECT COUNT(*)

FROM Studente

WHERE Sesso=‘F’

COUNT(*)

6

COUNT(*)

5

Vulnerabilità del sistema lineare

• L’attacco di tracker è un caso specifico di una vulnerabilità più generica in cui sfruttando algebra, logica e un po’ di fortuna si riesce ad ottenere tramite diverse query dei valori protetti


– Riconsideriamo l’esempio di prima, la query protetta è del tipo:

q = COUNT((Sesso = F)(Razza = C)(Dormitorio = Holmes))

– in base all’algebra riscriviamo la query come:

q = COUNT(Sesso = F) –

COUNT((Sesso = F)

((Razza = C) (Dormitorio = Holmes)))

– in pratica q = c1 riscritta come q = c2-c3


• Più in generale potremmo avere

q1=c1+c2+c3+c4+c5

q2=c1+c2+c4

q3=c3+c4

q4=c4+c5

q5=c2+c5

• Nessuna delle query rivela apertamente uno dei valori ci

• Risolvendo il sistema possiamo però conoscerli tutti

Protezione dall’inferenza

• Esistono alcune tecniche per combattere l’inferenza:

– Analisi delle query

– Soppressione: valori sensibili non forniti

– Occultamento: la risposta è vicina ma non corrisponde esattamente al valore effettivo

Soppressione e occultamento

• Un esempio di soppressione è la già citata regola “n elementi sul k percento”

• Alcune considerazioni:

– Può essere necessario sopprimere altri dati per evitare che quelli sensibili siano ottenibili per differenza

Esempio

Holmes Grey West Totale

M 1 3 1 5

F 2 1 3 6

Totale 3 4 4 11

Numero di residenti per sesso e dormitorio

Esempio

Holmes Grey West Totale

M - 3 - 5

F 2 - 3 6

Totale 3 4 4 11

Numero di residenti per sesso e dormitorio

Attenzione: i valori soppressi possono essere dedotti per differenza

Risultati combinati

• Per evitare di divulgare dati sensibili è possibile combinare più righe o colonne

Uso di droghe

0 1 2 3

M 1 1 1 2

F 2 2 2 0

Numero di studenti per sesso e uso di droghe

Risultati combinati

• Per evitare di divulgare dati sensibili è possibile combinare più righe o colonne

Uso di droghe

0 o 1 2 o 3

M 2 3

F 4 2

Numero di studenti per sesso e uso di droghe

Risultati combinati

• Analogamente risultati relativi agli aiuti finanziari potrebbero essere mostrati per intervalli: 0-1999, 2000-3999, 4000 e oltre

Campione casuale

• La query viene effettuata su un campione casuale dei dati

– Il campione deve essere abbastanza ampio da rappresentare l’intera popolazione

– In questo modo i dati sono rappresentativi dell’intera popolazione ma riducono la possibilità di attacchi statistici

Perturbazione casuale dei dati

• A volte può essere utile perturbare i valori del DB con un piccolo errore.

– Per ogni xi che rappresenta il valore vero dell’attributo i

– si può generare un piccolo errore ei e aggiungerlo ad xi per calcolare dati statistici

– Valori aggregati quali la media o la somma produrranno valori vicini a quelli veri ma non esatti

Inferenza: commenti

• Le varie soluzioni che abbiamo visto tendono a proteggere un DB dal problema dell’inferenza

• Al tempo stesso però limitano anche le informazioni fornite agli utenti che intendano fare un uso legittimo dei dati

Aggregazione

• Un particolare tipo di inferenza e quello dell’aggregazione

• Per aggregazione si intende l’individuazione di dati sensibili mettendo insieme dati non sensibili

– Es: il nome di un impiegato ed il suo stipendio

• nessuno dei due dati è sensibile di per sé, ma lo sono se messi insieme

Aggregazione

– Evitare l’aggregazione è difficile perché bisogna tenere conto delle informazioni già in possesso dell’utente

– Se un utente conosce il nome di un dipendente non devo comunicargli il salario e viceversa

– Tenere traccia delle informazioni in possesso di ciascun utente può essere proibitivo

– Inoltre utenti diversi potrebbero condividere le informazioni in loro possesso

ESERCITAZIONE SULL’INFERENZA

Esercizio

• Con riferimento alla tabella dipendenti, in allegato, trovare lo stipendio di Mister X con un attacco indiretto di tipo media.

• Si hanno a disposizione le seguenti informazioni:

a) Mister X è un uomo con più di 30 anni e non è di Roma;

b) i rimanenti dipendenti maschi con più di 30 anni sono tutti romani;

c) nessun dipendente donna è di Roma.

Esercizio

• Si tenga conto, inoltre, che viene applicata la seguente politica di protezione dei dati sensibili:

1. il campo stipendio non può essere divulgato direttamente e non può essere utilizzato come criterio di filtraggio;

2. i criteri di filtraggio possono essere eta, sesso, e citta;

3. non possono essere utilizzati più di due criteri di filtraggio in una singola interrogazione;

4. è consentita la divulgazione di medie e conteggi a patto che si riferiscano ad almeno tre tuple.

Tabella dipendenti cf cognome nome eta citta sesso ruolo stipendio

… Rossi Mario 36 Roma M impiegato 1200

… Neri Luigi 39 Roma M ricercatore 1700

… Bianchi Mario 35 Roma M ricercatore 1400

… Gialli Federica 36 Firenze F impiegata 1200

… Verdi Anna 38 Milano F impiegata 1300

… Rossi Claudia 31 Verona F segretaria 1000

… Pieri Alessandro 37 Torino M dirigente 4000

… Belli Ilaria 33 Venezia F commercialista 2000

… Bianchini Francesca 32 Napoli F dirigente 3000

… Brutti Elena 32 Perugia F impiegata 1200

… … … … … … … …

… … … … … … … …

Svolgimento – strategia base

• Una possibile strategia di attacco prevede l’individuazione di due insiemi di tuple U e V tali che: I. ciascun insieme contiene singolarmente almeno tre

tuple (vincolo 4.);

II. ciascun insieme deve poter essere individuato usando al più due condizioni di filtraggio (vincolo 3.) basate sugli attributi eta, sesso, e citta (vincolo 2.)

III. la differenza insiemistica U \ V deve contenere soltanto mister X; ovvero {Mister X} = U \ V

IV. l’insieme V deve essere un sottoinsieme di U: V U

Svolgimento – strategia base

• Una volta individuati due insiemi U e V, soddisfacenti le condizioni I, II, III e IV, ponendo: – mU = media degli stipendi dei dipendenti in U;

– cU = numero dei dipendenti in U;

– mV = media degli stipendi dei dipendenti in V;

– cV = numero dei dipendenti in V;

• si ottiene che stipendioMister X = mU ∙ cU – mV ∙ cV

Svolgimento – individuazione di U e V

• Si considerino i seguenti insiemi: – A: insieme dei dipendenti di sesso maschile (sesso

= M);

– B: insieme dei dipendenti con più di 30 anni (eta > 30);

– C: insieme dei dipendenti romani (citta = ‘Roma’);

• si osservi che dalla (a) e dalla (b) risulta che – {Mister X} = (A B) \ C = (A B) \ (B C)

• mentre dalla (c) si ha che C A

Svolgimento – individuazione di U e V

• pertanto risulta che

– {Mister X} = (A B) \ (B C), e

– (B C) (A B)

• quindi gli insiemi U e V sono:

– U = A B

– V = B C

Svolgimento – query SQL

• Individuazione di mU e cU: – SELECT avg(stipendi), count(stipendi) FROM

dipendenti WHERE sesso = ‘M’ AND eta > 30;

• Individuazione di mV e cV: – SELECT avg(stipendi), count(stipendi) FROM

dipendenti WHERE eta > 30 AND citta = ‘Roma’;

Bibliografia






Computer Networks

Circuit and Packet Switching

• Circuit switching – Legacy phone network – Single route through sequence of hardware devices established when two nodes start communication

– Data sent along route – Route maintained until communication ends

• Packet switching – Internet – Data split into packets – Packets transported independently through network

– Each packet handled on a best efforts basis

– Packets may follow different routes

Packet Switching

A

C

B

D

F

D

3 2 1

Packet Switching

A

C

B

D

F

D

3 2

1

Packet Switching

A

C

B

D

F

D

3

2 1

Packet Switching

A

C

B

D

F

D

3 2 1

Protocols • A protocol defines the rules for communication between

computers • Protocols are broadly classified as connectionless and

connection oriented • Connectionless protocol

– Sends data out as soon as there is enough data to be transmitted – E.g., user datagram protocol (UDP)

• Connection‐oriented protocol – Provides a reliable connection stream between two nodes – Consists of set up, transmission, and tear down phases – Creates virtual circuit‐switched network – E.g., transmission control protocol (TCP)

Encapsulation • A packet typically consists of

– Control information for addressing the packet: header and footer – Data: payload

• A network protocol N1 can use the services of another network protocol N2 – A packet p1 of N1 is encapsulated into a packet p2 of N2 – The payload of p2 is p1 – The control information of p2 is derived from that of p1

Header

Payload

Footer Header Payload Footer

Network Layers

• Network models typically use a stack of layers – Higher layers use the services of lower layers via encapsulation

– A layer can be implemented in hardware or software – The bottommost layer must be in hardware

• A network device may implement several layers • A communication channel between two nodes is established for each layer – Actual channel at the bottom layer – Virtual channel at higher layers

Internet Layers

Application

Transport

Network

Link

Application

Transport

Network

Link

Network

Link

Network

Link

Ethernet Fiber Optics Wi-Fi

Physical Layer

Intermediate Layers • Link layer

– Local area network: Ethernet, WiFi, optical fiber – 48‐bit media access control (MAC) addresses – Packets called frames

• Network layer – Internet‐wide communication – Best efforts – 32‐bit internet protocol (IP) addresses in IPv4 – 128‐bit IP addresses in IPv6

• Transport layer – 16‐bit addresses (ports) for classes of applications – Connection‐oriented transmission layer protocol (TCP) – Connectionless user datagram protocol (UDP)

Internet Packet Encapsulation Application

Packet

TCP Data TCP Header

IP Header

Frame Header

Frame Footer Link Layer

Network Layer

Transport Layer

IP Data

Frame Data

Application Layer

Internet Packet Encapsulation Data link frame

IP packet TCP or UDP packet

Application packet

Data link

heade

r

IP heade

r

TCP or UDP

he

ader

Application

packet

Dat

a lin

k fo

oter

The OSI Model

• The OSI (Open System Interconnect) Reference Model is a network model consisting of seven layers

• Created in 1983, OSI is promoted by the International Standard Organization (ISO)

Network Interfaces

• Network interface: device connecting a computer to a network – Ethernet card – WiFi adapter

• A computer may have multiple network interfaces • Packets transmitted between network interfaces • Most local area networks, (including Ethernet and WiFi)

broadcast frames • In regular mode, each network interface gets the frames

intended for it • Traffic sniffing can be accomplished by configuring the

network interface to read all frames (promiscuous mode)

MAC Addresses • Most network interfaces come with a predefined MAC address • A MAC address is a 48‐bit number usually represented in hex

– E.g., 00‐1A‐92‐D4‐BF‐86 • The first three octets of any MAC address are IEEE‐assigned

Organizationally Unique Identifiers – E.g., Cisco 00‐1A‐A1, D‐Link 00‐1B‐11, ASUSTek 00‐1A‐92

• The next three can be assigned by organizations as they please, with uniqueness being the only constraint

• Organizations can utilize MAC addresses to identify computers on their network

• MAC address can be reconfigured by network interface driver software

Switch

• A switch is a common network device – Operates at the link layer – Has multiple ports, each

connected to a computer

• Operation of a switch – Learn the MAC address of

each computer connected to it – Forward frames only to the

destination computer

Combining Switches

• Switches can be arranged into a tree

• Each port learns the MAC addresses of the machines in the segment (subtree) connected to it

• Fragments to unknown MAC addresses are broadcast

• Frames to MAC addresses in the same segment as the sender are ignored

MAC Address Filtering • A switch can be configured to provide service only to machines with specific MAC addresses

• Allowed MAC addresses need to be registered with a network administrator

• A MAC spoofing attack impersonates another machine – Find out MAC address of target machine – Reconfigure MAC address of rogue machine – Turn off or unplug target machine

• Countermeasures – Block port of switch when machine is turned off or unplugged

– Disable duplicate MAC addresses

Viewing and Changing MAC Addresses • Viewing the MAC addresses of the interfaces of a machine

– Linux: ifconfig – Windows: ipconfig /all

• Changing a MAC address in Linux – Stop the networking service: /etc/init.d/network stop – Change the MAC address: ifconfig eth0 hw ether <MAC‐address> – Start the networking service: /etc/init.d/network start

• Changing a MAC address in Windows – Open the Network Connections applet – Access the properties for the network interface – Click “Configure …” – In the advanced tab, change the network address to the desired value

• Changing a MAC address requires administrator privileges

ARP • The address resolution protocol (ARP) connects the network layer to the data

layer by converting IP addresses to MAC addresses • ARP works by broadcasting requests and caching responses for future use • The protocol begins with a computer broadcasting a message of the form

who has <IP address1> tell <IP address2> • When the machine with <IP address1> or an ARP server receives this

message, its broadcasts the response <IP address1> is <MAC address>

• The requestor’s IP address <IP address2> is contained in the link header • The Linux and Windows command arp ‐ a displays the ARP table

Internet Address Physical Address Type

128.148.31.1 00-00-0c-07-ac-00 dynamic

128.148.31.15 00-0c-76-b2-d7-1d dynamic

128.148.31.71 00-0c-76-b2-d0-d2 dynamic

128.148.31.75 00-0c-76-b2-d7-1d dynamic

128.148.31.102 00-22-0c-a3-e4-00 dynamic

128.148.31.137 00-1d-92-b6-f1-a9 dynamic

ARP Spoofing

• The ARP table is updated whenever an ARP response is received

• Requests are not tracked • ARP announcements are not authenticated • Machines trust each other • A rogue machine can spoof other machines

ARP Poisoning (ARP Spoofing)

• According to the standard, almost all ARP implementations are stateless

• An arp cache updates every time that it receives an arp reply… even if it did not send any arp request!

• It is possible to “poison” an arp cache by sending gratuitous arp replies

• Using static entries solves the problem but it is almost impossible to manage!

ARP Caches

IP: 192.168.1.1 MAC: 00:11:22:33:44:01

IP: 192.168.1.105 MAC: 00:11:22:33:44:02

ARP Cache

192.168.1.105 00:11:22:33:44:02

ARP Cache

192.168.1.1 00:11:22:33:44:01

Data 192.168.1.1 is at 00:11:22:33:44:01 192.168.1.105 is at 00:11:22:33:44:02

Poisoned ARP Caches

192.168.1.105 is at 00:11:22:33:44:03

Poisoned ARP Cache

192.168.1.1 00:11:22:33:44:03

Poisoned ARP Cache

192.168.1.105 00:11:22:33:44:03

Data Data

192.168.1.1 is at 00:11:22:33:44:03

192.168.1.1 00:11:22:33:44:01

192.168.1.105 00:11:22:33:44:02

192.168.1.106 00:11:22:33:44:03

Networks: IP and TCP

Internet Protocol • Connectionless

– Each packet is transported independently from other packets

• Unreliable – Delivery on a best effort basis – No acknowledgments

– Packets may be lost, reordered, corrupted, or duplicated

• IP packets – Encapsulate TCP and UDP

packets – Encapsulated into link‐layer

frames

Data link frame IP packet

TCP or UDP packet

IP Addresses and Packets

• IP addresses – IPv4: 32‐bit addresses – IPv6: 128‐bit addresses

• Address subdivided into network, subnet, and host – E.g., 128.148.32.110

• Broadcast addresses – E.g., 128.148.32.255

• Private networks – not routed outside of a LAN – 10.0.0.0/8 – 172.16.0.0/12 – 192.168.0.0/16

• IP header includes – Source address – Destination address – Packet length (up to 64KB) – Time to live (up to 255) – IP protocol version – Fragmentation information – Transport layer protocol

information (e.g., TCP)

fragmentation info

source

destination

TTL prot.

length v

IP Routing

• A router bridges two or more networks – Operates at the network layer – Maintains tables to forward packets to the appropriate network

– Forwarding decisions based solely on the destination address

• Routing table – Maps ranges of addresses to LANs or other gateway routers

Internet Routes

• Internet Control Message Protocol (ICMP) – Used for network testing and debugging – Simple messages encapsulated in single IP packets – Considered a network layer protocol

• Tools based on ICMP – Ping: sends series of echo request messages and provides statistics on roundtrip times and packet loss

– Traceroute: sends series ICMP packets with increasing TTL value to discover routes

ICMP Attacks

• Ping of death – ICMP specifies messages must fit a single IP packet (64KB)

– Send a ping packet that exceeds maximum size using IP fragmentation

– Reassembled packet caused several operating systems to crash due to a buffer overflow

• Smurf – Ping a broadcast address using a spoofed source address

Smurf Attack

Attacker Victim

Amplifying Network

echo request

echo response

echo response

echo response

IP Vulnerabilities • Unencrypted transmission

– Eavesdropping possible at any intermediate host during routing

• No source authentication – Sender can spoof source address, making it difficult to trace packet back to

attacker

• No integrity checking – Entire packet, header and payload, can be modified while en route to

destination, enabling content forgeries, redirections, and man‐in‐the‐middle attacks

• No bandwidth constraints – Large number of packets can be injected into network to launch a denial‐of‐

service attack – Broadcast addresses provide additional leverage

Denial of Service Attack • Send large number of packets to

host providing service – Slows down or crashes host – Often executed by botnet

• Attack propagation – Starts at zombies – Travels through tree of internet

routers rooted – Ends at victim

• IP source spoofing – Hides attacker – Scatters return traffic from

victim

Source: M.T. Goodrich, Probabalistic Packet Marking for Large-Scale IP Traceback, IEEE/ACM Transactions on Networking 16:1, 2008.

IP Traceback

• Problem – How to identify leaves of DoS propagation tree

– Routers next to attacker

• Issues – There are more than 2M internet routers

– Attacker can spoof source address

– Attacker knows that

traceback is being performed

• Approaches – Filtering and tracing (immediate reaction)

– Messaging (additional traffic)

– Logging (additional storage)

– Probabilistic marking

Probabilistic Packet Marking

• Method – Random injection of information into packet header – Changes seldom used bits – Forward routing information to victim – Redundancy to survive packet losses

• Benefits – No additional traffic – No router storage – No packet size increase – Can be performed online or offline

Transmission Control Protocol • TCP is a transport layer protocol guaranteeing reliable data transfer, in‐

order delivery of messages and the ability to distinguish data for multiple concurrent applications on the same host

• Most popular application protocols, including WWW, FTP and SSH are built on top of TCP

• TCP takes a stream of 8‐bit byte data, packages it into appropriately sized segment and calls on IP to transmit these packets

• Delivery order is maintained by marking each packet with a sequence number

• Every time TCP receives a packet, it sends out an ACK to indicate successful receipt of the packet.

• TCP generally checks data transmitted by comparing a checksum of the data with a checksum encoded in the packet

Ports

• TCP supports multiple concurrent applications on the same server • Accomplishes this by having ports, 16 bit numbers identifying where

data is directed • The TCP header includes space for both a source and a destination

port, thus allowing TCP to route all data • In most cases, both TCP and UDP use the same port numbers for the

same applications • Ports 0 through 1023 are reserved for use by known protocols. • Ports 1024 through 49151 are known as user ports, and should be

used by most user programs for listening to connections and the like • Ports 49152 through 65535 are private ports used for dynamic

allocation by socket libraries

TCP Packet Format Bit Offset 0‐3 4‐7 8‐15 16‐18 19‐31

0 Source Port Destination Port

32 Sequence Number

64 Acknowledgment Number

96 Offset Reserved Flags Window Size

128 Checksum Urgent Pointer

160 Options

>= 160 Payload

Establishing TCP Connections • TCP connections are established through a three way handshake. • The server generally has a passive listener, waiting for a connection

request • The client requests a connection by sending out a SYN packet • The server responds by sending a SYN/ACK packet, indicating an

acknowledgment for the connection • The client responds by sending an ACK to the server thus establishing

connection SYN

Seq = x

SYN‐ACK Seq = y

Ack = x + 1

ACK Seq = x + 1

SYN Flood

• Typically DOS attack, though can be combined with other attack such as TCP hijacking

• Rely on sending TCP connection requests faster than the server can process them

• Attacker creates a large number of packets with spoofed source addresses and setting the SYN flag on these

• The server responds with a SYN/ACK for which it never gets a response (waits for about 3 minutes each)

• Eventually the server stops accepting connection requests, thus triggering a denial of service.

• Can be solved in multiple ways • One of the common way to do this is to use SYN cookies

TCP Data Transfer • During connection initialization using the three way handshake, initial

sequence numbers are exchanged • The TCP header includes a 16 bit checksum of the data and parts of

the header, including the source and destination • Acknowledgment or lack thereof is used by TCP to keep track of

network congestion and control flow and such • TCP connections are cleanly terminated with a 4‐way handshake

– The client which wishes to terminate the connection sends a FIN message to the other client

– The other client responds by sending an ACK – The other client sends a FIN – The original client now sends an ACK, and the connection is

terminated

TCP Data Transfer and Teardown Data seq=x

Ack seq=x+1

Data seq=y

Ack seq=y+1

Client Server Client Server

Fin seq=x

Ack seq=x+1

Fin seq=y

Ack seq=y+1

TCP Congestion Control • During the mid‐80s it was discovered that uncontrolled TCP messages

were causing large scale network congestion • TCP responded to congestion by retransmitting lost packets, thus

making the problem was worse • What is predominantly used today is a system where ACKs are used to

determine the maximum number of packets which should be sent out • Most TCP congestion avoidance algorithms, avoid congestion by

modifying a congestion window (cwnd) as more cumulative ACKs are received

• Lost packets are taken to be a sign of network congestion • TCP begins with an extremely low cwnd and rapidly increases the

value of this variable to reach bottleneck capacity • At this point it shifts to a collision detection algorithm which slowly

probes the network for additional bandwidth • TCP congestion control is a good idea in general but allows for certain

attacks.

Optimistic ACK Attack • An optimistic ACK attack takes advantage of the TCP congestion

control • It begins with a client sending out ACKs for data segments it

hasn’t yet received • This flood of optimistic ACKs makes the servers TCP stack

believe that there is a large amount of bandwidth available and thus increase cwnd

• This leads to the attacker providing more optimistic ACKs, and eventually bandwidth use beyond what the server has available

• This can also be played out across multiple servers, with enough congestion that a certain section of the network is no longer reachable

• There are no practical solutions to this problem

Session Hijacking

• Also commonly known as TCP Session Hijacking • A security attack over a protected network • Attempt to take control of a network session • Sessions are server keeping state of a client’s connection • Servers need to keep track of messages sent between client

and the server and their respective actions • Most networks follow the TCP/IP protocol • IP Spoofing is one type of hijacking on large network

IP Spoofing

• IP Spoofing is an attempt by an intruder to send packets from one IP address that appear to originate at another

• If the server thinks it is receiving messages from the real source after authenticating a session, it could inadvertently behave maliciously

• There are two basic forms of IP Spoofing • Blind Spoofing

–Attack from any source • Non‐Blind Spoofing

–Attack from the same subnet

Blind IP Spoofing • The TCP/IP protocol requires that “acknowledgement” numbers be sent

across sessions • Makes sure that the client is getting the server’s packets and vice versa • Need to have the right sequence of acknowledgment numbers to spoof

an IP identity

Non‐Blind IP Spoofing • IP Spoofing without inherently knowing the acknowledgment sequence

pattern – Done on the same subnet – Use a packet sniffer to analyze the sequence pattern

• Packet sniffers intercept network packets • Eventually decodes and analyzes the packets sent across the network

• Determine the acknowledgment sequence pattern from the packets

• Send messages to server with actual client's IP address and with validly sequenced acknowledgment number

Packet Sniffers (cont.)

http://www.rootshell.be/~dhar/downloads/Sniffers.pdf

Packet Sniffers • Packet sniffers “read” information traversing a network

– Packet sniffers intercept network packets – Eventually decodes and analyzes the packets sent across the

network – Can be used as legitimate tools to analyze a network

• Monitor network usage • Filter network traffic • Analyze network problems

– Can also be used maliciously • Steal information (i.e. passwords, conversations, etc.) • Analyze network information to prepare an attack

• Packet sniffers can be either software or hardware based – Sniffers are dependent on network setup

Packet Sniffing (switches) • More common spoofing method on switched networks is ARP sniffing

– A network switch contains an Address Resolution Protocol (ARP) cache • The ARP is a table that maps network IP addresses to the MAC address • If no mapping exists for a requested IP address, broadcasts a request to all networked

machines • The machine with that address responds and is mapped in the ARP • By returning a false reply, a spoofing tool can map the ARP to itself instead of the actual

client and thus receive all packets from the server to the client – The reverse can be done as well to redirect the client packets through the sniffer

• Furthermore, the ARP is stateless – It will accept a “reply” to a broadcast even if no broadcast has been made – This would allow a sniffer to overwrite the ARP cache entry with it's own address – This is known as “poisoning” the ARP

• By utilizing an ARP cache, one can set up a passive sniffer that can be extremely hard to detect

Detecting Sniffers • Sniffers are almost always passive

– They simply collect data – They do not attempt “entry” to “steal” data

• This can make them extremely hard to detect • Most detection methods require suspicion that sniffing is occurring

– Then some sort of “ping” of the sniffer is necessary – It should be a broadcast that will cause a response only from a sniffer

• Another solution on switched hubs is ARP watch – An ARP watch monitors the ARP cache for duplicate entries of a machine – If such duplicates appear, raise an alarm – Problem: false alarms

• Specifically, DHCP networks can have multiple entires for a single machine

Stopping Packet Sniffing • The best way is to encrypt packets securely

– Sniffers can capture the packets, but they are meaningless • Capturing a packet is useless if it just reads as garbage

– SSH is also a much more secure method of connection • Private/Public key pairs makes sniffing virtually useless

– On switched networks, almost all attacks will be via ARP spoofing • Add machines to a permanent store in the cache • This store cannot be modified via a broadcast reply • Thus, a sniffer cannot redirect an address to itself

• The best security is to not let them in in the first place – Sniffers need to be on your subnet in a switched hub in the first place – All sniffers need to somehow access root at some point to start

themselves up

Port Knocking

• Broadly port knocking is the act of attempting to make connections to blocked ports in a certain order in an attempt to open a port

• Port knocking is fairly secure against brute force attacks since there are 65536k combinations, where k is the number of ports knocked

• Port knocking however if very susceptible to replay attacks. Someone can theoretically record port knocking attempts and repeat those to get the same open port again

• One good way of protecting against replay attacks would be a time dependent knock sequence.

User Datagram Protocol • UDP is a stateless, unreliable datagram protocol built on top of IP, that is it lies on

level 4 • It does not provide delivery guarantees, or acknowledgments, but is significantly

faster • Can however distinguish data for multiple concurrent applications on a single

host. • A lack of reliability implies applications using UDP must be ready to accept a fair

amount of error packages and data loss. Some application level protocols such as TFTP build reliability on top of UDP.

– Most applications used on UDP will suffer if they have reliability. VoIP, Streaming Video and Streaming Audio all use UDP.

• UDP does not come with built in congestion protection, so while UDP does not suffer from the problems associated with optimistic ACK, there are cases where high rate UDP network access will cause congestion.

Network Address Translation • Introduced in the early 90s to alleviate IPv4 address space

congestion • Relies on translating addresses in an internal network, to an

external address that is used for communication to and from the outside world

• NAT is usually implemented by placing a router in between the internal private network and the public network.

• Saves IP address space since not every terminal needs a globally unique IP address, only an organizationally unique one

• While NAT should really be transparent to all high level services, this is sadly not true because a lot of high level communication uses things on IP

Translation

• Router has a pool of private addresses 192.168.10.0/24

2/17/2010 Networks: IP and TCP 47

router (nat)

global realm private realm

192.168.10.237

s=192.168.10.237 d=128.148.36. 11

s=128.148.36.179 d=128.148.36.11

s=128.148.36.11 d=128.148.36.179

s=128.148.36.11 d=192.168.10.237

128.148.36.11

IP Packet Modifications

source IP address

type of service total length

ident

header checksum

destination IP address

options

data

vers len

flags fragment offset

time to live proto

padding

0 31

Modified on input

Modified on output

????

Computed

Firewalls, Tunnels, and Network Intrusion Detection

1

Firewalls• A firewall is an integrated collection of security

measures designed to prevent unauthorized electronic access to a networked computer system.

• A network firewall is similar to firewalls in building construction, because in both cases they are intended to isolate one "network" or "compartment" from another.

2

Firewall Policies• To protect private networks and individual machines

from the dangers of the greater Internet, a firewall can be employed to filter incoming or outgoing traffic based on a predefined set of rules called firewall policies.

3

Trusted internal network

Firewall policies

UntrustedInternetet

p

Policy Actions• Packets flowing through a firewall can have one of three outcomes:

– Accepted: permitted through the firewall

– Dropped: not allowed through with no indication of failure

– Rejected: not allowed through, accompanied by an attempt to inform the source that the packet was rejected

• Policies used by the firewall to handle packets are based on several properties of the packets being inspected, including the protocol used, such as:

– TCP or UDP

– the source and destination IP addresses

– the source and destination ports

– the application-level payload of the packet (e.g., whether it contains a virus).

42

1

Blacklists and White Lists• There are two fundamental approaches to creating firewall policies (or

rulesets) to effectively minimize vulnerability to the outside world while maintaining the desired functionality for the machines in the trusted internal network (or individual computer).

• Blacklist approach

– All packets are allowed through except those that fit the rules defined specifically in a blacklist.

– This type of configuration is more flexible in ensuring that service to the internal network is not disrupted by the firewall, but is naïve from a security perspective in that it assumes the network administrator can enumerate all of the properties of malicious traffic.

• Whitelist approach

– A safer approach to defining a firewall ruleset is the default-deny policy, in which packets are dropped or rejected unless they are specifically allowed by the firewall.

5

Firewall Types

• packet filters (stateless)– If a packet matches the packet filter's set of rules, the

packet filter will drop or accept it

• "stateful" filters– it maintains records of all connections passing through it and can

determine if a packet is either the start of a new connection, a part of an existing connection, or is an invalid packet.

• application layer– It works like a proxy it can “understand” certain applications and

protocols. – It may inspect the contents of the traffic, blocking what it views as

inappropriate content (i.e. websites, viruses, vulnerabilities, ...)

62

1

Stateless Firewalls• A stateless firewall doesn’t maintain any remembered context

(or “state”) with respect to the packets it is processing. Instead, it treats each packet attempting to travel through it in isolation without considering packets that it has processed previously.

7

Trusted internalnetwork

SYNSeq = xPort=80

SYN-ACKSeq = y

Ack = x + 1

ACKSeq = x + 1Ack = y + 1

Allow outbound SYN packets, destination port=80 Allow inbound SYN-ACK packets, source port=80

Client

Server

Firewall

Stateless Restrictions

• Stateless firewalls may have to be fairly restrictive in order to prevent most attacks.

8


SYNSeq = yPort=80

Allow outbound SYN packets, destination port=80 Drop inbound SYN packets,Allow inbound SYN-ACK packets, source port=80

Client Attacker(blocked)

Firewall

2

1

Statefull Firewalls

• Stateful firewalls can tell when packets are part of legitimate sessions originating within a trusted network.

• Stateful firewalls maintain tables containing information on each active connection, including the IP addresses, ports, and sequence numbers of packets.

• Using these tables, stateful firewalls can allow only inbound TCP packets that are in response to a connection initiated from within the internal network.

9

Statefull Firewall Example• Allow only requested TCP connections:

10


SYNSeq = xPort=80

SYN-ACKSeq = y

Ack = x + 1

ACKSeq = x + 1Ack = y + 1

Allow outbound TCP sessions,destination port=80

Client

SYN-ACKSeq = yPort=80 Attacker(blocked)

Established TCP session:(128.34.78.55, 76.120.54.101)

128.34.78.55

76.120.54.101

Firewall state table

Server

Firewall

2

1

Tunnels

• The contents of TCP packets are not normally encrypted, so if someone is eavesdropping on a TCP connection, he can often see the complete contents of the payloads in this session.

• One way to prevent such eavesdropping without changing the software performing the communication is to use a tunneling protocol.

• In such a protocol, the communication between a client and server is automatically encrypted, so that useful eavesdropping is infeasible.

11

Tunneling Prevents Eavesdropping• Packets sent over the Internet are automatically encrypted.

12

ServerClient

Tunneling protocol

(does end-to-end encryption and decryption)

Payloads are encrypted here

TCP/IPTCP/IP

UntrustedInternet

2

1

Secure Shell (SSH)• A secure interactive command session:

1. The client connects to the server via a TCP session.

2. The client and server exchange information on administrative details, such as supported encryption methods and their protocol version, each choosing a set of protocols that the other supports.

3. The client and server initiate a secret-key exchange to establish a shared secret session key, which is used to encrypt their communication (but not for authentication). This session key is used in conjunction with a chosen block cipher (typically AES, 3DES) to encrypt all further communications.

4. The server sends the client a list of acceptable forms of authentication, which the client will try in sequence. The most common mechanism is to use a password or the following public-key authentication method:

a) If public-key authentication is the selected mechanism, the client sends the server its public key.

b) The server then checks if this key is stored in its list of authorized keys. If so, the server encrypts a challenge using the client’s public key and sends it to the client.

c) The client decrypts the challenge with its private key and responds to the server, proving its identity.

5. Once authentication has been successfully completed, the server lets the client access appropriate resources, such as a command prompt.

13

IPSec

• IPSec defines a set of protocols to provide confidentiality and authenticity for IP packets

• Each protocol can operate in one of two modes, transport mode or tunnel mode. – In transport mode, additional IPsec header

information is inserted before the data of the original packet, and only the payload of the packet is encrypted or authenticated.

– In tunnel mode, a new packet is constructed with IPsec header information, and the entire original packet, including its header, is encapsulated as the payload of the new packet.

1

Virtual Private Networking (VPN)

• Virtual private networking (VPN) is a technology that allows private networks to be safely extended over long physical distances by making use of a public network, such as the Internet, as a means of transport.

• VPN provides guarantees of data confidentiality, integrity, and authentication, despite the use of an untrusted network for transmission.

• There are two primary types of VPNs, remote access VPN and site-to-site VPN.

15

Types of VPNs• Remote access VPNs allow authorized clients to access a

private network that is referred to as an intranet. – For example, an organization may wish to allow employees

access to the company network remotely but make it appear as though they are local to their system and even the Internet itself.

– To accomplish this, the organization sets up a VPN endpoint, known as a network access server, or NAS. Clients typically install VPN client software on their machines, which handle negotiating a connection to the NAS and facilitating communication.

• Site-to-site VPN solutions are designed to provide a secure bridge between two or more physically distant networks. – Before VPN, organizations wishing to safely bridge their private

networks purchased expensive leased lines to directly connect their intranets with cabling.

162

1

Intrusion Detection Systems• Intrusion

– Actions aimed at compromising the security of the target (confidentiality, integrity, availability of computing/networking resources)

• Intrusion detection– The identification through intrusion signatures

and report of intrusion activities

• Intrusion prevention– The process of both detecting intrusion activities

and managing automatic responsive actions throughout the network

17

IDS Components• The IDS manager compiles data from the IDS sensors to

determine if an intrusion has occurred. • This determination is based on a set of site policies, which

are rules and conditions that define probable intrusions. • If an IDS manager detects an intrusion, then it sounds an

alarm.

18

UntrustedInternet

IDS Manager

IDS Sensor

router router

DSS S SSSS Mana

router

DS SeS nsoso IDS SensorDS SeS nso

Firewall

2

1

Intrusions• An IDS is designed to detect a number of threats, including the following:

– masquerader: an attacker who is falsely using the identity and/or credentials of a legitimate user to gain access to a computer system or network

– Misfeasor: a legitimate user who performs actions he is not authorized to do– Clandestine user: a user who tries to block or cover up his actions by deleting

audit files and/or system logs• In addition, an IDS is designed to detect automated attacks and threats,

including the following:– port scans: information gathering intended to determine which ports on a

host are open for TCP connections– Denial-of-service attacks: network attacks meant to overwhelm a host and

shut out legitimate accesses– Malware attacks: replicating malicious software attacks, such as Trojan

horses, computer worms, viruses, etc. – ARP spoofing: an attempt to redirect IP traffic in a local-area network– DNS cache poisoning: a pharming attack directed at changing a host’s DNS

cache to create a falsified domain-name/IP-address association

19

Possible Alarm Outcomes• Alarms can be sounded (positive) or not (negative)

20

Intrusion Attack No Intrusion Attack

AlarmSounded

NoAlarm

Sounded

True Positive False Positive

True NegativeFalse Negative 2

1

The Base-Rate Fallacy

• It is difficult to create an intrusion detection system with the desirable properties of having both a high true-positive rate and a low false-negative rate.

• If the number of actual intrusions is relatively small compared to the amount of data being analyzed, then the effectiveness of an intrusion detection system can be reduced.

• In particular, the effectiveness of some IDSs can be misinterpreted due to a statistical error known as the base-rate fallacy.

• This type of error occurs when the probability of some conditional event is assessed without considering the “base rate” of that event.

21

Base-Rate Fallacy Example• Suppose an IDS is 99% accurate, having a 1% chance of

false positives or false negatives. Suppose further…• An intrusion detection system generates 1,000,100 log

entries.• Only 100 of the 1,000,100 entries correspond to actual

malicious events.• Because of the success rate of the IDS, of the 100 malicious

events, 99 will be detected as malicious, which means we have 1 false negative.

• Nevertheless, of the 1,000,000 benign events, 10,000 will be mistakenly identified as malicious. That is, we have 10,000 false positives!

• Thus, there will be 10,099 alarms sounded, 10,000 of which are false alarms. That is, roughly 99% of our alarms are false alarms.

22

IDS Data• In an influential 1987 paper, Dorothy Denning identified

several fields that should be included in IDS event records:

– Subject: the initiator of an action on the target

– Object: the resource being targeted, such as a file, command, device, or network protocol

– Action: the operation being performed by the subject towards the object

– Exception-condition: any error message or exception condition that was raised by this action

– Resource-usage: quantitative items that were expended by the system performing or responding to this action

– Time-stamp: a unique identifier for the moment in time when this action was initiated

23

Types of Intrusion Detection Systems• Rule-Based Intrusion Detection

– Rules identify the types of actions that match certain known profiles for an intrusion attack, in which case the rule would encode a signature for such an attack. Thus, if the IDS manager sees an event that matches the signature for such a rule, it would immediately sound an alarm, possibly even indicating the particular type of attack that is suspected.

• Statistical Intrusion Detection– A profile is built, which is a statistical representation of the typical

ways that a user acts or a host is used; hence, it can be used to determine when a user or host is acting in highly unusual, anomalous ways.

– Once a user profile is in place, the IDS manager can determine thresholds for anomalous behaviors and then sound an alarm any time a user or host deviates significantly from the stored profile for that person or machine.

242

1

dispensa

Documents

Transcript of dispensa