Sto attualmente scrivendo un'app di autenticazione basata su RSA, per Android che dovrebbe essere impossibile da copiare, anche se hai accesso fisico a un telefono senza lockscreen / PIN.
Tuttavia, l'HSM all'interno del telefono, che assicura che la chiave privata non possa mai lasciare la memoria, sia solo "usato", supporta solo il riempimento di PKCS 1.5 a causa di un bug nell'implementazione di bouncycastle.
I messaggi crittografati, saranno diversi ogni volta (nonce) quindi non c'è possibilità di osservare che due messaggi cifrati sono identici sul filo.
Un attaccante o un avversario, pur non avendo accesso al telefono, non ha accesso a un oracolo di riempimento. L'app funziona facendo in modo che l'utente esegua la scansione di un QR crittografato e questo decrittografato QR crittografato in un codice OTP. Sì, l'utente malintenzionato può visualizzare, su una pagina di phishing o una connessione dirottata, un codice QR contenente errori di padding e osservare se l'utente procede con l'autenticazione (entra in un OTP valido) oppure no, ma quello che ho letto su alcune pagine, un oracle di riempimento attacco richiede milioni di "test" contro il padding.
Quando l'attaccante o l'avversario ha accesso al telefono, l'attaccante può usare il telefono stesso come padding oracle, ma anche, quando ha accesso al telefono, l'attaccante è in grado di decifrare i messaggi arbitary usando comunque l'app.
Gli obiettivi di sicurezza che devono essere soddisfatti è:
-
Mentre l'autore dell'attacco non ha accesso al telefono, l'autore dell'attacco non dovrebbe essere in grado di autenticarsi.
-
Se l'utente malintenzionato ha accesso al telefono, anche per un lungo periodo, dovrebbe essere in grado di autenticarsi, ma non estrarre la chiave privata.
-
Quando l'utente malintenzionato non ha più accesso al telefono, ad esempio se l'attaccante è un dipendente precedente che è stato licenziato e ha quindi attivato il telefono, l'utente malintenzionato non dovrebbe più essere in grado di autenticarsi, anche se in precedenza aveva accesso al telefono e, anche se la coppia di chiavi all'interno dell'hardware sicuro, non è stata modificata.
In questa pagina, la risposta menziona il suo possibile estrarre la chiave privata, montando un attacco oracle padding: Quale specifica debolezza di padding fa l'indirizzo OAEP nella RSA?
Tuttavia, la pagina di Wikipedia, non menziona alcuna rivelazione delle chiavi private: link
Ma la pagina wikipedia menziona, usando l'oracle padding, un attacker è in grado di decrittografare i messaggi arbitary, semplicemente controllando le risposte oracle di padding, senza avere accesso né alla chiave né all'output in chiaro del motore di decrittografia. Tuttavia, in questo caso, quando un utente malintenzionato ha accesso al padding oracle, l'utente malintenzionato ha anche accesso all'output in chiaro e viceversa, il che significa che la decrittografia dei messaggi arbitary è già possibile quando l'utente malintenzionato ha accesso al motore di decrittografia , senza dover ricorrere a un attacco di oracle padding.
Le 2 cose sono completamente diverse, perché con la chiave privata, l'attaccante è in grado di decrittografare mentre non ha più accesso al pad Oracle, ma se l'oracle padding può essere usato solo per decrittografare i messaggi, l'oracle di padding in questo caso diventa effettivamente inutile per l'utente malintenzionato, perché quando l'utente malintenzionato non ha più accesso oracle a padding, non può più decrittografare e l'obiettivo di sicurezza è soddisfatto.
Le domande che ho sono:
1: È sicuro usare PKCS 1.5 in questo caso?
2: E 'davvero possibile estrarre la chiave privata usando un padding oracle, o il pad Oracle solo permette la decifratura dei messaggi arbitary? I 2 articoli collegati sono ambigui al riguardo.