Newsgroup: it.comp.sicurezza.varie
Titolo: Lettore Impronte Digitali

	Salve,
volevo realizzare un progettino carino e avrei bisogno di un lettore
di impronte digitali, compatibile con Linux.
Nessuno sa dove/come reperirlo? Preferibilmente in zona Roma, ma se
proprio non vengono trattati, allora su qualche sito di e-commerce.
Se poi qualcuno conoscesse anche qualche software (sempre *nix) che
gestisca gli accessi attraverso quest'apparecchio... :)
Ringraziandovi,
Federico Q.
-- 
Liberta'?  Qualcuno la vuole eliminare: 
http://www.complessita.it/tcpa/
Linux Registered User:  #263663 / Machine: #160060 (Debian 3.0 / Woody)
On the Net:  
qu...@despammed.com
  - On the Web:  
http://quaqo.lonex.org
On Jabber: 
qu...@jabber.org
 - On ICQ: 48618109 - My GPG Key: 0x1644D9E3

di impronte digitali, compatibile con Linux.
Li' vicino a te, spystore (at) 
spystore.it
 - domanda loro se possono
procurarti il lettore Polaroid, che fa parte del FT-376-M. Senza, e'
logico, il resto del kit. Il lettore e' un PFS-100
Dovrebbe venire sui 250-300 EUR.
Il punto debole e' la connessione seriale, per cui il tutto e' molto
vulnerabile ad un replay attack.
Leonardo
-- 
"Se e' vero che Linux in se' e' gratis, non lo sono le indispensabili
interfacce grafiche (X, KDE ecc.) che consentono alle persone normali
di utilizzarlo."                    -- Jason Matusow, Microsoft Corp.

 il tutto e' molto vulnerabile ad un replay attack.
Non dovrei avere di questo problemi in quanto e` un progetto casalingo,
di puro divertimento: non penso che qualcuno in casa  abbia conoscenze
o intenzione di violare il sistema con un replay attack. <g>
Grazie mille,


che si possa adattare.
No, lo scanner - per quanto ne so - codifica un tot di punti, sulla
lettura, in un pacchetto di 9 o 18 bytes, quindi spedisce a 9600 un
pacchetto del tipo <NUL><SIGNATURE><NUL><EOL>.
Ti basta leggerlo con un lettore di seriale, anche "cat /dev/ttyS0"
al limite, hexarlo, e poi fare
	SELECT username FROM database WHERE finger='09aef71b3c...';
Comunque meglio se senti prima 
www.futuranet.it
Qui poi ho trovato altra roba in seriale:
http://www.informer.co.uk/supp/supp_faq_sentrinetgeneral_1.htm
Leonardo
-- 
Questo messaggio e' NAGWARE. Per disattivare frecciatine, giochi
di parole, volgarita' gratuite ed inviti a rileggersi i messaggi
gia' passati e/o consultare 
http://groups.google.com
, effettuare
un versamento di 25 euro come tariffa di registrazione helpdesk.

 wrote:
Ah, badavi':
http://www.elettronicain.it/arretrati/sommario-n62.htm


 	SELECT username FROM database WHERE finger='09aef71b3c...';
 
Uhmm... Leonardo, di' un po'... ma cosi' peschi l'user solo se i punti 
letti sono esattamente gli stessi memorizzati nel db, giusto?
Ma normalmente dovrebbe essere cosi' o è un confronto... come dire....
particolarmente schizzinoso?
Chiedo perche' sto lavorando ad un progetto con un lettore biometrico -
un Precise Biometrics non mi ricordo il numero (che cmq non deve essere
niente di speciale perche' si sporca ogni momento). Beh, in pratica uso 
una DLL (parte dell'SDK) da VB e un db Access (no no, non guardatemi in
quel modo,non posso scegliere io! :P) e i tempi di ricerca mi aumentano
alla grande in base al numero di record nel db... pero' io no faccio la
query come te, in pratica confronto due buffers (per l'impronta letta e
per i "template" con i quali confrontarla, prendendoli man mano dal db)
con un'apposita funzione di verifica, sempre della dll (se ricordo bene 
pbVerifyFingerprint(buffer1, buffer2, match) - con match booleana che è
l'esito del confronto tra le due impronte).
Tale funzione poi è piu' o meno pignola in base al livello di sicurezza
che si setta con un'altra funzione (effettivamente coi livelli bassi ci
capitano dei falsi positivi ogni tanto, specie col sensore sporco).
Visto come funzionava la cosa, non ho trovato modo - sigh sob sigh - di
cavarsela con una query, perche' due buffer che danno matching true non
sono esattamente uguali (anzi, a occhio non ci ho visto nulla di simile
che potesse servire ad esempio per ordinarli/raggrupparli e velocizzare
la ricerca). Quindi, tu come fai? O il sensore che posso usare io funge 
in maniera completamente diversa? Hai idee? O_o
Ciao, grazie e buon Natale :)
un Dusk che ogni volta la giustificazione del testo e' una sfida nuova.

in maniera completamente diversa?
Temo sia vera la tua ipotesi :-(


 Temo sia vera la tua ipotesi :-(
Grazie di avermi aiutato a capire... ma tanto qualcosina per velocizzare 
me la inventero' ;)
ciau,
D.

me la inventero' ;)
Potresti vedere se la stessa impronta, scansionata in momenti diversi,
ti da' gli stessi valori di enrolment oppure no. Probabilmente no. Nel
caso, pero', sarebbe una colossale botta di fortuna - e vorrebbe dire,
alla fin fine, che nel lettore l'elettronica c'e' eccome.
Altrimenti bisognerebbe capire cosa c'e' in quei buffers :-), o con il
metodo gentile (chiedi all'helpdesk) oppure con guanti di gomma, tanta
pazienza e una serie di pennini Rotring e pennellini di bianchetto.
Un'altra strategia puo' essere quella di classificare i buffers.
Per esempio, quando hai un bel campione, lo suddividi in dieci gruppi,
circa equivalenti, tali che esiste una precisione P tale che, se A e B
sono nello stesso gruppo, Match(A, B, P)=True (e viceversa).
Idealmente, dovresti trovare per ogni gruppo una impronta equidistante
dalle altre nello spazio delle impronte - il centro dell'ipersfera.
A quel punto, per classificare una impronta sconosciuta X, effettui un
passaggio su tutti i gruppi con precisione decrescente, e poi effettui
il controllo solo sulle impronte del gruppo che matcha.
Il lavoro e' molto semplificato se la funzione ti ritorna un valore di
tipo probabilistico.
A questo proposito, *puo' essere* che la funzione calcoli davvero solo
un valore probabilistico, e poi ti ritorni "si" o "no" a seconda che i
limiti che hai impostato siano o meno soddisfatti con quel valore. Con
un po' di gufo, la funzione "interna" e' chiamata solo se necessario e
	Match(A, B, P1)
	Match(A, B, P2)
si traducono ad una _sola_ chiamata all'ipotetica _Match(A,B). Sarebbe
utile avere accesso, a _Match(A,B) - non ti suggerisco di picchiare la
DLL usando SYMBOLS.EXE, DEPENDS.EXE o QuickView (di serie), ma magari,
se ti concentri, percepisci il nome interno della funzione, e forse il
protocollo di chiamata - ma anche non avendolo, uno puo' riordinare il
conteggio in modo da trarre vantaggio dal caching di A e B in Match().
Leonardo e i libberi penzieri


 Un'altra strategia puo' essere quella di classificare i buffers.
<cuttone>
Ok, vedo di lavorare su questa strada... mentirei a dire di aver capito 
tutto, cmq mi hai dato un bel po' di spunti e ti ringrazio come al 
solito. :)
un Dusk che venerdi' dovrebbe avere di nuovo per le mani quell'aggeggio