Newsgroup: it.comp.sicurezza.varie
Titolo: Re: Autenticazione APP banca via impronta digitale

 qualcosa che dice "ho verificato io l'impronta, fallo entrare" (*)
 
Benche io sia da sempre contrario all'uso dell'impronta digitale, devo 
convenire che è molto comoda, e ora la uso.
 
Mi sono fatto l'idea che l'impronta risieda sul telefonino, e che la 
verifica competa all'app.
In linea di massima se l'impronta è verificata secondo me manda il pin 
all'app e non va oltre.
 
Io ho dedicato un telefono ancora buono all'app bancaria (tanto la uso 
poche volte e sempre da pc, mi serve solo come token) protetto da pin 
forte e impronta. Tale telefono è sempre spento.
Il suo android è stock e aggiornato, ha solo le app minime, senza 
social, senza whatsapp o telegram, senza altri account, senza posta, 
con numero di telefono praticamente mai usato da anni.

 sicuro di una buona password. O sbaglio?
 
sbagli. nella premessa.
 

 
 
no, è molto più banale,
la prima volta devi inserire le credenziali e solo
dopo l'app ti chiede se vuoi autenticarti con l'impronta,
a questo punto l'app si interfaccia con android che detiene
il controllo dell'impronta e se riconosciuta da l'ok all'app
la quale ""digita"" le credenziali precedentemente inserite.
con alcune banche si vede proprio in background la schermata
del pin/password che si auto-riempie di asterischi.
 

 numero di telefono praticamente mai usato da anni.
 
Stessa mia identica soluzione
Col cavolo concedo all'app dell banca di accedede a:
contatti
microfono
altoparlante
sms
calendario
app installate
 
L'unica cosa che posso capire è la geolocalizazione.
 
Comunque il "tokentelefono" è completamente vuoto :-)
 
-- 
Saluti
Bruno

 (*)
 
Sì, le impronte sono registrate in locale in un'area che si chiama 
Trusted Execution Environment. E' proprio un'area protetta a livello 
hardware, che nei processori ARM per dispositivi mobili è integrata nel 
SoC, e nello specifico si chiama ARM TrustZone.
Il sistema operativo espone delle API, che semplificando riportano 
semplicemente all'app "impronta verificata" o "impronta non verificata".
L'app non può accedere direttamente alle impronte, che sono 
immagazzinate a livello hardware e possono essere interrogate solo con 
la mediazione del SO a livello software.
Se ti interessano i dettagli (che io non conosco...) fai una ricerca con 
"Trusted Execution Environment" e con "ARM TrustZone"
 
-- 
Saluti
VITRIOL

 verificata"
 
Credo sia praticamente impossibile se sul dispositivo non ci sono 
permessi di root. Ma del resto se c'è il root la quasi totalità delle 
app bancarie smetterà di funzionare.
 
-- 
Saluti
VITRIOL

 verificata"
 
quello che scrivi può teoricamente accadere solo se il dispositivo è 
rootato. ammesso e non concesso che una app bancaria accetti di 
funzionare su un dispositivo rootato, è altresì ovvio se hai a cuore un 
minimo la sicurezza non utilizzi un dispositivo rootato per accedere alle 
tue finanze. 

 Hackingteam cosa potrebbe fare e cosa no?
 
non ne ho idea non ho letto nulla a proposito. ma lo spionaggio mi pare 
leggermente overkill rispetto al tema che stavamo trattando.

 positiva.
 
sarebbe una applicazione *diversa*. certo un malintenzionato può fare un 
clone e tecnicamente metterlo anche sullo store (finché non viene sgamato) 
ma non può fartela scaricare al posto dell'originale.

sempre positiva.
 
Ma a quel punto l'app risponderà in modo erroneo all'autenticazione richiesta
dalla banca.
 
La banca non si fida mica del fatto che la app trasmetta un "ok=true" :-D
 
Leonardo
-- 
 
"You all presumably know why" :-) :-(

 banca per bloccare l'accesso.
 
si troverà il telefono bloccato con l'impronta digitale e non potrà farci 
nulla. ovvero tutto quello che potrà fare è distruttivo rispetto a quello 
che vorrebbe ottenere.
d'altra parte a questo serve la protezione, eh. 
 

 tue finanze. 
 
Prendiamo il caso in cui sia sia sbloccato solo il bootloader e ci sia 
una versione stock senza root di android.
Come sarebbe la sicurezza di quel telefono con una app bancaria?

 Come sarebbe la sicurezza di quel telefono con una app bancaria?
 
queste discussioni al solito finiscono col perdere di senso.
se un utente modifica il dispositivo saprà il fatto suo, avrà i suoi 
motivi per farlo ma soprattutto sarà cosciente delle implicazioni. 
restiamo sul pezzo.

 restiamo sul pezzo.
 
 
Va bene, forse la mia domanda è troppo particolare, ma mi sembra invece 
di essere in topic sia nel gruppo (sicurezza) sia nel thread (app 
bancarie).

 dice anche qualcos'altro?
 
viene invocata una callback con un parametro che contiene un token 
encrypted che identifica la transazione (contro il tampering).
 
in sostanza sì, dice solo "ok, è autenticato" con in più la prova che si 
tratta effettivamente della transazione iniziata dalla app stessa.
 
a quel punto la app fa quello che deve fare, a seconda dei casi. nel caso 
di una app che deve autenticarsi su un backend (come ad esempio quella 
della banca) recupera le credenziali salvate sul keystore e le passa alla 
login, analogamente a come avviene col browser e strumenti come 
lastpassword o simila.
 

 thread (app bancarie).
 
C'è un X-post con it.discussioni.consumatori.tutela, sai? :-)
Io in compenso non m'ero accorto che fosse anche su I.C.S.V. O_0
 
Bye, G.
 
 
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
 

 Io in compenso non m'ero accorto che fosse anche su I.C.S.V. O_0
 
Ora vado a guardare, ma siccome mesnews da me non funziona bene (è il 
portabile) devo prima fare una copia di tutta la cartella e aggiungere 
quel gruppo, altrimenti mesnews si blocca.
Preferisco che si blocchi la copia, che poi elimino.

-il server della banca
 
Io la so così:
 
	- viene creata una connessione sicura fra server e app
	- il server invia un token altamente casuale
	- tu tocchi con il dito
	- la app richiede l'autenticazione all'HW via API
	- l'HW riconosce il dito e dice all'OS e all'app:
 
		"Con questo dito hai disponibili: (1) TOKEN_BANCARIO
		 (2) TOKEN_DI_DROPBOX (3) AUTH_MACELLERIA_FALORNI
		 (4) DA_BETTY_MASSAGGI_PERSONALI (5) ..."
 
	- la app via API dice "Ochei, criptami TOKEN_CASUALE con (1)"
	- l'HW risponde "Ecco la risposta: HASH_ABBESTIA"
	- la app invia alla banca HASH_ABBESTIA e il tuo ID utente
 
	- il server bancario, che è quello che ha rilasciato TOKEN_BANCARIO
	  a quell'ID utente mesi prima e quindi lo conosce, hasha pure lui
	  TOKEN_CASUALE con TOKEN_BANCARIO e ottiene HASH_ATTESO.
	- se HASH_ATTESO e HASH_ABBESTIA sono uguali, la sessione è
	  autenticata.
 
La app potrebbe essere falsa come Giuda, ma è solo un "passacarte" fra il
server e l'hardware. L'hardware, su un sistema non rootato (e forse anche
su un sistema rootato), non lo puoi compromettere in alcun modo.
 
Però su un sistema rootato non puoi essere sicuro che mesi prima, davvero
sia stato l'HW ad archiviare TOKEN_BANCARIO in modo sicuro, e che quindi,
oggi, l'utente non possa ripudiare una transazione "scoprendo" l'avvenuto
root e giurando sul BDSMVDP che l'impronta no, non era sua. E' per QUESTO
che su un dispositivo rootato l'app si rifiuta di girare e di chiedere un
TOKEN_BANCARIO funzionante al server.


trattamento massivo di dati  altamente "pericolosi".
 
Non necessariamente. Non è molto diverso dal sistema usato dai "Tutor". I dati
vengono passati da un macinello che consente di confrontare due hash, ma dall'
hash non consente di sapere nulla di che dati fossero.
 
Potrebbe essere un'idea. Naturalmente il macinello dovrebbe essere studiato ad
hoc per le impronte digitali, perché le immagini in arrivo non saranno mai del
tutto uguali.


 server. 
 
cosa che non ha alcun senso sotto tutti i punti di vista.
l'autenticazione biometrica serve per garantire l'accesso autorizzato al 
dispositivo, stop. 

 univoci.
 
e vorrei ben vedere che gli hash fossero univoci.

 *stessa* persona non genera hash univoci, a differenza di una password"
 
guarda che gli hash *non* sono univoci neanche per la stessa password.
e vorrei ben vedere, ripeto.
questo ti sto dicendo.

univoci.
 
Ho capito cosa volevi dire, ma ti sbagli: le IMMAGINI non son tutte uguali, ma
possono generare sindromi CONFRONTABILI (che non significa 'identiche').
 
Ho usato il termine sindrome anziché hash perché più esatto. La sindrome è una
versione "digerita" della impronta digitale, ed è possibile anonimizzarla come
dicevo con un "macinello" adatto (ma va detto che da una semplice lista di una
serie di cd. "minuzie" non si ricostruisce granché l'impronta, perciò potremmo
anche dire che la codifica sindromica _E'_ un hash, o almeno ne eredita alcune
caratteristiche [*]).
 
https://en.wikipedia.org/wiki/Locality-sensitive_hashing
 
 
Naturalmente il macinello VERO è ancora diverso, e, in effetti, le varie ditte
produttrici ne hanno sviluppati di proprietari e con algoritmi segreti (questo
perché le caratteristiche dell'algoritmo si traducono in prestazioni diverse e
più o meno superiori per certe applicazioni).
 
Vedi per es.: 
https://ieeexplore.ieee.org/document/8003392
 
 
Leonardo
 
[*] per es. dalla MCC di una impronta posso sì ricostruire una impronta che mi
    dia la stessa sindrome e sembri una impronta umana, ma sovrapponendola con
    l'impronta originale vedo che sono diverse: ho cioè ottenuto una specie di
    "hash collision".


 'identiche').
 
esatto. tant'è vero che per acquisire il pattern è necessario acquisire 
numerose impronte per "aggiustare" la tolleranza rispetto alla 
variabilità.
analogamente a quando in banca acquisiscono la firma sulla tavoletta.