MD5 e SHA-1 hanno difetti riguardo a collisioni (nel caso di SHA-1, questi difetti sono "teorici" in quanto non è stata ancora prodotta alcuna collisione effettiva). Le collisioni non sono necessariamente un problema, a seconda del contesto.
Una collisione è una coppia di input m e m ' che sono distinti, ma hash allo stesso valore. Poiché gli algoritmi di firma operano su messaggi hash, una firma sul primo messaggio di una coppia di collisioni sarebbe valida anche per l'altro messaggio, meccanicamente. Le collisioni sono distinte da second pre-imaging nel senso seguente:
- in un secondo preimage, l'attaccante viene mostrato un messaggio m e viene sfidato a trovare un distinto m ' che collide con m ;
- in caso di collisione, l'attaccante sceglie sia m sia m '.
Al momento, non è noto un secondo attacco preimage su SHA-1 e solo un attacco di preimage secondo molto molto teorico su MD5 (sforzo di più di 2 120 ).
La firma delle app riguarda responsabilità . Normalmente non vorresti installare un'app che potrebbe fare cose cattive; la firma non garantisce che l'app non fa cose cattive, ma dà potere di ritorsione all'utente: il firmatario non dovrebbe essere in grado di negare di aver firmato l'app. Questo è importante da ricordare: la firma fa il suo lavoro fintanto che consente di risalire al colpevole.
Un utente malintenzionato potrebbe voler creare due versioni della sua app, l'hashing delle due versioni con lo stesso valore e quindi utilizzare lo stesso valore di firma. Una versione sarebbe "onesta", e l'altra avrebbe dirottato il telefono o emettere cattiveria simile. Ma cosa otterrebbe all'attaccante? Se l'applicazione m e l'applicazione m condividono lo stesso valore di firma, la firma "dimostra" che l'autore dell'applicazione ha scritto veramente entrambi ... il che è completamente vero! La proprietà di sicurezza della firma, la responsabilità, è ancora valida in presenza di collisioni.
Ciò che l'hacker vuole davvero è una seconda preimage: vuole fare un'app male che è firmata da qualcun altro . Per questo, ha bisogno di prendere un'app "onesta" esistente e crearne una nuova che abbia lo stesso valore, permettendogli così di prendere in prestito il valore della firma. Al momento, nessuno sa come farlo con una firma RSA / SHA-1 (o, peraltro, con una firma RSA / MD5).
Le collisioni possono essere un problema quando l'attaccante deve scegliere cosa sarà firmato da qualcun altro. Questo è quello che è successo con una dimostrazione che coinvolge RSA / MD5 e certificati . Questo, tuttavia, non si applica al tuo contesto, quando ciò che firmi è la tua app. Le collisioni su MD5 o SHA-1 sarebbero rilevanti se immaginassimo una situazione che andrebbe così:
- L'attaccante crea un paio di app, una onesta e una maliziosa, che ha un hash dello stesso valore.
- L'attaccante invia la prima app a qualcuno che può firmare l'app.
- Il firmatario ispeziona a fondo il codice dell'app, vede che tutto sembra a posto e lo firma.
- L'utente malintenzionato riutilizza quindi il valore della firma sulla sua app dannosa.
Anche in questo caso, mentre la firma dovrebbe puntare al firmatario, quel firmatario saprebbe, in caso di problemi, che l'app dannosa non è ciò che ha firmato. Infatti, avrebbe semplicemente riesumato l'app "onesta" dalle sue e-mail, dimostrando che sia l'app onesta che quella malevola sono una coppia in collisione per la funzione hash, dimostrando in tal modo l'intento malevolo dell'autore dell'app (non si verificano collisioni di sfortuna, devi farlo apposta).
Riepilogo: i difetti noti di MD5 e SHA-1 in relazione alle collisioni non mettono in pericolo il modello di sicurezza della firma delle app. È comunque una buona idea esaminare l'utilizzo di funzioni più moderne e robuste come SHA-256, ma non c'è urgenza .