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
**********************************************************************
