Esiste un equivalente di una criptochip Apple nei dispositivi Android?

Question

Esiste un equivalente di una criptochip Apple nei dispositivi Android?

#1 da (3 voti)
#2 da (1 voti)

6

Apple ha un cryptochip che, oltre a gestire le chiavi di crittografia, l'autenticazione dei tunnel e fornisce la limitazione del fallimento tentativi, oltre alla possibilità di attivare un dispositivo per cancellare dopo diversi tentativi falliti di autenticarsi. Ciò consente una sicurezza ragionevole utilizzando un PIN a 4 cifre.

Non ho trovato alcuna informazione sull'esistenza di un tale meccanismo hardware in dispositivi basati su Android. Il più vicino potrebbe essere il TEE (Trusted Execution Environment)

The TEE is a secure area of the main processor in a smart phone (or any connected device). It ensures that sensitive data is stored, processed and protected in an isolated, trusted environment

La mia comprensione è che si tratta essenzialmente di un'implementazione di TPM , che protegge solo le chiavi di crittografia e in particolare non gestire l'autenticazione stessa.

In questo caso, in che modo Android garantisce che la limitazione dei tentativi di autenticazione falliti non venga ignorata durante un attacco offline?

In particolare:

decrittografia di un disco nudo estratto dal dispositivo non è possibile (la chiave generata dal TEE è robusta)
decrittografia di un disco nel dispositivo con l'aiuto del TEE deve essere protetto contro - tramite la limitazione o la cancellazione dopo un determinato numero di tentativi.

Una descrizione dell'implementazione di quest'ultimo è ciò che sto cercando.

Nota : sono consapevole del fatto che esistono bug di sicurezza che aiutano a bypassare un'impostazione di sicurezza. Questo accade ovunque e su ogni dispositivo e si spera che venga riparato con le patch. Questo non è l'argomento della mia domanda - sono specificamente interessato ai meccanismi hardware progettati per proteggere da meccanismi di autenticazione apparentemente insicuri (che un PIN a 4 cifre, in assenza di questi sistemi, sarebbe un esempio di).

EDIT: vedi anche questa risposta su TEE stesso (come complemento alla domanda precedente)

encryption android brute-force password-cracking

posta WoJ 28.10.2015 - 17:19

fonte

2 risposte

1

Il più vicino che io conosca è voltault del progetto Google . È un sistema che ha una CPU secondaria all'interno di una scheda SD bloccata che esegue tutti i processi sensibili e la gestione delle chiavi. Google spera di cucinare il sistema in API androidi in modo che qualsiasi dispositivo Android con un lettore di schede SD possa utilizzare il chip.

Ci sono alcune aziende che sostengono di fare la stessa cosa, ma con i ricercatori che continuano a trovare difetti in quei sistemi, questa sembra la strada più promettente per fornire una strong sicurezza per Android finora.

risposta data 28.10.2015 - 22:27

fonte

Leggi altre domande sui tag encryption android brute-force password-cracking

JSON Web Token Security Ci sono delle proposte per la verifica dell'e-mail senza un'email di conferma?

score 3 · Accepted Answer

how does Android ensure that the throttling of failed authentication attempts is not by-passed during an offline attack?

Android KeyStores può essere basato su hardware o software precedente ad Android N, che ha reso l'hardware KeyStore a DEVE nel CTS.

EDIT : nel seguito sto usando il termine attacco online come qualcosa con la proprietà

Online entities can perform additional security checks to make a protocol more safe. For example, an online entity can regulate the number and speed of login attempts (from another SO q)

... piuttosto che essere condotto su una rete remota. Forse non lo sto usando nel modo comune, ma per me la proprietà interessante sugli attacchi online è che c'è un livello tra l'attaccante e i dati attaccati che non è sotto il controllo degli attaccanti. Se questo strato è un webserver remoto o un hardware locale non fa molta differenza in questo caso, poiché entrambi possono eseguire un limite di velocità, a meno che il chip fisico non venga attaccato / ispezionato, che sarebbe una classe di attacco completamente diversa.

Questa risposta SO ha effettivamente una definizione più vicina a quella che sto usando

An online attack tries automated routines providing input to a legitimate system. They are not looking to create an exploit in functionality, but to abuse expected functionality.

An offline attack attempts to emulate the encryption/hashing and requires a known output of that process (i.e., you don't attack the system, you already have the hashed/encrypted password)

Se basato su hardware, le chiavi private dovrebbero essere estraibili dal KeyStore senza un attacco fisico sofisticato (forse un microscopio elettronico o una scatola nera vuln esposta dal TEE / TPM. online attacco. Speri che il TEE / TPM implementi la strozzatura.

EDIT : Ho appena testato il nexus 6p KeyStore impl e nessuna limitazione ha luogo per le operazioni generali Cipher (vedevo se un padding oracle è stato esposto per RSA). Tuttavia non ho provato KeyStore limitando la velocità per lo sblocco principale.

Se il software è basato su root, il blob KeyStore può essere rimosso e potenzialmente bruto. Questo è un attacco offline e nessuna limitazione può aver luogo.

In risposta alla tua domanda, non è possibile garantire la limitazione di un attacco offline, per sua natura.