RE: Smart card proposal

["Lyal Collins" <lyal.collins () key2it com au>]

Generally, smartcards themselves are relatively robust, if well
chosen/specified, and secure apps placed on them.
'hotwiring' smartcards is simple - install a remote access backdoor and
keyboard sniffer, then every time the smartcard is inserted and any 'hacked'
machine, interrogate for it's serial number, and present the right password
to perform whatever authentication you want.

PIN-pad equipped readers to exist.  They often need extra power, and need
proprietary drivers - PC/SC doees't cater to PINpads, while for sTIP stuff
may do.  Consequently, they cost more to buy and support.

Lyal



> -----Original Message-----
> From: Glenn_Everhart () bankone com [mailto:Glenn_Everhart () bankone com] 
> Sent: Thursday, 3 February 2005 4:13 AM
> To: webappsec () lists securityfocus com
> Subject: RE: Smart card proposal
>
>
> I wonder with these smartcards that have PIN pads so you 
> authenticate to the
> card...
>
> Can they be "hotwired", i.e., have an emulator that grabs 
> their data but pretends
> to have the PIN and just talks to whatever? (Obviously nobody 
> would likely
> alter the actual smartcard, but if the data thereof could be 
> dumped, what assures
> a back end that the real smartcard, and not an emulator with 
> its data, is there?
> Thus what assures the card has been authenticated to?
>
>
> -----Original Message-----
> From: Miguel Ruiz Velasco Sobrino [mailto:miguelrvs () yahoo com mx]
> Sent: Monday, January 31, 2005 2:06 PM
> To: webappsec () lists securityfocus com
> Subject: Re: Smart card proposal
>
>
>
> > Forwarded Message
> > > >
> > >
> > > Richard M. Smith wrote:
> >
> > > > < ... > What I still do not understand is how a Web 
> site communicates > >with the USB key device.
> > > >
> >
> > > Token-aware browsers (Internet Explorer, Netscape, 
> Mozilla, etc.) can be > >configured with PKI credentials 
> (e.g., private key and corresponding ID > >certificate) that 
> are stored either on the PC or on a smart card or USB > 
> > token.  The client's private key is used during the optional 
> (and server 
> > > controlled) "SSL client authentication" protocol sequence. 
>  The token 
> > > must be  "online" at SSL/TLS connect time.  The user is 
> prompted to 
> > > enter his/her user PIN as needed to access the private key 
> (which cannot > >be read from the token under any 
> circumstance).  Use of certificates 
> > > that have been issued by an Enterprise CA, etc. can help 
> simplify user > >interaction.  For example, the secure 
> website can inform the remote 
> > > client/browser that it accepts client certificates issued 
> by a certain > >CA or list of CAs.  In that case, other 
> available client certificates, > >if any, will not be part of 
> the site's user-authentication process.
> > > It's important to remember that, SSL connections can be 
> "resumed" for 
> > > some (server-specified) period of time.  The user can 
> revisit the secure > >site without additional token 
> interaction.  Normally, this resume 
> > > capability is invalidated immediately upon browser program 
> close (since > >the client's copy of previously negotiated 
> session parameters is 
> > > deleted) or by expiration of the server/site defined time 
> period.  This > >convenient but somewhat counter-intuitive 
> property of the web browser & > >underlying protocol 
> operation must be factored into secure application > >design.
> > Normally the act of extracting the card from the reader or 
> unplugging the token, makes
> > all SSL state to be lost (in a proper designed 
> driver/library), so it takes a bit of
> > education to your users. 
> > Some of the people making crypto discussions here (and in 
> other lists), have a curious
> > but  fatal misconception: they want to exclude the human 
> factor from security
> > frameworks,
> > sure, many users are morons but you cannot make a moron 
> (user) proof framework by
> > technological means. You have to make an effort educating 
> them to enhance security,
> > regardless how good and secure is the design of all the 
> components of the system.
> > > So the web site communicates with a client machine and browser 
> > > software.  Token operations occur indirectly through 
> browser software, > >token middleware, and USB device drivers.
> > > A couple of fun? details for future reference ...
> > >
> > > Per current standards, smart cards/tokens can be configured with a 
> > > "secondary authentication" PIN that must be presented each time a 
> > > particular signing key is used to perform it's digital signature 
> > > operation.  This "Signing PIN" may be distinct from the 
> User PIN that 
> > > controls general access to all protected objects on the 
> card (private 
> > > keys, certificates, data objects, etc.).  See the most 
> recent version of > >RSA's PKCS#11 standard for details.  I 
> believe Microsoft supports same > >or simlar via their CAPI 
> interface.  Intended effect is "one digital 
> > > signature per Signing-PIN presentation".
> >
> > CAPI for IE, outlook and other windoze programs
> > PKCS#11 for NS, mozilla. Also there are others interfaces 
> like MUSCLE.
> > And let's face it, in systems other than windoze, the smart 
> card are poorly developed
> > by
> > a variety of factors, including no vendor interest in the platform.
> >
> > > Some experts believe that, in some environments, the 
> user's PIN should > >be entered through a specially designed 
> reader that protects the PIN 
> > > from being captured (by keyloggers, etc.) -- see "protected 
> > > authentication path" in PKCS#11.  Several vendors have 
> fielded readers > >with a PINPad capability that allows the 
> PIN to be entered directly 
> > > through the reader unit (e.g., bypassing the client workstation).
> > >
> > > If / when such capabilities will be sufficiently viable in 
> commercial 
> > > products appears to be an open question.
> >
> > The smart card reader with pinpad are already in the 
> mainstream market, but they are
> > more
> > expensive than standard ones. I know al least that G&D have 
> one of that. And their SW
> > support it, because the other day my boss machine became 
> disconfigured due to infetion
> > and suddenly began asking for one of that readers/pinpad 
> (The smarcard windoze logon is
> > a
> > standard here).
> >
> > > HTH.
> >
> >
> >             
> > __________________________________ 
> > Do you Yahoo!? 
> > Yahoo! Mail - Easier than ever with enhanced search. Learn more.
> > http://info.mail.yahoo.com/mail_250
>
>
>
> Forwarded Message
> > >
> >
> > Richard M. Smith wrote:
>
> > > < ... > What I still do not understand is how a Web site 
> communicates >with the USB key device.
> > >
>
> > Token-aware browsers (Internet Explorer, Netscape, Mozilla, 
> etc.) can be >configured with PKI credentials (e.g., private 
> key and corresponding ID >certificate) that are stored either 
> on the PC or on a smart card or USB >token.  The client's 
> private key is used during the optional (and server 
> > controlled) "SSL client authentication" protocol sequence.  
> The token 
> > must be  "online" at SSL/TLS connect time.  The user is prompted to 
> > enter his/her user PIN as needed to access the private key 
> (which cannot >be read from the token under any 
> circumstance).  Use of certificates 
> > that have been issued by an Enterprise CA, etc. can help 
> simplify user 
> > interaction.  For example, the secure website can inform the remote 
> > client/browser that it accepts client certificates issued by 
> a certain 
> > CA or list of CAs.  In that case, other available client 
> certificates, 
> > if any, will not be part of the site's user-authentication process.
> >
> > It's important to remember that, SSL connections can be 
> "resumed" for 
> > some (server-specified) period of time.  The user can 
> revisit the secure >site without additional token 
> interaction.  Normally, this resume 
> > capability is invalidated immediately upon browser program 
> close (since 
> > the client's copy of previously negotiated session parameters is 
> > deleted) or by expiration of the server/site defined time 
> period.  This 
> > convenient but somewhat counter-intuitive property of the 
> web browser & 
> > underlying protocol operation must be factored into secure 
> application 
> > design.
>
> Normally the act of extracting the card from the reader or 
> unplugging the token, makes
> all SSL state to be lost (in a proper designed 
> driver/library), so it takes a bit of
> education to your users. 
> Some of the people making crypto discussions here (and in 
> other lists), have a curious
> but  fatal misconception: they want to exclude the human 
> factor from security frameworks,
> sure, many users are morons but you cannot make a moron 
> (user) proof framework by
> technological means. You have to make an effort educating 
> them to enhance security,
> regardless how good and secure is the design of all the 
> components of the system.
>
> > So the web site communicates with a client machine and browser 
> > software.  Token operations occur indirectly through browser 
> software, 
> > token middleware, and USB device drivers.
> >
> > A couple of fun? details for future reference ...
> >
> > Per current standards, smart cards/tokens can be configured with a 
> > "secondary authentication" PIN that must be presented each time a 
> > particular signing key is used to perform it's digital signature 
> > operation.  This "Signing PIN" may be distinct from the User 
> PIN that 
> > controls general access to all protected objects on the card 
> (private 
> > keys, certificates, data objects, etc.).  See the most 
> recent version of >RSA's PKCS#11 standard for details.  I 
> believe Microsoft supports same 
> > or simlar via their CAPI interface.  Intended effect is "one digital 
> > signature per Signing-PIN presentation".
>
> CAPI for IE, outlook and other windoze programs
> PKCS#11 for NS, mozilla. Also there are others interfaces like MUSCLE.
> And let's face it, in systems other than windoze, the smart 
> card are poorly developed by
> a variety of factors, including no vendor interest in the platform.
>
> > Some experts believe that, in some environments, the user's 
> PIN should 
> > be entered through a specially designed reader that protects the PIN 
> > from being captured (by keyloggers, etc.) -- see "protected 
> > authentication path" in PKCS#11.  Several vendors have 
> fielded readers 
> > with a PINPad capability that allows the PIN to be entered directly 
> > through the reader unit (e.g., bypassing the client workstation).
> >
> > If / when such capabilities will be sufficiently viable in 
> commercial 
> > products appears to be an open question.
>
> The smart card reader with pinpad are already in the 
> mainstream market, but they are more
> expensive than standard ones. I know al least that G&D have 
> one of that. And their SW
> support it, because the other day my boss machine became 
> disconfigured due to infetion
> and suddenly began asking for one of that readers/pinpad (The 
> smarcard windoze logon is a
> standard here).
>
> Miguel Ruiz Velasco
>
>
>               
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - Easier than ever with enhanced search. Learn more.
> http://info.mail.yahoo.com/mail_250
>
>
> **********************************************************************
> This transmission may contain information that is privileged, 
> confidential and/or exempt from disclosure under applicable 
> law. If you are not the intended recipient, you are hereby 
> notified that any disclosure, copying, distribution, or use 
> of the information contained herein (including any reliance 
> thereon) is STRICTLY PROHIBITED. If you received this 
> transmission in error, please immediately contact the sender 
> and destroy the material in its entirety, whether in 
> electronic or hard copy format. Thank you
> **********************************************************************