Quanto è affidabile l'utilizzo del sensore di impronte digitali (iPhone / Android) per l'approvazione dell'identità?

Naviga le tue risposte
1

Quello che sto cercando di ottenere è una conferma della transazione (non del pagamento) con un sensore di impronte digitali. Proprio come fa Google nel suo Play Store:

  1. Scegli un prodotto, fai clic su paga
  2. Approva la tua scelta con una scansione delle impronte digitali

Ciò che ritengo è che Google lo utilizzi solo sul lato client, senza alcuna conferma sul back-end che l'app abbia realmente richiesto l'impronta digitale.

Nel mio caso, è necessario fornire una prova al back-end che l'impronta digitale sia stata realmente richiesta. Per farlo io:

  1. Coppia di chiavi gen
  2. Iscrivi una chiave pubblica al back-end
  3. Scrivi una chiave privata per l'archiviazione delle chiavi sicure e collegala all'impronta digitale

In modo che la prossima volta che ho bisogno di una approvazione della transazione I:

  1. Chiedi a un utente di fornire un'impronta digitale, ricevere una chiave privata
  2. Firma la transazione con la chiave privata
  3. Convalidare tx con la chiave pubblica sul back-end

Ma ecco due idee per cui potrebbe non essere sicuro:

  1. L'applicazione client (android / ios) può essere modificata in JMP attorno alla chiamata alle impronte digitali e non associare affatto una chiave all'impronta digitale.
  2. Impronta digitale e amp; la memoria della chiave può essere emulata, ad es. in Android VD

In entrambi i casi, il back-end non avrà idea che la chiamata alle impronte digitali sia stata passata in giro poiché sta solo validando i dati per firma.

Non sono affatto un esperto di piattaforma mobile (sicurezza) e sto cercando di capire se quegli attacchi sono realmente validi / probabili e in qualche modo è possibile proteggerli contro di loro?

    
posta ovnia 10.03.2018 - 22:44
fonte

1 risposta

1

Il client può simulare l'intero processo, ma non l'autenticazione. Ciò significa che anche se il dispositivo viene rubato e la password del blocco schermo è compromessa, l'utente malintenzionato non può recuperare la chiave dal keystore e non può effettuare un acquisto nel nome del proprietario originale (registrato). Lo stesso se il dispositivo è rootato (con o senza il consenso dell'utente finale).

In quest'ultimo caso, tuttavia, lo scenario seguente è ancora possibile: l'utente finale conferma una transazione con un'impronta digitale, ma l'autore dell'attacco potrebbe aver stravolto la transazione, ad es. l'utente finale ritiene di aver approvato un acquisto di $ 10, mentre in realtà è di $ 100. Oppure l'utente finale desidera che il prodotto venga inviato al suo indirizzo di casa, ma in realtà la transazione elenca un indirizzo diverso.

Per quanto riguarda la prima e più realistica minaccia: non dovrebbe essere una grande preoccupazione per te, e se lo è, il tuo modello dovrebbe essere rivisto. Se hai un utente falso che sceglie di falsificare la sua autenticazione, può facilmente confermare una transazione con un'impronta digitale vera o con un'impronta digitale falsa.

Probabilmente un use case attacco che può essere mitigato dal lato server: transazioni di impronte digitali false possono arrivare a frequenze molto più elevate e provenire da dispositivi diversi. Quindi, se si considera questo attacco, è possibile alzare un flag quando lo stesso account utente produce acquisti molto veloci e / o utilizza molti dispositivi contemporaneamente.

    
risposta data 11.03.2018 - 17:39
fonte

Leggi altre domande sui tag

La catena ROP è possibile a 64 bit? Gestione della perdita di un telefono con FIDO UAF