Migliorerà la sicurezza se metto entrambe le firme SHA1 e SHA256 all'interno di binari codificati su Windows?

4

La mia applicazione si rivolge a piattaforme che iniziano con Windows 7 a 32 bit. Molti di loro non sono aggiornati (ad esempio potrebbero mancare molti aggiornamenti consigliati da Microsoft).

Dati i vincoli, devo usare la firma SHA1 all'interno del mio spazio utente e dei binari del kernel. Tuttavia, renderà la vita dell'attaccante più difficile se incorporo SHA256?

Sono preoccupato, perché sto cercando di immaginare cosa può fare un attaccante. Come attaccante, il mio obiettivo sarebbe quello di sostituire il binario senza rompere facendo in modo che Windows lo notasse. Non sono sicuro di come Windows verifichi le firme, ma l'idea è di rimuovere la firma SHA256 e fare in modo che il mio binario sostitutivo abbia la stessa firma SHA1. Quindi, quando Windows verificherà i binari dell'app, confronterà le loro firme SHA256 per tutti tranne il mio binario, che ha solo la firma SHA1.

Nota: il mio certificato pubblico ha solo una firma SHA1 incorporata dall'emittente.

    
posta Kentzo 22.07.2015 - 18:02
fonte

3 risposte

4

Tecnicamente, l'uso di SHA-256 non renderà le cose molto più difficili per l'aggressore. A meno che tu sia l'autore dell'attacco.

Le preoccupazioni su SHA-1 riguardano circa collisioni . Si ritiene che SHA-1 sia un po 'debole sotto questo aspetto (generare una collisione SHA-1 è ancora molto costoso, al punto che non è stato ancora fatto neanche una volta, ma abbiamo forti ragioni teoriche per pensare che il collision-finding i metodi che sono stati progettati per attaccare SHA-1 riuscirebbero a trovare una collisione in uno sforzo sostanzialmente inferiore rispetto al 2 80 previsto da una funzione di "hash" perfetta).

Quando firma un pezzo di dati, inizi con l'hashing e il valore hash viene quindi utilizzato nel resto degli algoritmi di generazione e verifica della firma. Per sfruttare una collisione, bisogna immaginare che ci siano due versioni distinte dello stesso software, la seconda è maliziosa e fa cose cattive sul sistema client, ma in modo tale che entrambe producano lo stesso valore quando sono state sottoposte a hash con SHA-1. Se è possibile creare due di questi file, una firma (con SHA-1) calcolata sul primo file si applicherà anche alla seconda e viceversa. Questo aiuta l'aggressore solo in un contesto in cui l'autore dell'attacco può scegliere il file che è stato firmato in primo luogo.

Nel tuo caso, il file originale (quello normale, onesto) è quello che produci tu stesso. Se una collisione aiuta l'attaccante, allora tu sei l'attaccante.

Se non sei l'attaccante, allora quello che l'attaccante deve fare è trovare un secondo preimage : l'attaccante vede il file onesto e non dannoso (che hai firmato) e prova a crea un file modificato con hash allo stesso valore. Questo non è affatto lo stesso problema. Una collisione riguarda la ricerca di m e m tale che m m ma h ( m ) = h ( m '). Un secondo preimage è la stessa cosa tranne che m non è scelto dall'attaccante. Questo è molto più difficile e (per quanto ne sappiamo) non è fattibile con SHA-1. Non c'è alcuna nota, anche teorica, debolezza di SHA-1 che consentirebbe a un aggressore di farlo.

Di conseguenza, passare da SHA-1 a SHA-256 non migliorerebbe le cose. Se l'utente malintenzionato può creare un file dannoso con una firma valida da te, significa che l'autore dell'attacco può effettivamente farti firmare il codice di sua scelta (ad esempio l'attaccante ha compromesso i tuoi computer di sviluppo), e in queste condizioni, SHA-256 non lo fa non bloccare l'utente malintenzionato più di SHA-1.

Tuttavia, i sistemi client potrebbero avere un'altra opinione sull'argomento. Dal punto di vista di un cliente, il processo di firma può andare così:

  • Qualcuno invia al firmatario (tu) alcuni dati da firmare.
  • Controlla i dati da firmare e firmalo se lo trovi opportuno e appropriato. Ad esempio, per il software, si guarda il codice sorgente e si fa la compilazione da soli.

In questo modello, l'attaccante può creare un codice che sembra buono ma, una volta compilato, produce un binario che si scontra con un codice dannoso creato anche dall'attaccante. Sotto questo modello specifico, le collisioni sono un problema, perché l'attaccante è in grado di scegliere sia la versione onesta che quella malevola del software.

Molto probabilmente, non segui questo modello: quando firmi un software, è un software sviluppato da te stesso, non qualcosa presentato da potenziali aggressori. Lo sai. Ma Microsoft non ne è così sicuro e potrebbe decidere che sarebbe troppo rischioso utilizzare una funzione di hash che potrebbe consentire che le collisioni si verifichino.

Quindi probabilmente vorrai passare a SHA-256, non perché SHA-1 sarebbe troppo vulnerabile (questo non è il caso nella tua situazione), ma perché Microsoft potrebbe decidere di rimuovere il supporto SHA-1.

La politica Microsoft è spiegata qui , con l'estratto particolare:

Code signed with SHA-1 certificates that are time stamped before 1 January, 2016 will be accepted until 14 January 2020 (when Server 2008 extended support ends), at latest. This date may be moved earlier if Microsoft decides SHA1 is vulnerable to pre-image attack.

Nota l'ultima frase: il problema riguarda davvero le pre-immagini, non le collisioni.

Dovrai anche acquistare un certificato di firma del codice tale che la firma sul certificato , e su tutti i certificati CA nella catena, usi SHA-256, perché sembra che Windows stia diventando sempre più allergico a SHA-1. Per gli stessi motivi di cui sopra, questo anatema su SHA-1 può essere qualificato come eccessivo, ma Microsoft non ha scelta: Google è intenzionato ad uccidere SHA-1 e Microsoft deve seguire; altrimenti, saranno derisi e derisi.

    
risposta data 22.07.2015 - 20:25
fonte
1

La mia risposta breve: il passaggio da SHA1 a SHA256 per le firme dei file aumenterà a malapena la tua sicurezza, l'unica buona ragione sarebbe quella di rimanere aggiornato con le best practice.

La preoccupazione per SHA-1 e il rischio di collisioni è che potrebbe verificarsi una potenziale decifrazione. Questo ha a che fare con la decrittazione degli hash dopo il fatto: ad esempio, le password in un database possono essere cercate tramite una tabella arcobaleno e questo processo potrebbe essere accelerato attraverso collisioni.

Tuttavia, stai utilizzando SHA per uno scopo diverso: verifica dell'integrità del file. A causa dell'effetto valanga negli algoritmi di hashing, nonostante l'età di SHA1 sarebbe ancora quasi impossibile per un utente malintenzionato inserire codice dannoso o altre modifiche mantenendo la firma precedente.

Quindi, per le sessioni SSL che possono essere archiviate e decifrate dopo il fatto, passare a SHA256 ha senso. Tuttavia, per la convalida dell'integrità del file, probabilmente farà poca differenza. Potrebbe avere senso fornire entrambi gli hash SHA1 e SHA256 solo per ragioni di best practice, ma non conosco alcun metodo di attacco prevedibile che possa sfruttare SHA1 per consentire a uno di modificare i file e mantenere la firma precedente.

    
risposta data 22.07.2015 - 20:02
fonte
0

Se sei preoccupato per la sicurezza di SHA-1 devi sapere che l'uso di SHA-1 su Internet è stato deprecato dal 2011 e solo per darti un suggerimento:

HTTPS sites whose certificate chains use SHA-1 and are valid past 1 January 2017 will no longer appear to be fully trustworthy in Chrome’s user interface.

Ma non c'è nessun attacco di collisione completo di successo noto dalla data in cui hai fatto questa domanda su SHA-1 - ma potrebbe non essere così nei prossimi anni riguardo alla crescente velocità di calcolo dei computer - mentre SHA- 256 è totalmente resistente alle collisioni. Quindi sì, la tua opzione è molto meglio che fare affidamento solo su SHA-1.

    
risposta data 22.07.2015 - 19:07
fonte

Leggi altre domande sui tag