biometrics
lynn.wheeler at firstdata.com
lynn.wheeler at firstdata.com
Wed Jan 30 12:23:09 EST 2002
The "secret" PIN/Password (or biometric) is respect to the card. The card
is then the thing that is actually used to authenticate (aka the card
doesn't work as needed unless the correct secret has been presented to the
card).
this is different from "shared-secrets" (pin, password or biometric) where
the value is registered in some repository and presenting the correct
"shared-secret" (pin, password or biometric) represents the authentication
operation. As mentioned in related postings, (shared-secret) passwords
"don't work" because a diffferent one is needed for every security domain
(in fact, it is a problem with respect to all "shared-secret" opertaions).
So a card or hardware token is a "something you have" authentication. In
the case of hardware token, the hardware token has to perform some unique
operation for each authentication event. Since the hardware token is using
a unique operation for each authentication event (digital signature on
unique message; sever sends a unique message containing unique time or
number, the receiver appends their own unique time or number to the message
and then digitally signs the combined unique message with their hardware
token using a private key, the receiver provided part of the message and
the digital signature is returned to the original sender as proof of
authentication ... aka possesing a unique "something you have").
In such a hardware token proof of authentication "something you have" ...
the corresponding "public key" is registered at the sender. The use of the
"public key" is only in "authenticating" the message and therefor the
person possesing the hardware token "something you have". It differs from
"shared secret" implementations, in that the value registered can be used
to both authenticate transmissions as well as originate value transmissions
(givng rise to the recommendation that unique "shared secrets" are to be
registered in each unique security domain).
However, since the "something you have" hardware token is using public key
authentication, in place of "shared-secret" authentication; it is not
necessary to have a unique one in every domain.
Now a somple "something you have" authentication process can be compromised
by stealing the "something you have" hardware token. The hardware token can
be more secure by making its correct operation dependent on a secret pin,
password, &/or biometric being entered. While the authenticating agency
still only does public key digital signature authentication, it has a
business process where it establishes that a unique public/private key has
been created with a specific kind of hardware token, that the generated
private key only exists in that specific hardware token so that the
authenticating agency has a high level of confidence that any message
digital signature that authenticates with the registered public key ....
must have originated from the corresponding hardware token.
To make it more secure than "something you have" authentication (addressing
the stolen token compromise), the authenticating agency also makes sure
that the associated token only correctly signs messages when there has been
a secret pin, password, and/or biometric entered into the hardware token.
Given that the authenticating agency validates the business process and
nature of the hardware token (public/private key, digital signature,
correct operation dependent on entering correct secret pin, password,
biometric), then the authenticating agency can be relatively confident that
message digital signatures correctly authenticated by a specific public key
must have originated from a specific hardware token in the possession of a
specific person.
Now, since the registering of a public key in multiple places doesn't
represent a security compromise (of allowing one security domain to
impersonate an entity to a different security domain having learned their
public key), using the corresponding hardware token in multiple different
environments also doesn't represent that kind of security compromise.
So we are now down to the "failure mode" of getting your card stolen AND
the secret compromised for that card's correct operation. Does having a
unique card for each security domain change the situation? Well, for the
majority of cards they are all carried in the same container (wallet,
purse, etc) and the unit of theft is most commoningly the container. So the
claim there is that for all cards currently carried in the same container
.... they could all be reduced to a single card (of the hardware token
nature described) w/o significantly changing the failure mode.
Now lets look at the counter scenario.
Every domain that is currently shared-secret passed is upgraded to a
hardware token of the type described (digital signature authentication,
correct public/private key protection practices, hardware token operation
dependent on entering correct secret, etc). I sit at my home computer;
from that home computer I currently have possibly 80 different security
domains that I access, each with its unique pin/password. Each one of those
environments upgrades to the hardware token of the described specific
nature (and the value registered in each of the domains is a public key,
where knowing the specific public key it is possible to authenticate a
message, but knowing the public key it is not possible to originate a
fraudulent message ... as in the "shared secret" case).
I'm now sitting hear with some sort of card acceptor device at my home
computer and a pile of 80 hardware tokens each with their own unique
activation secret.
I claim that the operational difficulties is more severe than what the
world was in progress of heading to in the mid-80s with copy protection
floppy disks .... I had a unique copy protected floppy disk for every copy
protected application loaded on my hard disk; when ever a specific
application needed correct operation, I would have to pull the current
floppy from the drive and shuffle thru the pile of copy protected floppy
disks looking for the correct one and insert it into the floppy drive.
I contend that having 80 unique hardware tokens, each hardware token with a
unique "secret" value (that is not written down anywhere) is a
significantly worse human factors operation thatn the typical '80s copy
protection floppy nightmare. Having to remember 80 "secret" values doesn't
improve my current situation of having to remember 80 "shared secret"
values. However, having to also remove the current card and shuffle thru 80
different hardware tokens for the correct card, insert that card, and then
enter the correct "secret" associated with that specific hardware token is
totally unmanageable.
I contend that the process would support at most 2-3 unique hardware tokens
.... with each unique hardware token supporting 20-30 different "logins".
Even that I contend has lousy human factors since the person still has to
partition and remember the different "logins" associated with a specific
token (and still shuffle tokens and hope they get the correct one for the
correct applications).
previous discussion of floppy disk analogy applied to hardware tokens:
http://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY
previous shared-secret/secret &/or hardware token discussions:
http://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature
initiative stalled
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#ecomm Authentication in eCommerce
applications
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re:
KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION
:draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
http://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX ....
password/digital signature
http://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An
Artifact...
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about
Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#ocrp Online Certificate Revocation
Protocol
http://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate Revocation
Protocol
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server
security
http://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower
These Terrorists?
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper
Political Cryptography
http://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re:
Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#3dvulner 3D Secure Vulnerabilities?
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for
PKI)
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel
Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm9.htm#carnivore2 Shades of FV's Nathaniel
Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12 A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12c A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations
on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#biometrics biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm10.htm#bio5 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations
regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments
on X9.59 issues.
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
http://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment
standard issue
http://www.garlic.com/~lynn/aepay6.htm#harvest2 shared secrets, CC#, &
harvesting CC#
http://www.garlic.com/~lynn/aepay6.htm#erictalk Announce: Eric Hughes
giving Stanford EE380 talk this
http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and
PKI (addenda)
http://www.garlic.com/~lynn/aepay7.htm#ssexploit Shared Secret exploit
http://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe??
... power to the consumer
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities?
Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay8.htm#vulner account number & shared
secret vulnerabilities
http://www.garlic.com/~lynn/2000.html#39 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#46 question about PKI...
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2000b.html#53 Digital Certificates-Healthcare
Setting
http://www.garlic.com/~lynn/2000b.html#90 Question regarding authentication
implementation
http://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication
implementation
http://www.garlic.com/~lynn/2000f.html#1 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
http://www.garlic.com/~lynn/2000g.html#5 e-commerce: Storing Credit Card
numbers safely
http://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of
acceptance of key binding ?
http://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of
acceptance of key binding ?
http://www.garlic.com/~lynn/2000g.html#49 Use of SET?
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001f.html#25 Question about credit card number
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit
cards!
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#63 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#75 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#10 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001i.html#35 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#49 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001k.html#58 I-net banking security
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security
http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip
Market
http://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle
attacks?
http://www.garlic.com/~lynn/2001n.html#94 Secret Key Infrastructure plug
compatible with PKI
http://www.garlic.com/~lynn/2002.html#9 How to get 128-256 bit security
only from a passphrase?
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow
http://www.garlic.com/~lynn/99.html#79 Authentication in eCommerce
applications
http://www.garlic.com/~lynn/99.html#214 Ask about Certification-less Public
Key
http://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
<pasward at big.uwa
terloo.ca> To: Bill Frantz
<frantz at pwpconsult.com>
01/30/2002 06:13 cc: lynn.wheeler at firstdata.com,
AM cryptography at wasabisystems.com,
pasward at big.uwaterloo.ca
Subject: Re: biometrics
Bill Frantz writes:
>
> What would be really nice is to be able to have the same PIN/password
for
> everything.
Do you really mean that? Sure, if I only have to remember one thing
it is easier for me. It is also a complete nightmare if it is ever
compromised.
--
----------------------------------------------------------------------------
Paul A.S. Ward, Assistant Professor Email: pasward at shoshin.uwaterloo.ca
University of Waterloo pasward at computer.org
Department of Computer Engineering Tel: +1 (519) 888-4567 ext.3127
Waterloo, Ontario Fax: +1 (519) 885-1208
Canada N2L 3G1 URL:
http://shoshin.uwaterloo.ca/~pasward
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com
More information about the cryptography
mailing list