Alfonso Maruccia

Microsoft: stop alla crittografia vulnerabile

Redmond si prepara in anticipo alla futura "apocalisse" degli algoritmi crittografici insicuri annunciando l'abbandono di RC4 e SHA-1. I malware capaci di falsificare i certificati di sicurezza sono giÓ in circolazione da anni

Roma - Il blog Security Research & Defense di Microsoft ha annunciate due importanti novità sul fronte degli algoritmi crittografici, in particolare una raccomandazione di abbandonare l'uso di SHA-1 e una per disabilitare RC4. Entrambe le tecnologie soffrono di vulnerabilità e problemi ben noti da tempo.

Sia SHA-1 che RC4 sono attualmente usati nel campo dei protocolli di sicurezza per le comunicazioni telematiche cifrate (SSL e TLS): nel caso di SHA-1, la tecnologia di hashing crittografico progettata dalla NSA nel 1995 (il che è già tutto dire) è stata già "crackata" anni fa e da tempo si prevedono scenari da "apocalisse" per il normale funzionamento del web moderno nel caso in cui non si ponga rimedio in tempo.

Gli hash (firme digitali) generati tramite SHA-1 sono notoriamente vulnerabili ad attacchi a base di collisioni, dove input diversi possono portare alla creazione di firme identiche con tanti saluti alla sicurezza - soprattutto nel caso dei certificati di sicurezza adottati dall'intero mondo tecnologico per autenticare comunicazioni Internet cifrate, verifica della legittima di software informatico e via elencando.
Non si tratta di un rischio teorico ma della semplice constatazione di un dato di fatto, visto che il famigerato malware Flame - cyber-attacco partito come al solito dalle spie statunitensi con la collaborazione del Mossad israeliano - è riuscito a falsificare le credenziali di Microsoft attaccando un algoritmo di hash crittografico (MD5) meno recente di SHA-1 (1992).

Nel caso di quest'ultimo, Redmond evidenzia una serie di attacchi teorici sviluppati a partire dal 2005 in poi. Microsoft annuncia che non riconoscerà più la validità dei certificati basati su SHA-1 a partire dal 2016, anno per chi gli attacchi a base di collisione dovrebbero essere più che fattibili.

Per quanto riguarda RC4, infine, Microsoft dice che è venuto il tempo di "deprecare" lo storico algoritmo crittografico - in circolazione dal 1987, ben prima che qualsiasi comunicazione telematica raggruppabile sotto il termine-ombrello di Internet potesse ritenersi la norma - e di passare all'uso dello standard TLS1.2 con algoritmo AES-GCM.

Anche RC4 è notoriamente bucato, tanto che l'algoritmo sarebbe alla base della capacità di penetrazione della NSA nelle comunicazioni sulla darknet di Tor recentemente venute alla ribalta nel più ampio scandalo Datagate. L'advisory di sicurezza di Microsoft si accompagna a un aggiornamento per Windows (7, 8/RT, Server 2008 R2 e Server 2012) pensato per disabilitare l'uso di RC4 sui software di Redmond (e Internet Explorer in particolare).

Alfonso Maruccia
Notizie collegate
  • AttualitàFlame, malware a stelle e strisceEnnesima rivelazione imbarazzante per Washington: la Casa Bianca sarebbe direttamente responsabile della creazione del super-malware venuto alla ribalta in queste ultime settimane, dicono fonti anonime
27 Commenti alla Notizia Microsoft: stop alla crittografia vulnerabile
Ordina
  • ... la loro crittografia è affidabilissima e soprattutto PRIVA DI QUALSIASIVOGLIA BACKDOOR NSA.

    Ma fatemi il piacere di guardarvi allo specchio prima di criticare gli altri.
    non+autenticato
  • sono quantomeno dei buffoni

    *qualsiasi* crittografia è vulnerabile se le chiavi non sono esclusivamente nelle mani di chi la usa...

    chi ha le chiavi dei sistemi (sic!) WIn8+ARM con il "SecureBoot" *non* disabilitabile?
    gli utilizzatori? nooooooo...
    le ha *solo* M$ (e, come minimo, anche la NSA, ovviamente...)
    non+autenticato
  • contenuto non disponibile
  • bisogna vedere a cosa ti riferisci il termine "attaccare" privo di contesto non ha senso.
    Facciamo un esempio concreto:
    Poniamo che io trovi una "collisione" su sha-1 pensi che sia sufficiente?
    Il problema è non tanto trovare una collisione ma una collisione su un "plain text" con un signifcato e non con un "signficato a caso" ma con qualcosa che sia esattamente lo scopo che mi prefiggo.

    Esempio pratico :
    ti mando un messaggio con scritto "ci vediamo martedì sera con il pacchetto dei soldoni illegali"

    Ebbene se il mio scopo è cambiare la data da "martedì" a "venerdì" per indurti in trappola la mia unica speranza pratica è che io trovi una collisione (ovvero generi un hash identico) a partire da un testo che non solo contenga "venerdì" e una serie di caratteri a caso ma qualcosa che continui ad avere un senso compiuto e ti induca a portare con te i "soldoni illegali"... il che è francamente del tutto inverosimile.
    Basta che il messaggio sia firmato (oltre che cifrato) e la cosa non funziona mai.
    Quanto alla crittografia devo invece trovare una collisione su una chiave (quella pubblica che è verificabile "outbound" cioè per altra via ad esempio un messaggio precedente o un repository pubblico) che oltre a essere tale (cioè una chiave) corrisponda in modo biunivoco alla parte pubblica (e viceversa) perchè altrimenti non cifra ne decifra una ceppa.
    L'algoritmo di hash (one way) è solo una parte e non la più rilevante di un protocollo basato su chiavi asimmetriche.
    Il fatto che siano teoricamente possibili collisioni non significa che le collisioni in questione (se non hai una fortuna sfacciata e quasi del tutto impossibile) siano utilizzabili.
    ╚ molto più semplice vincere il jack-pot del lotto.
    Questo non significa che il problema non esista sul piano "teorico" significa solo che gli scenari "apocalittici" sono del tutto fuori luogo.
    Puoi tranquillamente fidarti dei messaggi spediti con un "weak" hash.
    Quello di cui non puoi fidarti invece sono le back door e in quel caso puoi avere l'algoritmo più "strong" del mondo ma ti fregano comunque.
    Ora:
    Fatti una domanda e valuta quale dei 2 problemi costituisce un rischio maggiore una piattaforma "proprietaria" fatta in "accordo" con NSA o i messaggi che usano sha-1 (che peraltro comunque nessuno ti obbliga a usare dato che hai a disposizione sha-256 e 512 e molti altri).
    Fatto?
    Occhiolino
    non+autenticato
  • E in più c'è sempre il problema del man in the middle.
    non+autenticato
  • contenuto non disponibile
  • - Scritto da: unaDuraLezione
    > - Scritto da: tucumcari
    >
    > Dipende da chi è l'avversario.
    > Se l'avversario è NSA c'è poco da fare per chi
    > usa prodotti chiusi (e anche perm olti degli
    > altri), ma se l'avversario è più piccolo, gli
    > potrebbe tornare molto utile poterti installare
    > certificati falsi ma
    > validi.
    Se l'avversario è piccolo, rimane da capire come abbia potuto installarmi certificati falsi senza che me ne accorgessi.A bocca aperta
    Forse tanto piccolo non è.
    È meglio partire dal presupposto che dall'altra parte c'è la NSA, sempre.
    non+autenticato
  • - Scritto da: unaDuraLezione
    > - Scritto da: tucumcari
    >
    >
    > > Ebbene se il mio scopo è cambiare la data da
    > > "martedì" a "venerdì" per indurti in
    > trappola
    > la
    > > mia unica speranza pratica è che io trovi una
    > > collisione (ovvero generi un hash identico) a
    > > partire da un testo che non solo contenga
    > > "venerdì" e una serie di caratteri a caso ma
    > > qualcosa che continui ad avere un senso
    > compiuto
    > > e ti induca a portare con te i "soldoni
    > > illegali"... il che è francamente del tutto
    > > inverosimile.
    >
    >
    > Nel caso migliore (per l'attaccante ovviamente) è
    > possibile comporre un 'messaggio' (e stiamo
    > comunque paralndo di dati binari) forgiato
    > partendo da un messaggio arbitrario (quindi
    > l'attaccante sceglie il contenuto) in cui solo
    > pochi byte (le cui posizioni sceglie sempre
    > l'attaccante) vengono modificati dall'algoritmo
    > di cracking per far quadrare la firma
    > hash.

    Problema :
    1) il contenuto lo dovresti conoscere per attuare quello che dici... il problema è che non è così (altrimenti non c'è alcuna necessità di "attaccare")
    2) non c'è alcun "algoritmo di cracking" ma solo collisioni (una o più) e purtroppo bisogna che siano "collisioni sensate"... non "collisioni a caso".

    > Quindi, basta che questi pochi bye stiano in un
    > punto in cui un numero vale l'altro (chessò, la
    > versione del certificato,
    > ...)
    Ammesso (e non concesso) cambiare il version number non ti è per nulla utile.
    E ripeto non è che puoi cambiare un numero x di bit a piacere deve "tornare" l'hash di tutto l'oggetto .

    >
    >
    > > L'algoritmo di hash (one way) è solo una
    > parte
    > e
    > > non la più rilevante di un protocollo basato
    > su
    > > chiavi
    > > asimmetriche.
    >
    >
    > questo sì.

    Lo credo bene... altrimenti perchè sbattersi a disegnare protocolli?

    >
    > > Questo non significa che il problema non
    > esista
    > > sul piano "teorico" significa solo che gli
    > > scenari "apocalittici" sono del tutto fuori
    > > luogo.
    >
    > Beh, dipende da quanta libertà ti lascia il
    > metodo di cracking sulla forgiatura del
    > messaggio.

    Ripeti con me non c'è alcun "metodo di cracking" ma solo collisioni!
    Le funzioni (persino il vituperato MD5) sono "genuinamente" one way!
    Un conto è che ci siano collisioni un altro che l'algoritmo sia (matematicamente parlando) "farlocco".

    Mentre del fatto che una funzione sia "one way" poui ottenere la dimostrazione matematica (chiedere lumi a diffie nel caso o leggere) del fatto che non esistano collisioni possibili non avrai mai dimostrazione matematica.
    Al massimo puoi ridurne la probabilità.
    In parole povere nessuno a questo mondo ti può garantire che sha-256 è privo di collisioni (anzi potrei sostenere ragionevolmente il contrario) ti si può solo garantire che la funzione è "one way" e che la possibilità di collisione è inferiore a quella di md5 o sha-1.
    Tutto qui

    > Io onestamente non conosco il caso di cui si
    > parla, ma se è venuto fuori, posso supporre che
    > il metodo di cracking lasci molta libertà
    > all'attaccante.

    Ancora?
    Di quale "metodo di cracking" vai cianciando?

    >
    >
    > > Fatti una domanda e valuta quale dei 2
    > problemi
    > > costituisce un rischio maggiore una
    > piattaforma
    > > "proprietaria" fatta in "accordo" con NSA o i
    > > messaggi che usano sha-1 (che peraltro
    > comunque
    > > nessuno ti obbliga a usare dato che hai a
    > > disposizione sha-256 e 512 e molti
    > > altri).
    > > Fatto?
    >
    > Dipende da chi è l'avversario.
    > Se l'avversario è NSA c'è poco da fare per chi
    > usa prodotti chiusi (e anche perm olti degli
    > altri), ma se l'avversario è più piccolo, gli
    > potrebbe tornare molto utile poterti installare
    > certificati falsi ma
    > validi.
    E come farebbe di grazia? tu "installi" certificati in base a quale ragionamento?
    E sopratutto sei sicuro di avere dei motivi per metterli nella tua "trust list" e perchè?
    Se è per quello te ne posso mandare un milione di certificati (veri falsi mezzi veri e mezzi falsi a tuo e mio piacimento) la questione resta... se i valori sono (come sono) differenti da quelli che hai (o avevi) in precedenza perchè dovresti crederci?
    A bocca aperta
    Poi per carità se quando installi un certificato non ci guardi dentro... puoi installare qualunque cosa tanto vale che tu scarichi direttamente il programma di crittografia dal sito della NSA.
    Fai prima...
    A bocca aperta
    non+autenticato
  • contenuto non disponibile
  • - Scritto da: unaDuraLezione
    > - Scritto da: fante lesto
    > > - Scritto da: unaDuraLezione
    > > > - Scritto da: tucumcari
    >
    > > Problema :
    >
    > > 2) non c'è alcun "algoritmo di cracking" ma
    > solo
    > > collisioni
    >
    > secondo te le collisioni sono trovate per caso
    > oppure calcolate a
    > mano?
    > Evidentemente no. Si sfrutta la debolezza
    > dall'hash di turno per individuare un
    > metodo.
    > Il metodo è l'algoritmo.
    > E tale algoritmo ha ben diritto di chiamarsi
    > algoritmo di
    > cracking.
    Il "metodo" non esiste in termini di "algoritmo" esiste solo la ricerca di collisioni e il problema è che i bit (pochi o tanti) devono essere uguali TUTTI!
    E partire dalla stessa stringa di hash (quindi lo stesso plain text) di cui vorresti "falsificare" l'hash.

    L'entropia che introduci (e questo è dimostrato matematicamente) cambiando un solo bit equivale a quella introdotta cambiandoli tutti.
    Non mi pareva difficile da capire (leggi ripeto).

    >
    >
    >
    >
    > > > Quindi, basta che questi pochi bye
    > stiano in
    > un
    > > > punto in cui un numero vale l'altro
    > (chessò,
    > la
    > > > versione del certificato,
    > > > ...)
    >
    > > E ripeto non è che puoi cambiare un numero x
    > di
    > > bit a piacere deve "tornare" l'hash di tutto
    > > l'oggetto
    >
    > gli hash sono firme di pochi bit, quindi, nel
    > caso peggiore possibile (perchè l'algoritmo è
    > pessimo), ti bastano altrettanti bit in un luogo
    > a tua
    > scelta.

    Leggi sopra e ricomincia da capo!

    >
    > Basta pensare al più scarso degli algoritmi
    > possibili, ovvero la parità: un bit/byte/quello
    > che vuoi come firma di tutto e si scardina
    > esattamente con un bit/byte/quello che vuoi in un
    > punto arbitrario del messaggio arbitrariamente
    > forgiato.
    Peccato che non sia un algoritmo one way!
    Ci sarà o no secondo te un motivo (leggere fa bene) se si usano quegli algoritmi?

    > SO che gli HASH seri sono fatti ni modo che non
    > debba succedere, ma visto che stiamo parlando di
    > debolezze...

    No stiamo parlando di collisioni non di "debolezze" è proprio questo che non ti entra in testa.
    L'algoritmo MD5 in se non ha nulla che non va!

    >
    >
    >
    >
    > > Ripeti con me non c'è alcun "metodo di
    > cracking"
    > > ma solo
    > > collisioni!
    >
    >
    > Ripeti con me: "le collisioni non si trovano per
    > magia, ma con un metodo che sfrutta le
    > caratteristiche del sistema di
    > HASH"

    Non esiste tale "metodo" è un mero calcolo probabilistico quello che devi applicare.

    >
    > > del
    > > fatto che non esistano collisioni possibili
    > non
    > > avrai mai dimostrazione
    > > matematica.
    >
    > Infatti si dimostra in due passaggi il CONTRARIO:
    > basta contare i membri dell'insieme delle
    > stringhe prima dell'hash (2^numero arbitrario) e
    > quello delle stringhe HASH (2^lunghezza della
    > firma).
    > Il primo insieme ha un numero nifinitamente
    > maggiore di elementi, quindi moltissimi elementi
    > del primo insieme NECESSARAMENTE vengono mappati
    > nello stesso elemento del secondo
    > insieme
    La "lunghezza della firma" (o meglio dell'hash cifrato con la chiave pubblica) non c'entra nulla quello che ti interessa è la lunghezza dell'Hash.
    E la probabilità di collisione in una funzione "one way" (proprio perchè è "one way") è tutt'altro che "esponenzialmente proporzionale" alla sua lunghezza come tu sostieni.
    ╚ semplice matematica fammi un favore leggi prima di lanciarti in ipotesi ok?

    >
    >
    > > Al massimo puoi ridurne la probabilità.
    > > In parole povere nessuno a questo mondo ti
    > può
    > > garantire che sha-256 è privo di collisioni
    > (anzi
    > > potrei sostenere ragionevolmente il
    > contrario)
    >
    > Ragionavolmente?
    > Suvvià è una banale questione di cardinalità
    >
    è qui che ti sbagli altrimenti non ci sarebbe alcun bisogno che la funzione fosse "one way" (cioè non reversibile).
    il problema ripeto non è "trovare una collisione a caso".
    è trovare quella "giusta" è li che cessa di essere un banale problema di "cardinalità".
    non+autenticato
  • contenuto non disponibile
  • - Scritto da: unaDuraLezione
    > - Scritto da: tucumcari fante lesto
    >
    > > Il "metodo" non esiste in termini di
    > "algoritmo"
    > > esiste solo la ricerca di collisioni
    >
    > non ho tempo (ne fiato), mi fermo qui.
    > Sappi solo che ciò che hai scritto fa ribaltare
    > nella bara i fondatori dell'informatica
    > teorica.

    Direi che è vero per quello che hai scritto più che altro.

    > La ricerca delle collisioni, COMUNQUE AVVENGA, è
    > un metodo, quindi traducibile in algoritmo,
    > quindi implementabile (ancora non hai risposto,
    > lo fanno a
    > mano????).

    Se per "a mano" intendi "brute force" si!
    Lo fanno "a mano" e il "brute force" non è un algoritmo ne un metodo!
    Per questo motivo ci hanno messo tanto a verificare che le collisioni erano possibili in MD5 e ancora più in SHA-1.

    > Che termini presto, tardi o non termini affatto
    > il suo lavoro è un altro paio di maniche e
    > dipende dalla bontà dall'algoritmo di HASH e
    > dalla bontà del metodo di rilevamento delle
    > collisioni.

    Ripeto non c'è alcun "metodo".
    Il "brute force" non è un "metodo" è un mezzo (esattamente come una calcolatrice invece che carta e penna).

    >
    >
    > edit: solo un ppunto sull'ultima frase:
    > > il problema ripeto non è "trovare una
    > collisione a
    > caso".
    > > è trovare quella "giusta" è li che cessa di
    > essere
    >
    > > un banale problema di "cardinalità".
    >
    > falso: se il messaggio forgiato è modificabile
    > per una quantità di bit superiore alla lunghezza
    > della firma (HASH è sottointeso, non stiamo
    > parlando di crottgrafia ma solo dell'HASH) allora
    > la parte variabile del messaggio
    >
    ha una cardinalità almeno uguale a
    > quella dell'insieme delle firme HASH
    > possibili.
    > Quindi era e rimane una mera questione di
    > cardinalità.
    No la cardinalità non è affatto quella la cardinalità (in senso stretto) anche se ti bastasse è pari alla lunghezza dell'Hash e alla lunghezza del plain text sommati.
    ad esempio se hai una cardinalità di 2048 bit (pari a 256 miseri byte di testo) che è 160 (bit di sha1)+2048 per un totale di 2^2208 si ti sembra poco accomodati pure!
    Vedi il problema è che non contano "solo" i bit della funzione di hash ma TUTTI i bit come ti ho già spiegato!
    I bit "minimi" che contano sempre la somma di tutto ciò che devi cambiare più quelli di hash!
    E la lunghezza appunto rimane invariata qualunque cosa tu faccia a meno che tu non trovi la funzione "inversa" a quella di hash ma in tal caso non sarebbe per definizione una funzione "one way".
    Il che ripeto è un fatto dimostrabile matematicamente e non ha nulla a che vedere con la lunghezza del valore generato dalla funzione che di per se sarebbe pure "abbordabile" in alcuni casi 128 bit per md5 che renderebbero possibile persino un "birthday attack"... peccato che ci siano anche gli "altri" bit... quelli del "plaintext" e ripeto non possono essere bit a caso.
    Per darti una idea di quanto queste cose siano una "novità" ti cito questo pezzetto tratto da Schneier:

    "Nel 1996 Dobbertin annunciò una collisione della funzione di compressione MD5. Anche se non rappresentava un attacco alla funzione hash MD5 completa, fu sufficiente a molti crittografi per raccomandare di passare ad un sostituto come il WHIRLPOOL, SHA-1 o RIPEMD-160".

    Il che è una semplice misura di "manutenzione" non una "catastrofe".
    N.B.
    Ron Rivest pubblicò MD5 nel 1991 e viene tutt'ora usato (per alcune cose) senza che nessuno abbià trovato il modo "pratico" di sfruttare concretamente le collisioni per contenuti "sensati"...
    Non casualmente viene correntemente usato come check ad esempio sul codice dei programmi eseguibili.
    Il che è più che sensato dato che non puoi (ammesso che trovi una collisione) fare eseguire codice binario "a caso" anche se "collidente" dato che non funziona.
    non+autenticato