La firma del file apk di Android con il digest SHA1 è abbastanza sicura?

5

Esempio di riga di comando di Google per la firma di file apk:

$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore my_application.apk alias_name

fonte: link

Come sapete, sia MD5 che SHA1 sono considerati seriamente imperfetti (con MD5 malamente rotto anche nella pratica). Quindi firmare i file apk di Android con hash SHA1 abbastanza sicuri? Se no, i ragazzi di Google dovrebbero saperlo e mi chiedo perché abbiano fornito un esempio del genere. Posso usare un altro algoritmo per la firma di Android Apk?

    
posta user273084 30.03.2016 - 19:05
fonte

2 risposte

5

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ì:

  1. L'attaccante crea un paio di app, una onesta e una maliziosa, che ha un hash dello stesso valore.
  2. L'attaccante invia la prima app a qualcuno che può firmare l'app.
  3. Il firmatario ispeziona a fondo il codice dell'app, vede che tutto sembra a posto e lo firma.
  4. 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 .

    
risposta data 30.03.2016 - 19:39
fonte
1

La firma non ha alcun accordo o dipendenza in ciò che viene firmato: è una forza / debolezza di un alge crittografico proiettata sull'oggetto firmato. Prova SHA-512 o qualsiasi membro SHA-2, dovrebbe funzionare. L'esempio prende piede in un momento molto tempo fa quando è stato scritto, quindi è solo obsoleto.

    
risposta data 30.03.2016 - 19:21
fonte

Leggi altre domande sui tag