Feeds:
Posts
Comments

Posts Tagged ‘Crittografia’

Man in the middle - fonte OWASP - Man in the middle – fonte OWASP –

Dopo alcuni mesi (Moxie Marlinspike e Dan Kaminsky, Defcon e Blackhat) si riparla di una vulnerabilità alle implementazioni SSL (API crittografiche) che, di fatto, prestano il fianco ad un attacco di tipo man in the middle nonchè a tecniche di phishing.

Perchè se ne riparla dopo poco più di due mesi? E’ proprio di questi giorni la pubblicazione di un certificato (e chiave privata) attribuito a PayPal carpita proprio grazie alla vulnerabilità descritta da Moxie Marlinspike al BlackHat USA nel luglio di quest’anno (vedi video dell’intervento al defcon 17).

Frutto di tecniche di parsing datate e usate nelle librerie crittografiche dei client che implementano e usano lo strato SSL (per cui non solo browser web ma anche client di posta, instant messaging, client irc,VPN SSL, etc) e di tool appositi (sslsniff).

In particolare, questa vulnerabilità sfrutta la struttura del certificato X.509 del certificato e le informazioni in esso contenute usandole a proprio piacimento in quel procedimento di validazione a cascata della fiducia.

La catena di fiducia tra il sito interessato e la Certification Authority (CA) funziona come descritto sotto

Root CA -> Intermediate CA -> Intermediate CA -> .. -> Intermediate CA -> esempio.com

Cosa dovrebbe avvenire:

  1. verifica che il nome del nodo foglia è lo stesso del sito a cui ci si sta collegando
  2. verifica che il certificato è valido, non è scaduto, revocato, etc
  3. Controllo della firma (signature)
  4. Se tale firma della CA appartiene alla nostra lista di una Root CA trusted il processo di conclude positivamente altrimenti si ripetono nuovamente gli step dopo aver risalito la catena di un livello.

Questo è lo scenario incriminato:

Root CA -> Intermediate CA -> Intermediate CA -> .. ->Intermediate CA -> sitomalevolo.com -> esempio.com

Purtroppo, questo scenario, nelle condizioni di vulnerabilità indicate nel paper di Marlinspike al Blackhat di Las Vegas, sembra essere del tutto lecito: le firme sono validate, i certificati non sono scaduti/revocati, il procedimento indicato di verifica si conclude con una Root CA trusted “embedded” incorporata nel browser.

Questo significa però che abbiamo costruito un certificato VALIDO per esempio.com ma che in nessun modo rappresentiamo in quanto siamo legati a sitomalevolo.com

Affinchè questo funzioni, viene sfruttata la debolezza di una codifica del CN (Common Name) Subject del PKCS #10 in cui il campo (stringa) viene “chiuso” da un particolare valore null ().

Quando viene effettuato il controllo 1), in questo scenario vengono confrontate due stringhe di lunghezza potenzialmente diversa.

Tenendo conto che la stringa si conclude con il carattere , il parsing considera solamente i primi n caratteri fino al valore null ().

Quindi se in un certificato X509 è specificato di essere www.esempio.comsitomalevolo.com le verifiche vengono effettate sulla precedente stringa (fino al campo ) e l’indirizzo a cui vogliamo collegarci (www.esempio.com).
A questo punto si hanno tutti gli elementi per effettuare un MITM che generi il certificato apposito e si interponga trasparentemente tra le parti (molte CA rilasciano dei certificati se il richiedente è l’owner specificato DOPO il valore null).

Per quanto riguarda Mozilla, i security advisor riportano di avere chiuso la falla a partire dalla versione di firefox 3.5 e 3.0.13 (vedi variante attacco su 3.0.11 vulnerabile), Thunderbird dalla 2.0.0.23, SeaMonkey dalla 1.1.18 e NSS dalla 3.12.3

Al momento sembra che le crypto API di windows siano vulnerabili.

Ci sono ripercussioni e impatti anche nel campo delle applicazioni mobile.

PayPal ha nel frattempo sospeso l’account di Moxie Marlinspike.

Raccomandazioni: massima attenzione sulle transazioni in https e scrivere manualmente il link sul browser (possibilmente firefox, aggiornato) e mai fidarsi di link specialmente contenute in messaggi di posta elettronica.

_______
Taccuino

Read Full Post »

random-generationI numeri casuali sono cruciali per diverse applicazioni, dalle simulazioni alla statistica e soprattutto sono determinanti per gli algoritmi crittografici.

Le diverse tecniche di generazione (anche quelle che sfruttano fenomeni fisici imprevedibili, disturbi elettrici o decadimento radiattivo) non riescono a garantire un elevato throughput di numeri prodotti.

Un gruppo di scienziati giapponesi dell’Università Takushoku,  Saitama University e della Ntt Corporation ha ottenuto una produzione di numeri casuali al rate di 1.7 Gbps pari a 10 volte quello ottenibile attualmente con i fenomeni fisici sopra indicati. Gli stessi scienziati confidano di raggiungere i 10 Gbps con affinamenti successivi.

Il risultato è stato ottenuto riflettendo parte del segnale laser verso il laser stesso tramite  riflettori esterni. Questa sorta di sovrapposizione causa un comportamento imprevedibile, non deterministico e caotico (caos) e una rapida ed ampia oscillazione dell’intensità della luce. Come risultato, i  segnali luminosi elettromagnetici generati sono estremamente complessi e coprono molto rapidamente un range molto elevato di valori.

Per i fisici e per chi volesse approfondire la tematica e volesse maggiori dettagli sull’esperimento è disponibile un abstract e un paper Fast physical random bit generation with chaotic semiconductor lasers in Nature Photonics.

Chiaramente è da verificare quanto possano essere validi, complessi e realmente casuali questi numeri per le reali applicazioni crittografiche ma di sicuro rappresenta un grosso passo avanti nella loro generazione.

Read Full Post »

Come già detto, il termine per la presentazione delle domande di partecipazione alla call del NIST per l’individuazione di una nuova famiglia di algoritmi di hash è scaduto lo scorso 31 ottobre.

I contributi presentati sono stati 64 (27 dei quali di pubblico dominio al momento, ndr) e sono decisamente tanti se confrontati con l’ultima call che vide la nascita di AES nel 1998 in cui le proposte furono solamente 16. Singolare che in entrambi i casi il numero delle proposte sia proprio una potenza di 2. Inoltre, alcuni sono stati già definiti “broken” ad una prima criptanalisi.

CI si aspetta adesso un periodo di qualche anno per la selezione dell’algoritmo “migliore” in cui i gruppi che hanno presentato la propria proposta effettuerà criptanalisi sul proprio e sull’altrui contributo. Questo periodo, estremamente importante per la selezione e rafforzamento delle proposte stesse, vedrà NIST da una parte e comunità crittografiche dall’altra apportare tutti quei contributi utili ad ordinare le proposte per funzionalità, efficienza, prestazioni e robustezza.

Per la parte finale del processo selettivo ci si aspetta pertanto di concentrarsi su un sottoinsieme di algoritmi particolarmente validi e completi.

Schneier e altri co-autori (Niels Ferguson, Stefan Lucks, Doug Whiting, Mihir Bellare, Tadayoshi Kohno, Jon Callas e Jesse Walker) hanno presentato Skein.

Skein è una nuova famiglia di funzioni hash crittografiche. Il suo design unisce velocità, sicurezza, semplicità e una notevole flessibilità, il tutto all’interno di un package modulare facile da analizzare

si legge nel loro executive summary.

Skein, continuano gli autori, è veloce, sicuro, semplice, flessibile, efficiente e progettato da un team di esperti che hanno messo a fattor comune le loro esperienze.

Dall’executive summary una rapida overview.

Velocità
Skein-512 effettua l’hash dei dati a 6,1 cicli di clock per byte su una CPU a 64 bit. Ciò significa che con un processore Core 2 Duo x64 a 3,1 GHz Skein effettua l’hash dei dati a 500 MB al secondo per ciascun core — è quindi circa due volte più veloce di SHA-512 e tre volte più veloce di SHA-256. Una modalità hash-tree velocizza ancor di più le implementazioni parallelizzabili. Skein è veloce anche con i messaggi corti: Skein-512 effettua l’hash di messaggi corti in circa 1000 cicli di clock.
Sicurezza

 

 

 

Il suo design conservativo si basa sul block cipher Threefish. Al momento il nostro migliore attacco contro Threefish-512 è su 25 di 72 round, per un fattore di sicurezza di 2,9. Per fare un confronto, a uno stadio analogo del processo di standardizzazione, l’algoritmo di cifratura AES aveva un attacco su 6 di 10 round, per un fattore di sicurezza di 1,7 soltanto.
Semplicità

Utilizzando solamente tre operazioni primitive, la funzione di compressione di Skein può essere facilmente compresa e ricordata.

Flessibilità

Skein viene definito per tre dimensioni di stato interno (256 bit, 512 bit e 1024 bit), e per qualsiasi dimensione di output.

Un sistema di argomenti espandibile e completamente opzionale rende Skein uno strumento efficace da impiegare per un gran numero di funzioni: un PRNG (generatore di numeri pseudo-casuali), uno stream cipher, una funzione di derivazione di chiavi, autenticazione senza le informazioni addizionali del HMAC (Hashed Message Authentication Code), e la possibilità di personalizzazione.

Efficienza

Skein è efficiente su una grande varietà di piattaforme, sia hardware che software. Skein-512 può essere implementato in circa 200 byte di stato. Piccoli dispositivi, come le smart card a 8 bit, possono implementare Skein-256 utilizzando circa 100 byte di memoria. Dispositivi più grandi possono implementare le versioni maggiori di Skein per raggiungere velocità più elevate.

Le caratteristiche sulla carta sembrano esserci tutte.

Per gli addetti ai lavori ecco il paper ed i sorgenti con test vector.

Per gli altri, leggete, documentatevi e aspettate fiduciosi.

 

 

 

 

 

 

 

 

 

 

 

Read Full Post »