Hello, Peter ...
 
"... bypasses the PIN entry and allows the biometric authentication system to directly 
access card resources."
 
Anything that bypasses my security conditions gets my attention.  
 
Perhaps I the cardholder wish to PIN-protect my biometric templates so that I get a 
heads-up when a terminal is trying to read them.  And maybe I want to decide not to be 
biometrically authenticated in the situation at hand BEFORE the biometric 
authentication system has directly accessed the card resources.
 
And furthermore, how do I know it is a "biometric authentication system"?  And once 
this supposed biometric authentication system gets direct access to card resources, 
how am I assured that it limits itself to biometric information?
 
It's a backdoor, plain and simple.  Just like the Java Card Virtual Machine backdoor.  
And you want me to trust the security systems these folks are selling?  They're full 
of holes papered over with arrogance.
 
IMHO, as always.
 
Cheers, Scott

        -----Original Message----- 
        From: Peter Williams [mailto:[EMAIL PROTECTED] 
        Sent: Sun 3/14/2004 8:45 PM 
        To: [EMAIL PROTECTED] 
        Cc: 
        Subject: RE: [Muscle] Cardholder Must Trust All Applets and Middleware
        
        

        i dont dont understand your complaint, this time. The overview is asserting
        merely that there are two entry points to the TCB subject verification
        module: Pin verification, and a "crypto method" agreed between bio token and
        TCB.
        
        All it seems to be saying is that you dont have to layer the factors: having
        a powerful factor [using a 32bit arm, probably) reduce to a 5 decimal
        number! Rather, administration of the bio profiles and login conditions are
        managed locally - like at any wiegand bio device in any data center,
        airport, etc.
        
        It does imply, as you may be asserting, that the TCB has _delegated_ the
        subject verification to the bio token, which must then cite a magic crypto
        number that.....any one else with the magic formula could also cite, or
        introduce via an active wiretap.
        
        Under the evaluation rules, this architecture would count as a partitioned
        TCB, and requires additional functions and assurance to show the designers
        are controlling the risk of partitioning.
        
        I remember reading the activecard FIPS 140-1 certificate, about a year ago.
        Its on the NIST website. It disclosed a fair amount of their proprietary
        methods of handling applet loading, and applet distribution. It was unusual
        to see this stuff in a 140-1 security policy; may be just marketing, to give
        the appearance that the 140-1 certfication addresses these common criteria
        issues. Or, perhaps they were going to give 140-2 a try, at some point.
        
        Bio-arming of crypto boundaries is hardly new.
        
        
        >From: "Scott Guthery" <[EMAIL PROTECTED]>
        >Reply-To: [EMAIL PROTECTED]
        >To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
        >CC: "David Everett" <[EMAIL PROTECTED]>
        >Subject: [Muscle] Cardholder Must Trust All Applets and Middleware
        >Date: Sun, 14 Mar 2004 18:41:50 -0500
        >
        >I've questioned the wisdom of letting on-card applets slide by the access
        >control rules, particularly PIN protections, on data files in integrated
        >circuit cards.  Now comes a patent application that says that middleware
        >gets to slide by too.  That will teach me to think that things can't get
        >worse!
        >
        >Notice that middleware convenience trumps cardholder privacy.
        >
        >Cheers, Scott
        >
        >EP1396779A2: System and method to facilitate separate cardholder and system
        >access to resources controlled by a smart card
        >
        >ACTIVCARD IRELAND LIMITED
        >
        >This invention provides a mechanism, which allows a user's personal
        >identification number (PIN) to operate independently from a biometric
        >authentication system. This improvement reduces the administrative burden
        >of having to keep a user's PIN synchronized with the PIN used to access the
        >user's smart card (15) following successful biometric authentication. The
        >first embodiment of the invention incorporates a cryptographic interface,
        >which bypasses the PIN entry and allows the biometric authentication system
        >to directly access card resources. The second embodiment of the invention
        >provides a second system PIN having greater bit strength than the
        >cardholder PIN. Both embodiments of the invention retrieve secrets (either
        >a cryptographic key or system PIN) from a biometric database (60) by
        >comparing a processed biometric sample with known biometric templates. The
        >biometric authentication system incorporates a client-server architecture,
        >which facilitates multiple biometric authen!
        >  tications.
        >
        >
        >_______________________________________________
        >Muscle mailing list
        >[EMAIL PROTECTED]
        >http://lists.musclecard.com/mailman/listinfo/muscle
        
        _________________________________________________________________
        Fast. Reliable. Get MSN 9 Dial-up - 3 months for the price of 1!
        (Limited-time Offer) http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/
        
        _______________________________________________
        Muscle mailing list
        [EMAIL PROTECTED]
        http://lists.musclecard.com/mailman/listinfo/muscle
        


_______________________________________________
Muscle mailing list
[EMAIL PROTECTED]
http://lists.musclecard.com/mailman/listinfo/muscle

Reply via email to