Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next, previous
- home
- the limits of crypto and authentication
- Keeping an eye on ATM fraud
- US consumers want companies fined for security breaches
- City National Bank is the latest major US company to admit it has lost customer data
- the limits of crypto and authentication
- the limits of crypto and authentication
- the limits of crypto and authentication
- EMV
- UK EU presidency aims for Europe-wide biometric ID card
- the limits of crypto and authentication
- the limits of crypto and authentication
- the limits of crypto and authentication
- the limits of crypto and authentication
- ID "theft" -- so what?
- the limits of crypto and authentication
- the limits of crypto and authentication
- the limits of crypto and authentication
- the limits of crypto and authentication
- the limits of crypto and authentication
- the limits of crypto and authentication
- ID "theft" -- so what?
- Qualified Certificate Request
- ID "theft" -- so what?
- Online ID Thieves Exploit Lax ATM Security
- [Clips] Escaping Password Purgatory
- Cross logins
- [Clips] Does Phil Zimmermann need a clue on VoIP?
- [Clips] Does Phil Zimmermann need a clue on VoIP?
- solving the wrong problem
- How much for a DoD X.509 certificate?
- How much for a DoD X.509 certificate?
- The summer of PKI love
- How many wrongs do you need to make a right?
- How many wrongs do you need to make a right?
- Another entry in the internet security hall of shame
- Federal Information Assurance Conference 2005, Oct 25-26
- Another entry in the internet security hall of shame
- Another entry in the internet security hall of shame
- Another entry in the internet security hall of shame
- Another entry in the internet security hall of shame
- Another entry in the internet security hall of shame
- Another entry in the internet security hall of shame
- Another entry in the internet security hall of shame
- Another entry in the internet security hall of shame
- Another entry in the internet security hall of shame
the limits of crypto and authentication
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Sun, 10 Jul 2005 13:36:04 -0600
To: Perry E. Metzger <perry@xxxxxxxx>
CC: Nick Owen <nowen@xxxxxxxx>, cryptography@xxxxxxxx,
"Steven M. Bellovin" <smb@xxxxxxxx>
another characteristic of the PKI x.509 identity certificate activity
(besides attempting to create mass world-wide confusion regarding the
difference between identification and authentication ... and trying to
get govs. to mandate that x.509 identity certificates, grossly
overloaded with personal information had to be appended to even the
most simple of authentication transactions) .... was trying to cause a
great deal of confusion about the difference between digital
signatures and human signatures. some of this possibly was semantic
confusion because both of the terms, digital signature and human
signature contain the word signature.
nominally a digital signature is the use of a private key to encode a
message/document hash. the relying party then recalculates the
message/document hash, uses the corresponding public key to decode the
digital signature, and compares the two hash. if they are equal, the
relying party assumes:
- the message/document hasn't been altered (since the digital
signature)
- something you have authentication, aka the originator has access
and use of the private key.
the base technology is asymmetric key cryptography (what one key
encodes, the other key decodes). the business process of public key,
identifies one key as publicly available. the other key is kept
confidential and never divulged. the integrity of something you have
authentication can be improved by deploying secure hardware tokens
where the key pair are generated in the token and the private key
never leaves the token (improving the probability that the private key
is never divulged).
now, normal human signature implies read, understood, agrees,
approves, and/or authorizes. The normal digital signature is purely
a something you have authentication process implying none of the
characteristics of a human signature. In fact, a series of my pasts
posts on dual-use attacks was specifically with using the same
private key to apply digital signatures to random data (as part of
authentication operations) and digital signatures to non-random data
(assuming human signature characteristics).
Somewhat in support of helping create world wide confusion about the
differences between digital signatures and human signatures (in
addition to creating world wide confusion about the difference between
authentication and identification), the PKI x.509 digital certificate
standard also defined a non-repudiation bit. For some number of
PKI-oriented payment protocols in the mid-90s, there was the
specification of digital certificates with the non-repudiation bit
turned on. Supposedly, if a merchant could produce any valid
digital certificate with the non-repudiation bit turned on (for the
customer's public key), then the burden of proof in any dispute would
have shifted from the merchant to the consumer. The
threat/vulnerability was
- the PKI-oriented protocols provided no mechanism for proving which
certificate had been originally attached to the transaction
- supposedly the non-repudiation bit was capable of turning any
digital signature operation (regardless of the environemnt in which
the signature had been performed) magically into a human signature
carrying the attributes of read, understood, agreed, approved and/or
authorized.
So the PKI x.509 identity digital certificates were targeted at
- turning every transaction in the world (even the most trivial
authentication operation) into a heavy duty identification operation
(with attached x.509 identity digital certificates carrying enormous
amounts of personal information)
- allowing anybody that could produce a valid digital certificate
(for the associated public key) with the non-repudiation bit on, to
magically turn all associated digital signaturesinto human
signatures (even digital signatures that had been presumably been
performed on random data for purely authentication operations).
since that time, the use of the certificate-based non-repudiation
bit has been severely depreciated (many people coming to realize that
it takes more than magical PKI bits to turn digital signatures into
human signatures).
there were some that started to realize that the PKI x.509 identity
certificate model represented severe privacy and liability issues. The
initial quick&dirty fix were the relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
containing just public key and some sort of database lookup index.
The issue here is that it is trivial to demonstrate that such
relying-party-only certificates are redundant and superfluous .... if
the relying party already has all the information, then the relying
party can directly look up the necessary information (including
registered public key as well as all integrity characteristics that
might be associated with that public key ... and the last thing they
need are redundant and superfluous relying-party-only digital
certificates).
a couple past posts mentioning confusing authentication and identification
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
https://www.garlic.com/~lynn/2005j.html#64 More on garbage
misc. past posts discussing dual-use attacks on digital signatures
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
https://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
numerous pasts posts discussing the non-repudiation characteristic
https://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#ocrp Online Certificate Revocation Protocol
https://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
https://www.garlic.com/~lynn/aadsm6.htm#nonreput Sender and receiver non-repudiation
https://www.garlic.com/~lynn/aadsm6.htm#nonreput2 Sender and receiver non-repudiation
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsmail.htm#complex AADS/CADS complexity issue
https://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
https://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
https://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign
https://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses "Authority-stamp-signatures"
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
https://www.garlic.com/~lynn/aadsm14.htm#48 basic question: semantics of "map", "tie", etc in PKI
https://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
https://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm16.htm#11 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
https://www.garlic.com/~lynn/aadsm16.htm#14 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm16.htm#17 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm16.htm#18 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm16.htm#23 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#55 MD5 collision in X509 certificates
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID?
https://www.garlic.com/~lynn/aadsm19.htm#12 EuroPKI 2005 - Call for Participation
https://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
https://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
https://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
https://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002j.html#24 Definition of Non-Repudiation ?
https://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2003f.html#37 unix
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature
https://www.garlic.com/~lynn/2003h.html#38 entity authentication with non-repudiation
https://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
https://www.garlic.com/~lynn/2003.html#29 Message (authentication/integrity); was: Re: CRC-32 collision
https://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
https://www.garlic.com/~lynn/2003k.html#6 Security models
https://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the same key for authentication and encryption
https://www.garlic.com/~lynn/2003o.html#22 securID weakness
https://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
https://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
https://www.garlic.com/~lynn/2003p.html#11 Order of Encryption and Authentication
https://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
https://www.garlic.com/~lynn/2004e.html#20 Soft signatures
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005d.html#32 Is a cryptographic monoculture hurting us all?
https://www.garlic.com/~lynn/2005e.html#41 xml-security vs. native security
https://www.garlic.com/~lynn/2005e.html#42 xml-security vs. native security
https://www.garlic.com/~lynn/2005g.html#51 Security via hardware?
https://www.garlic.com/~lynn/2005j.html#64 More on garbage
https://www.garlic.com/~lynn/2005k.html#23 More on garbage
https://www.garlic.com/~lynn/2005k.html#26 More on garbage
https://www.garlic.com/~lynn/2005k.html#55 Encryption Everywhere? (Was: Re: Ho boy! Another big one!)
https://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
https://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#6 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
Keeping an eye on ATM fraud
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Keeping an eye on ATM fraud
Date: Sun, 10 Jul 2005 15:50:17 -0600
To: cryptography@xxxxxxxx
http://www.atmmarketplace.com/news_story_23530.htm
Keeping an eye on ATM fraud
What happened to the good ole days when the magnetic stripe was king?
Remember those were the days when you didn't have to worry about ATM
devices that skim or trap. In today's techie world, those days are
long gone, and the mag-stripe's life is nearing its end.
... snip ...
note, as in previous posts ... it isn't just the skimming of static
data from the magstripe (as well as pin-hole cameras that capture any
pin) .... but it is being able to capture the static data at any point
in the infrastructure
https://www.garlic.com/~lynn/subintegrity.html#harvest
and use that static data in any kind of subsequent fraudulent transactions.
For the enforced PIN-debit and enforced x9.59 operations, it also
means that normal static data is never sufficient to perform a
transaction .... that authentication is always required.
The specific issue for PIN-debit is that technology advances are
making it easier to skim both the magstripe as well as the PIN ... and
then reproduce them for fraudulent transactions. enforced PIN-debit
does improve situation (compared to regular credit magstripe) that
harvesting static data from transaction logs is normally not
sufficient to perform fraudulent transactions. enforced PIN-debit
has somewhat higher resistance to the data breaches that have been in
the press ... since the necessary PIN won't be found in the standard
log and accounting files for standard business process (but PIN-debit
is still vulnerable to the skimming exploits at transaction origin).
ecdsa on x9.59 transactions
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy
won't expose any of the information to originate a fraudulent
transaction (the specific account number and digital signature may be
exposed ... but not the private key).
A PIN on digital signature transactions can act as a countermeasure
for lost/stolen token exploits. The issue is that the PIN doesn't make
a lot of difference on point-of-origin skimming exploits ... since the
PIN will nominally be captured (but not the private key). Digital
signature with private key (that is never divulged) for enforced
x9.59 transactions (i.e. the related static information can never be
used successfully for a non-x9.59 transaction) is sufficient
countermeasure against both skimming and harvesting vulnerabilities.
A lot has been made of two-factor authentication as being necessary as
countermeasure for majority of the current threats and
vulnerabilities. A majority of the current threats and
vulnerabilities are authentication infrastructures that use static
data for authentication (and the static data can be skimmed and used
for fraudulent transactions). Simple (static data) two-factor
authentication isn't a countermeasure for the skimming exploits, while
dynamic data (like digital signature) single factor authentication is
a countermeasure for the skimming and harvesting exploits.
US consumers want companies fined for security breaches
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: US consumers want companies fined for security breaches
Date: Sun, 10 Jul 2005 16:26:59 -0600
To: cryptography@xxxxxxxx
http://www.finextra.com/fullstory.asp?id=13952
US consumers want companies fined for security breaches
The majority of US consumers want to see criminal charges levied
against companies that fail to protect their personal data, as one in
five individuals admit falling victim to identity theft.
... snip ...
part of this is the risk proportional to security post that i frequently
repeat
https://www.garlic.com/~lynn/2001h.html#63
part of the issue is that these tend to not be security integrity
breaches that threaten the companies involved. these tend to security
privacy breaches that threaten the customers, where (static)
personal data can be used in account and/or identity fraud. In some
cases, as little information as a valid account number is sufficient
to generate a successful fraudulent transactions.
I had provided a motherhood statement for the x9.99 financial
standards privacy standard .... something to the effect that most
privacy security tends to require a rethinking of the security
landscape .... since these security threats aren't directly against
the institution, they are against customers of the institution (unless
the gov. can translate such privacy breaches into direct threats
against the institution in the form of fines or other
regulatory/legislative action).
somewhat related post
https://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
City National Bank is the latest major US company to admit it has lost customer data
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: City National Bank is the latest major US company to admit it has lost customer data.
Date: Mon, 11 Jul 2005 09:07:45 -0600
To: cryptography@metzdowd.com
http://81.144.183.106/Articles/2005/07/11/210820/AnotherUSbanksownsuptodataloss.htm
City National Bank is the latest major US company to admit it has lost
customer data.
The bank says it lost data back-up tapes in April, while they were being
transported to a secure facility by third-party data storage company
Iron Mountain.
The sensitive data contained account numbers, social security numbers...
... snip ...
the limits of crypto and authentication
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Mon, 11 Jul 2005 12:54:27 -0600
To: Perry E. Metzger <perry@xxxxxxxx>
CC: Florian Weimer <fw@xxxxxxxx>, cryptography@xxxxxxxx,
"Steven M. Bellovin" <smb@xxxxxxxx>
Perry E. Metzger wrote:
However, you need both the end to end communication and the hardware
token with built in display and keyboard.
there is two issues for digital signatures ...
- something you have authentication
- proof to the relying party as to the integrity level of the operations
it is possible to establish the integrity level of the hardware token
at the time the public key is registered ... and then possibly track
the token integrity level as it degrades over time (because of
technology advances).
in the EU finread standard case
https://www.garlic.com/~lynn/subintegrity.html#finread
it assumed that the display/pinpad and the token were separate. the
the case of relying party being able to evaluate the risk of the
transaction ... then it would actually need the separate
display/pinpad to also digitally sign the transaction (and also having
previously registered the finread terminal public key and integrity
level).
the co-signing by the separate display/pinpad was allowed for in x9.59
financial transaction standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy
but not mandated.
when the display, pinpad, and token are all a single device ... then
there would only be a requirement for a single digital signature ...
representing both the something you have authentication as well as
the integrity level of the signing environment.
in the human signature realm there is the aspect of many financial
point-of-sale termainals where there is requirement for some sort of
manual, human interaction that demonstrates some sort of agreement,
approval, and/or authorization of the transaction (in addition to the
authentication operation). frequently this is a display of the
transaction requiring the person to hit the agree/yes button ... as a
separate operation from any authentication operations.
the limits of crypto and authentication
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Tue, 12 Jul 2005 12:28:20 -0600
To: Perry E. Metzger <perry@xxxxxxxx>
CC: Ben Laurie <ben@xxxxxxxx>, cryptography@xxxxxxxx,
Florian Weimer <fw@xxxxxxxx>,
"Steven M. Bellovin" <smb@xxxxxxxx>
Perry E. Metzger wrote:
By the way, I note as an aside that this also means (in my opinion)
that certificates are no longer an interesting technology for
payments protocols, because in a purely online environment, you
never need a third party x.509 certificate in the course of the
payments protocol itself when there are no offline components of the
protocol and all relationships are bilateral.
my impression of the 3party x.509 identity certificate model of the
early 90s ... was that every person would pay $100/annum for their
identity certificate grossly overloaded with personal information.
the certificate model has a design point from the early 80s, offline
email, where the receiver dials their local (electronic) postoffice,
exchanges email and hangs up. they then are faced with dealing with
first time email from total strangers. the x.509 identity certificates,
grossly overloaded with personal information ... were targeted at
(hopefully) including at least one piece of personal information (about
the sender), that the receiver might find useful when dealing with total
stranger.
moving into the early 90s, with a model where everybody would have
$100/annum identity certificates ... the apparent business model would
be that all established business relationships would be done away with
... and people would only be performing spontaneous business
transactions with total strangers ... supported by the x.509 identity
certificates. For instance, rather than depositing money in an
established bank account .... you would spontaneously contact a total
stranger to accept your large sums of money. The exchange of x.509
identity certificates with total strangers would provide sufficient
trust and integrity to safegard your large sums of money.
Moving into the mid-90s, some institutions started to realize that such
x.509 identity certificates represented huge privacy and liability
issues and there was some implementations by financial institutions of
relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
which only contained a public key and some sort of database lookup index
(as unique information) along with a lot of CPS and other types of
certification accounting gorp. In this situation, it was trivial to show
that such relying-party-only certificates were redundant and
superfluous: the relying party already has all the necessary information
on file, which invalidates the certificate design point of providing
"letters of credit" type of information between two strangers in first
time communicate (where there is no other recourse for information about
the party you are dealing with).
of course, there was a side issue in these payment protocols from the
period. the typical iso8583 payment message is on the order of 60-80
bytes. the typical overhead for even the relying-party-only certificates
(attached to every payment message) was on the order of 4k-12k bytes ...
leading to an enormous payload bloat of one hundred times for something
that was totally redundant and superfluous.
In general, the design point of x.509 identity certificates were to turn
all transactions (regardless of kind, even the most lightweight
authentication transactions) into heavyweight identification operations.
You would even find some govs. passing legislation that was oriented
towards mandating x.509 identity certificate be appended to every
digital signed transaction ... even when you might be looking at purely
a lightweight something you have authentication operation.
misc. recent posts on the subject:
https://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand
the limits of crypto and authentication
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Tue, 12 Jul 2005 12:42:29 -0600
To: Perry E. Metzger <perry@xxxxxxxx>
CC: Ben Laurie <ben@xxxxxxxx>, cryptography@xxxxxxxx,
Florian Weimer <fw@xxxxxxxx>,
"Steven M. Bellovin" <smb@xxxxxxxx>
Perry E. Metzger wrote:
Ah, I see what you mean.
Sadly, I don't think there is much to be done about that, but I think
that (personally) I'd only end up with two of the things. If they can
be made credit card sized, I don't see this as worse than what I have
to carry now.
there are a couple of issues. in some ways .... if
institutional-centric physical tokens were to be successful ... you
would start to see one in lieu of ever pin, password, &/or shared-secret ... for every possible type of relationship requiring
authentication.
there was an issue in the early e-commerce days
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
a lot of the funding for the early commerce server work was targeted
at a "mall" type environment/experience ... where a large outsourcer
would provide electronic "mall" space for retail stores. The apparent
assumption was that the physical distance metaphor addressed by
shopping malls, would be carried over into the internet. however, the
basic characteristic of the internet & the world-wide-web already was
obliterated physical distance concepts. the issue then was why would a
metaphor designed to address physical distance limitations, carry over
into an environment where physical distance was a meaningless concept.
the issue with many of the existing issued cards and tokens are that
they are institutional-centric, one per institution. this could
approach the DRM/copy-protect approach of the mid-80s ... where
applications were being shipped with unique floppy disks that were
required to be mounted anytime the application was executed. an
operation with one or two such applications wouldn't be so bad ... but
can you imagine that being successful today? .... where you might have
hundreds of such floppy disks and requirement to have a dozen such
floppy disks concurrently mounted in a single floppy drive ... and
possibly having to select and exchange floopy disks (from a pile of
hundreds) several times a minute.
i contend that the physical store checkout and payment model ... where
you are physically performing checkout and can likely do only one such
at a time .... has analogies to the shopping mall physical metaphor
model ... and it starts to hit limitations when you translate that
into internet electronic metaphor with the possibility of multiple
things going on concurrently
EMV
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxx>
Subject: Re: EMV
To: gabriel
CC: 'Ben Laurie' <ben@xxxxxxxx>, cryptography@xxxxxxxx,
'Peter Fairbrother' <zenadsl6186@xxxxxxxx>,
'Florian Weimer' <fw@xxxxxxxx>,
'David Alexander Molnar' <dmolnar@xxxxxxxx>,
'? Schmidt' <joern2473@xxxxxxxx>
Gabriel Haythornthwaite wrote:
In Hong Kong a lot of people do little more than wave their bags at the
turnstile. Removing the wallet and revealing its size is unnecessary.
... the original introduction of HK octopus transit card used the
"sony" flavor of iso 14443 with 10cm and transit requirements of
transaction in 100ms. having it in the bottom of a bag and bringing the
bag within 10cm of the reader does the trick.
there was a transit meeting where the mondex people attended ... they
claimed that they could also be used for transit ... just get a wireless
sleave for the mondex card ... and build 14' long tunnels leading up to
the transit gates ... and have the people walk slowly thru the tunnels.
UK EU presidency aims for Europe-wide biometric ID card
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: UK EU presidency aims for Europe-wide biometric ID card
Date: Wed, 13 Jul 2005 10:49:30 -0600
To: cryptography@xxxxxxxx
http://www.theregister.com/2005/07/13/uk_eu_id_proposal/
UK EU presidency aims for Europe-wide biometric ID card
The UK is using its Presidency of the Council of the European Union to
push for the adoption of biometric ID cards and associated standards
across the whole of the EU. In a proposal issued on Monday (11th
July), the UK calls for the drafting of "common standards for national
identity cards taking into account the achievements in relation to the
EU passport and in the ICAO framework."
,,, snip ...
note that some EU govs. are trying to have legislation that has an
x.509 identity certificate appended to every digital signature. this
effectively turns even the most lightweight digital signature
authentication even into a heavyweight identification event.
when we were called into help word-smith the cal. state and later the
fed. electronic signature law ... a lot of effort went into making the
wording technology agnostic as well as trying to avoid confusing
authentication and identification. the other force that was somewhat
at work was moving things in the direction that a digital signature
could take on the attributes of a human signature (possibly because of
semantic confusion over both terms; digital signature and human
signature containing the word signature) ... including that if a
digital signature was discovered ... that human intent, read,
understand, agrees, approves, and/or authorizes was somehow
implicit in the existance of a digital signature.
the limits of crypto and authentication
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Thu, 14 Jul 2005 08:25:42 -0600
To: Rich Salz <rsalz@xxxxxxxx>
CC: Perry E. Metzger <perry@xxxxxxxx>, <cryptography@xxxxxxxx>
Rich Salz wrote:
Wasn't that a goal of SET?
there was an observation that SET possibly wouldn't divulge your
account number until the merchant had been determined to be some
entity registered as a merchant (akin to the SSL domain name
infrastructure certificates ... if a spoofed site didn't use SSL until
you hit the pay/checkout button, what is the probability that a
spoofed site provides a URL that matched some valid certificate that
they have).
note, however, some of the participants even got confused about this issue.
note, that there are a lot of merchant business processes that require
the account number ... and therefor you can't prevent the merchant
from possessing the account number. some might be tempted to observe
that there is a kind of conflict of interest ... using the same value
for authentication purposes as well as widely needed for a large
number of other purposes (akin to designing a system that widely uses
your userid a basis for normal functioning ... as well as making your
userid also your password).
some past posts where the SET issue of divulging account number was
disucssed.
https://www.garlic.com/~lynn/2001h.html#38 Credit Card # encryption
https://www.garlic.com/~lynn/2001h.html#39 Credit Card # encryption
https://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
https://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
I thot the goal of SET was to maximize the number of RSA-ops being
executed in the world.
When I first obtained a copy of the initial SET specification, I did a
RSA-ops profile and a business operation profile. An acquatance had
done some work on the BSAFE library and improved the performance by a
factor of four times. I got him to run timing tests on the SET RSA-ops
profile across a number of different machines. I then communicated the
results to a number of people that were part of the SET group. The
reply from various members of the SET group was that the numbers were
obviously one hundred times too slow (the correct answer should have
been that the numbers were four times too fast). Six months later when
the first prototype SET code was running ... their measured numbers
were within a couple percent of my earlier profile numbers (aka the
BSAFE enhancements had been given back to RSA).
One possible observation was that SSL work
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
was already providing account number confidentiality for
data-in-flight. The significantly much more complex, and
heavyweight SET would have needed to provide countermeasures for
significantly more threats and vulnerabilities ... like security for
data-at-rest (aka data breaches) in order to make any headway
against the (SSL) incumbant.
I also made a couple comments to the SET group about the heavy-weight
nature of SET (apparently the RSA-ops being one hundred times more
onerous than they believed). Effectively, the SET RSA-op profile was
symmetrical .... but the standard processing is quite asymmetrical.
In effect, the massive datacenters that are currently processing
credit card transactions would have needed their computational
facilities increased by at least one hundred times (SET RSA-op profile
was looking at tens of seconds per transaction while many of these
datacenters measure their thruput in thousands of transactions per
second ... a four orders of magnitude gap).
the limits of crypto and authentication
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Thu, 14 Jul 2005 11:09:21 -0600
To: Aram Perez <aramperez@xxxxxxxx>
CC: cryptography@xxxxxxxx
Aram Perez wrote:
While the SET protocol was complicated, it's failure had nothing to
do with that fact or the lack of USB on PCs. You could buy libraries
that implemented the protocol and the protocol did not require USB.
IMO, the failure had to do with time-to-market factors. In the late
90s, when ecommerce was just at it's infancy and you took the risk
of setting up a web store, were you going to wait you could
integrate a SET toolkit into you web site and until your customers
had SET wallets installed on their PCs before selling a product? Or
were you going to sell to anyone who used a web browser that
supported SSL? It was very simple economics, even if you had to pay
VeriSign $400 for your SSL certificate and pay Visa/MasterCard a
higher fee.
can you say that processing overhead was on the order of 20-30 seconds
(on completely unloaded infrastrucutre ... demos at shows and
conferences ... can you imagine what a little bit of queuing load
would do to it?) ... if merchants thot SSL was onerous ... just
imagine what SET did to the infrastructure .... and it provided
effectively no additional improvement over fraud vis-a-vis effectively
only addressing the confidentiality of account numbers as
data-in-flight.
SSL was the encumbant, was significantly less complex and
significantly lighter weight (even tho most merchants decided that it
was too heavy except for the credit card portion) and provided
effectively the same amount of anti-fraud as SET.
If you had two products ... both effectively performing the same
function, one you already had deployed, which was significantly
cheaper, significantly simpler, and significantly faster, which one
would you choose?
the limits of crypto and authentication
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Thu, 14 Jul 2005 11:41:52 -0600
To: pfarrell@xxxxxxxx
CC: cryptography@xxxxxxxx
Pat Farrell wrote:
As others have said, and in the spirit of the subject of this
thread, SET failed for many reasons, many of them economic. There
was little effort made to bribe the merchants, I think there was
talk of a 26 basis point change in the discount rate, which the
banks thought was huge and the merchants thought was noise. What
really killed it was the billions it would have cost all the banks
to issue and manage all the certificates.
this was some of the confusion between identification and
authentication. The SET effort was smart enuf to not do x.509 identity
certificates and instead do relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
and they even made comments about the enormous privacy and liability
issues raised with x.509 identity certificates.
They also avoided doing any sort of PKI infrastructure ... aka the
management and administration of the certificates. The effectively
were doing the same stuff as the original SSL domain name certificates
... for which we coined the term certificate manufacturing (to
differentiate from a PKI certificate administrative and management
operation). They basically said that the certificate only contained
the account number ... and the account number could be turned-off at
the issuing financial institution ... making it redundant and
superfluous to also have to have a separate infrastructure for
invaliding the certifcate.
So they have an online infrastructure with real-time transactions and
real-time operation of the real information. It is an extremely
trivial additional step to show that then the certificates themselves
are redundant and superfluous.
The cost of the certificates only become an issue if you are talking
about having to pay a trusted third party, $100/annum for every
certificate.
So we can take this in incremental steps.
- you have the consumer's financial infrastructure register the
public key. they then can generate and issue a relying-party-only
certificate to the consumer (containing the consumer's public key and
account number).
- there was work started in X9 financial standards body on compressed
certificates. Even the SET relying-party-only certificate overhead ran
4k-12k bytes. The typical iso8583 financial message is on the order of
60-80 bytes. Even the trivial SET relying-party-only certificates
represented a payload bloat of one hundred times (besides the RSA-ops
inflating processing overhead by 3-4 orders of magnitude).
- Because of the enormous payload bloat contributed by the
certificates, the digital signature processing was being truncated at
the internet boundary and a standard iso 8583 message was then
generated with a flag turned on indicating that the internet had
validated the digital signature. The merchants had an incentive to see
that flag turned on since that was the basis on which a lower discount
was calculated. At an ISO meeting in europe ... one of the association
network people presented statistics on the number of iso 8583 messages
that they found with the flag turned on and they could prove that no
digital signature technology could have been involved
- I presented an argument that a valid compressing technology is to
eliminate all fields from the (certificate) contents that were known
to already be in possession of the relying party. Since it could be
proved that all fields in the SET relying-party-only certificate were
already on file with at the consumer's financial institutions ... it
would be possible to eliminate all fields from the relying-party-only
certificates. If they preferred, i would start describing the process
of appending zero byte digital certificates as an alternative to
describing certificate-less digital signature operation
https://www.garlic.com/~lynn/subpubkey.html#certless
- The consumer's financial institution could effectively use the
existing business processes for registering PINs as a mechanism for
registering public keys. That is not known to be an expensive business
process. A consumer's financial institution then could set up a
website where the consumer could later retrieve their (redundant and
superfluous relying-party-only) digital certifcate. There are some
integrity constraints here ... but since the purpose of a digital
certificate is to spray it all over the world ... there isn't a lot of
confidentiality constraints (i.e. it doesn't hurt a lot if other
people pick up your digital certificate). However, since both the
public key and the digital certificate would already be on file
... you could require people to perform digital signature
authentication before picking up their redundant and superfluous
digital certificate. This does have an unfortunate downside since it
highlights that consumer digital signatures can be validated by onfile
public keys w/o needing digital certificates
- there were lots of comments that leaving all the PKI gorp in the
hands of trusted third parties was a trade-off of the
$100/annum/certificate against the upfront costs of modifying mainline
production systems. The two problems was that only worked as long as
the PKI stuff was being limited to toy demos. For any sort of
production roll-out,
- the $100/annum/certificate would exceed the costs of upgrading
mainline production system,
- toy demos didn't have to worry about customer calls, if you wanted to
provide a service, you have to take trouble/customer calls. To have
integrated financial institution trouble/customer service ... you have to
integrate the public key stuff into the production systems.
aka ... the only scenario where you could use trusted third party
trade-off of $100/annum/certificate against modifying production
systems was in the toy demo stage.
- concurrent with SET ... we were also working in the X9A10 financial
standards working group ... which had been charged with preserving the
integrity of the financial infrastructure for all retail payments. we
had done many of the detailed business and technology issue
examination coming up with x9.59 standard ...
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy
which then made it much easier to spot them in the SET specification.
the limits of crypto and authentication
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Thu, 14 Jul 2005 23:15:13 -0600
To: Rich Salz <rsalz@xxxxxxxx>
CC: Aram Perez <aramperez@xxxxxxxx>,
<cryptography@xxxxxxxx>
Rich Salz wrote:
I was told that one of the reasons SSL took off was because Visa
and/or MC told merchants they would "for the time being" treat SSL
as card-present, in terms of fraud penalties, etc. If this is true
(anyone here verify? My source is on the list if s/he wants to name
themselves), then SSL/SET is an interesting example of betting on
both sides.
I only know of MOTO ... the original netscape e-store and merchants
processed thru the original payment gateway.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
SSL originally just provided for webserver authentication. while we
mandated mutual authentication for SSL between webservers and the
payment gateway (before there was even a specification for mutual
authentication). Information about the respective other end-point were
preloaded in the respective servers ... so the use of digital
certificates was purely an artificial artifact of the existing code
base.
However, normal merchant webserver operation for SSL was purely
one-sided authentication ... there was no form of client
authentication that would provide any kind of basis for either
cardholder-present or card-present.
There is something for being there first, starting late 94 ...
http://scout.wisc.edu/Projects/PastProjects/NH/95-03/95-03-27/0016.html
remember what Verisign was called before it was renamed Verisign?
SET prototype shows up early fall 96 with dedicated demo systems
appearing at conferences late '96 (dedicated demo systems taking 30
seconds elapsed time to perform transaction).
Two of the major risks and vulnerabilities that have been discussed
are evesdropping on data-in-flight ... and data breaches at merchant
databases ... old post on security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
both SSL and SET addressed confidentiality of data-in-flight. Neither
SSL nor SET addressed data breaches at merchant databases.
Going on in parallel with webservers doing MOTO transactions thru the
payment gateway .... you also found some number of webservers doing
emulated POS terminal dialup operations (also MOTO transactions). Some
number of vendors were peddling software that was originally developed
to run on PCs and autodial merchant processor (effectively emulated
POS terminal dial) ... software originally targeted for hotels,
casinos, etc.
... from long ago and far away:
Date: Sat, 24 Feb 1996 17:08:01 -0500 (EST)
From: H Morrow Long <long-morrow@cs.yale.edu>
To: sneakers@cs.yale.edu
Subject: Draft SET Standard/specs now online at MC and Visa
The new SET (Secure Electronic Transaction) draft standard/
specs are now online at VISA and Mastercard for downloading.
The draft docs were just released yesterday (Feb 23).
The docs are available in Word and Postscript file formats
for Windows, Unix and the Mac.
Check out:
http://www.mastercard.com/set/set.htm
http://www.visa.com:80/cgi-bin/vee/sf/standard.html?2+0
The Web pages also have information on how to subscribe to
the set-discuss mailing list.
- Morrow
ID "theft" -- so what?
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: ID "theft" -- so what?
Date: Fri, 15 Jul 2005 11:44:45 -0600
To: Ian Grigg <iang@xxxxxxxx>
CC: Aram Perez <aramperez@xxxxxxxx>,
cryptography@xxxxxxx
Ian Grigg wrote:
Personally, I call "what PGP does" a Web of Trust.
And I call what browsers do a PKI. The fact that
there is "trust" in PKI and there is "infrastructure"
in WoT is an issue, yes, but we have to have some
sense of differentiation; and those terms are what
the people in those fields tend to be comfortable
with.
simple, PKI basically was designed for situations where you trusted
somebody else to do your trusting ... this is the letters of credit
paradigm from the sailing ship days. most modern business processes go
to great deal of trouble to manage their own trust ... they have
account databases, relationship management systems, accounts
receivable, accounts payable, etc, etc ...
these business operations with their own well established trust
infrastructure ... are in need of better authentication technology.
public/private key and digital signature business process can supply
that better technology.
a lot of PKI likes to focus on PKIs being able to supply organizations
with a trust infrastructure ... so the organizations can avoid
developing their own trust infrastructure.
the truth is that very few business operations actually lack a trust
infrastructure. however, many have a need for upgrading the
authentication technology in their existing trust
infrastructures. PKIs like to get them focused on such technology
upgrade actually mandating creating a (duplicate redundant and
superfluous) PKI trust infrastructure.
there has been significant financial incentive for PKIs to propagate
the concept that they are the only kind of real trust infrastructure
in existance. when they can't avoid acknowledging that a business
operation might already have an existing trust infrastructure
... frequently there is recourse to obfuscation, trying to imply that
the PKI-based trust infrastructures carry magical properties that
other trust infrastructures will never be able to have.
the limits of crypto and authentication
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: the limits of crypto and authentication
Date: Fri, 15 Jul 2005 12:13:35 -0600
To: Rich Salz <rsalz@datapower.com>
CC: Aram Perez <aramperez@mac.com>,
cryptography@metzdowd.com
ref:
https://www.garlic.com/~lynn/aadsm20.htm#12 the limits of crypto and authentication
a harder problem for early stage web merchants was getting a merchant
financial institution .... the merchant financial institution that
sponsors a merchant for payment transactions ... takes financial
responsibility for that merchant.
the standard procedure was to send somebody out to the retail
brick&morter and do an asset inventory ... to see if the merchant
went under ... that there would be enuf assets left to help cover the
merchant financial institutions losses.
retail web merchants might have nearly zero assets ... they leased
time with a webhosting and fulfillment was outsourced ... so there was
no onhand inventory and effectively no assets. if they were totally
unsuccessful ... then the merchant financial institution would have
little outstanding transaction financial liability.
there were cases where merchant financial institution would try and
cancel a merchant as it became successful ... since the outstanding
transaction liability for the merchant financial institution could be
going way up ... with no increase in assets to cover the finanical
institution's outstanding liability.
for such "high risk" merchants ... the merchant financial institution
discount might actually be bigger than the MOTO discount ... or any
difference between MOTO and card-present.
early web merchants tended to be existing brick&morter operations
where web MOTO ("mail-order/telephone-order") transactions were not
separated out from non-web MOTO transactions.
there were all sorts of strategy meetings in the '95 time-frame, brain
storming about how to get a bank's financial risk department to even
approve purely web merchant signup (and MOTO vis-a-vis card-present
wasn't a primary issue).
misc. past posts mentioning merchant financial institution:
https://www.garlic.com/~lynn/ansiepay.htm#x959demo X9.59/AADS demos operational
https://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature
https://www.garlic.com/~lynn/aepay11.htm#65 E-merchants Turn Fraud-busters (somewhat related)
https://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
https://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aadsm18.htm#15 In Search of Eve - the upper boundary on Mallory
https://www.garlic.com/~lynn/aadsm19.htm#39 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
https://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#19 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#13 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#13 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#14 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#17 The Worth of Verisign's Brand
the limits of crypto and authentication
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Fri, 15 Jul 2005 12:35:29 -0600
To: Aram Perez <aramperez@xxxxxxxx>
CC: cryptography@xxxxxxxx
Aram Perez wrote:
One other point, SET did NOT require certs for the consumers. The
client-merchant protocol supported clients without certs.
there was a later "set-lite" w/o certs for clients ... but the
original specification had client certs as part of the core process.
note that the SET consumer certificate was NOT a x.509 identity
certificate ... because of stated reasons regarding privacy and
liability. It was a relying-party-only certificate that basically
contained the account number and the public key
https://www.garlic.com/~lynn/subpubkey.html#rpo
It was also, not a true PKI ... since it didn't have any certificate
administration and management infrastructure. It was purely a
certificate manufacturing process (a term we had coined to
differentiate the early SSL certificate operations from what had been
defined for a PKI operation). Further, the statement was that they
could get by w/o a PKI operation ... since it was purely a
certificate manufacturing process using relying-party-only
certificates (containing just the public key and account number), the
business process could be managed by deactivating the account number
in the real, real-time, online operation.
note the attached reference is dated 3/22/1999 ... and comments
about SET being deployed two years earlier ... aka spring 1997;
compared to the 1994 original deployment for SSL
quicky search engine for set-lite:
http://iugsun.cs.uni-dortmund.de/lehre/datenschutz/material/folien/dsss2004-5-ecommerce.pdf
http://www.it.murdoch.edu.au/~smr/honours/admin/info/DavidsProposal.html
http://www.indiainfoline.com/bisc/ieps.html
http://www.networkworld.com/archive/1999/61423_03-22-1999.html
from above:
When MasterCard and Visa unveiled technology for secure Internet
electronic commerce transactions two years ago, they thought it would
take over the world.
But while Secure Electronic Transaction (SET) has made inroads in
Europe and Asia, it has faltered badly in the U.S. Faced with
technical and business obstacles to SET, MasterCard and Visa are now
coming up with alternatives to SET - SET Lite and Merchant-originated
SET (MOSET).
But SET Lite and MOSET critically alter the SET 1.0 architecture and
soften SET's rock-hard security - all for the sake of convenience. For
example, the technologies abandon the idea that each online consumer
is going to have a bank-issued SET digital certificate for credit-card
encryption. This certificate was to be the main means of verifying the
consumer's real identity on the Internet.
... snip ...
the limits of crypto and authentication
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Fri, 15 Jul 2005 13:05:11 -0600
To: Ram A Moskovitz <ram0502@xxxxxxxx>
CC: cryptography@xxxxxxxx
Ram A Moskovitz wrote:
Did you consult for First Data Corp. at the time?
some reference:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
little later, we got to review chaum and brand stuff. brand had done a
take-off on chaum's stuff so that if somebody double-spent (aka fraud)
... the financial institution could determine who did it (basically a
form of solving two equations in two unknowns).
the limits of crypto and authentication
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Sat, 16 Jul 2005 10:48:14 -0600
To: cryptography <cryptography@xxxxxxxx>
CC: Aram Perez <aramperez@xxxxxxxx>
Anne & Lynn Wheeler wrote:
But SET Lite and MOSET critically alter the SET 1.0 architecture and
soften SET's rock-hard security - all for the sake of convenience. For
example, the technologies abandon the idea that each online consumer is
going to have a bank-issued SET digital certificate for credit-card
encryption. This certificate was to be the main means of verifying the
consumer's real identity on the Internet.
ref:
https://www.garlic.com/~lynn/aadsm20.htm#15 the limits of crypto and authentication
note that the bank-issued consumer SET digital certificate ... wasn't
used for credit-card encryption. the original set had this terribly
convoluted process where the consumer encrypted some of the stuff with
the merchants public key and other stuff with the processors
public key.
the consumers relying-party-only digital certificate
https://www.garlic.com/~lynn/subpubkey.html#rpo
was used for the client to perform something you have authentication
... aka digitally signing with the corresponding private key (aka the
verification of the digital signature implies that the signer has
access and use of the private key)
since it wasn't an x.509 identity certificate, didn't contain any
personal information, and was purely a relying-party-only certificate
... there was no real identity on the internet (avoiding raising
horrible privacy and liability issues).
futhermore, since it was a simple relying-party-only certificate, it
is trivial to demonstrate that it is redundant and superfluos ... aka
just flow the transaction thru to the consumer's bank ... and they can
validate the digital signature using the onfile public key. it isn't
necessary for the consumer to repeatedly append a relying-party-only
certificate to possibly thousands of transactions ... for transmission
back to the issuing institution ... which has the original onfile;
especially when the redundant and superfluous relying-party-only
certificate can represent a payload bloat of one hundred times.
note that the referenced article is dated 1999/3/22 and references the
original SET 1.0 deployment (full blown redundant and superfluous
relying-party-only customer certificates) two years earlier (spring
1997). The draft 1.0 specification had appeared spring 1996, initial
prototype appeared early fall 1996, and dedicaed demo systems showed
up at floor shows by the end of 1996.
the other reference indicates that browsers with ssl support appeared
late 1994 with big announcement the spring of 1995.
https://www.garlic.com/~lynn/aadsm20.htm#12 the limits of crypto and authentication
a trivial side-note ... since the SET specification wasn't issued by a
sanction standards body ... it wasn't a Standard in the official
sense.
one of the operational differences between SET and x9.59 financial
industry standard ...
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy
is that x9.59 has an operational rule that account numbers used in
x9.59 transactions can't be valid in non-x9.59 transactions .... which
eliminates the requirement for horrendous amounts of cryptography as
countermeasure for evesdropping of transactions during transmission
(since evesdropping of the transactions doesn't provide an attacker
with sufficient information to perform fraudulent transactions). As a
by-product, it also eliminates the threats and vulnerabilities from
data-breaches ... where there is insufficient information in logged
transactions for a crook to perform fraudulent transactions.
In the SET scenario ... even when the transaction is authenticated
using digital signature ... there was still a requirement for horribly
complex cryptographic implementation as countermeasure to attacker
evesdropping the transaction and using the gained information to
perform fraudulent transactions.
There is an issue where both account fraud and identity fraud have
been lumped under global identity theft label. In the strict account
fraud case, the attacker just needs to obtain sufficient information
to perform fraudulent transactions (against existing accounts) w/o
necessarily obtaining any real personal information.
While SET avoided the horrible privacy and liability issues with real
x.509 identity certificates by using relying-party-only certificates
... it was still subject to account fraud where crooks obtaining
access to information from transaction (either data-in-flight or
data-at-rest .... aka data breaches) have access to sufficient
information for performing fraudulent transactions.
In contrast, x9.59 is signifcantly simpler and represents
significantly lighter payload ... and even eliminates the need to
provide security confidentiality for transactions as countermeasure
against attackers (both in the data-in-flight as well as the
data-at-rest cases) looking at performing account fraud
transactions.
past posts mentioning x9.59 & business rules:
https://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
https://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
https://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
https://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm9.htm#cfppki11 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#28 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
https://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
https://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and authentication
https://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#0 e-commerce security????
https://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site
https://www.garlic.com/~lynn/2002n.html#14 So how does it work... (public/private key)
https://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004m.html#9 REVIEW: "Biometrics for Network Security", Paul Reid
https://www.garlic.com/~lynn/2005k.html#26 More on garbage
https://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
the limits of crypto and authentication
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Mon, 18 Jul 2005 10:07:47 -0600
CC: cryptography <cryptography@xxxxxxxx>,
Aram Perez <aramperez@xxxxxxxx>
ref:
https://www.garlic.com/~lynn/aadsm20.htm#10 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#15 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
one of the issues raised in the x9.59 business rule case was whether
there are sufficient PANs (account numbers) to be able to temporarily
be able to issue two PANs for every account; one PAN usable against
account in X9.59 transactions and one PAN usable against account in
non-X9.59 (legacy, non-authenticated) transactions.
there was some issues raised about having multiple PANs pointing at
the same account ... but that is in wide-spread use already as normal
business practice.
Note that during any transition to secure x9.59 transaction ... the
worst case scenario is that there would be two PANs in existance for
every account. The issue raised whether the account number space is
large enuf to have two PANs for every account (note that if this turns
out to be a real issue ... it would also be a much larger problem for
one-time-PAN implementations ... where you might have hundreds of PANs
mapped to the same account).
The problem for an X9.59 transition is actually somewhat less severe.
Part of the current PAN strategy is stacked against re-use of a PAN.
However, in the x9.59 transition case, I would claim that PAN re-use
is much less of a problem
- re-use of any PAN for x9.59 use .... automatically disables the PAN
for all non-x9.59 use (if the PAN had some lingering legacy attachment
... that woulc be disabled as soon as it was assigned for x9.59 use)
- re-use of a previously assigned x9.59 PAN for x9.59 use ... could
happen on somewhat accelerated schedule ... since the previous x9.59
PAN use would have been associated with a public key that was no
longer active.
the lingering issue as dangling business process associated with old
transactions that are bound to a specific PAN. re-use of PANs need to
after any such dangling business processes have been assured to have
expired.
the upside is that any transition to x9.59 would then give the
consumer some choice and/or control ... strict use of x9.59
transactions would give the consumer some protection against most
skimming, havesting and data breach threats and vulnerabilities. such
a consumer might then want any non-x9.59 PANs to have very strict use
limits (akin to some of the customer specified limits available on
pin-debit accounts ... or what is available on dependent cards).
the limits of crypto and authentication
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Tue, 19 Jul 2005 13:20:47 -0600
To: Jaap-Henk Hoepman <jhh@xxxxxxxx>
CC: cryptography@xxxxxxxx
Jaap-Henk Hoepman wrote:
Actually, Dutch banks already give users the option to recieve
one-time pass-codes by SMS to authenticate internet banking
transactions (instead of sending a list of those codes on paper by
ordinary mail in advance). So it's less unrealistic than you think.
there is also the EU bank challenge/response scenario (requires
two-way communication protocol chatter). the customer initiates a
transaction ... on the internet or even over (voice) phone. the bank
responds with a challenge which is entered into a calculator sized
device and the display comes back with the response. the response then
is either typed or the keyboard (or the phone keypad).
basically it is a relatively dumb pin-pad sleave that a chipcard slips
into ... some old post visiting the company that makes the devices:
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
ID "theft" -- so what?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: ID "theft" -- so what?
Date: Thu, 21 Jul 2005 10:28:33 -0600
To: Jeffrey I. Schiller <jis@xxxxxxxx>
CC: Jerrold Leichter <jerrold.leichter@xxxxxxxx>,
John Denker <jsd@xxxxxxxx>,
"Perry E. Metzger" <perry@xxxxxxxx>, cryptography@xxxxxxxx
Jeffrey I. Schiller wrote:
Btw. There are credit card issuers (AT&T Universal is one) that
permits you to create a virtual one-time use credit card (with a time
limit and $$ limit if you want).
So when I shop at a merchant I don't want to trust, I open another
browser window and go to my issuers website and obtain a one-time card
number and use it at the merchant site. I can usually see immediately
after the purchase that the card has been used (on the issuers website)
so I know the merchant is checking the card in real time.
Apparently there is wallet software that will do this in a more
automated fashion, but it isn't available for my platform (non-Windows).
an analogy i've used recently with respect to userid/password
paradigm,
https://www.garlic.com/~lynn/2005m.html#42 public key authentication
is that account numbers are being concurrently used for both the
userid function (requiring security integrity but not security
confidentiality) as well as the password function (requiring strong
security confidentiality). as a result there are frequently
diametrically opposing requirements where the muiltitude of
userid-type business functions require access to the account number
... at the same time, the password-type functions require that the
account number be kept strictly confidential and not be available at
all.
the x9a10 working group was given the requirement to preserve the
integrity of the financail infrastructure for all retail payments. the
resulting x9.59 protocol
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
- allowed for single round-trip, straight-through processing found at
many point-of-sale ... w/o requiring extraneous protocol chatter
- created a strictly enforced separation of the account number as a
userid-type function from digital signature as a password-type function
this eliminated the strongly conflicting goals of very weak
confidentiality requirement for use of the account number in the
multitude of userid-type business processes at the same time having a
very strong confidentiality requirement for the same account number
in its role as passoword/authentication.
this had the downside that there was potentially a maximum of two PANs
allocated for the same account during some transition period (where
both legacy, conflicting use of an account number was required and the
new x9.59 use of an account number requiring separate authentication).
it was startling that some of the strongest opponents of x9.59
claiming that there wasn't large enuf PAN space available to have a
maximum of two PANs per account (during some transition periods)
... subsequently were strong backers of one-time-use PANs ... which
might result in potentially hundreds of PANs being mapped to the same
account.
https://www.garlic.com/~lynn/aadsm20.htm#18 the limits of crypto and authentication
Qualified Certificate Request
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Qualified Certificate Request
Date: Thu, 21 Jul 2005 12:20:51 -0600
To: pg@xxxxxxxx
CC: cryptography@xxxxxxxx
Philipp Gühring wrote:
Regarding the requirements for qualified certificates, the only
obstacle we still have is the problem, that CAcert has to make sure,
that the private key for the certificate is generated and stored
securely in a SmartCard, or another Hardware Token. Since the users
should be able to issue the certificates at home, we need a
technical solution to make sure, that the private key is from within
a SmartCard, when we receive a certificate request.
aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads
took a different approach ... the key pair is generated during the
power-on chip test process ... before the wafer is even sliced and
diced and the public key becomes an attribute of the chip (along with
some number of other individual chip specific integrity
characteristics).
the resulting digital signature from the token isn't intended to
represent who you are ... it is intended to provide something you
have authentication ... aka the verification of the digital signature
then implies that the individual has access to and use of the
corresponding private key (and the specific hardware token that
contains it). the private key is never divulged and the public key and
the digital signature represent characteristics of the something you
have authentication.
the public key can be registered ... and there is a service that
allows a relying party to retrieve the integrity characteristics of
the hardware token associated with the public key.
the issue is that the majority of the existing business processes go
to a great deal of trouble binding an identity to some set of business
process characteristics. the incremental issue for the majority of the
business processes in the world ... isn't with respect to who an
individual is ... but what are all the integrity and assurance
characteristics associated with the actual authentication business
processes.
the overall integrity and assurance characteristics associated with
hardware token public key digital signatures ... includes (at least)
the current time-varient characteristics of the specific chip
(apparently identical hardware tokens might have different chip
generations with different assurance characteristics depending on the
date/time of the manufacture of the specific chip), the key length, the
particular digital signature algorithm, the environment in which the
digital signature occured, whether the hardware otken performed a
digital signature with or w/o an associated PIN entry or with or w/o
an associated biometric entry.
I've frequently asserted in the past that some number of PKI-oriented
interests have muddled and obfuscated the fundamental assurance issues
that most business processes have a real need-to-know ... and attempted
to substituted things that certification authorities might be doing when
certification of information for inclusion in a digital certificate.
However, for the majority of things that have been talked about for
stuff that goess into certificates (like information for x.509
identity certificates) ... is stuff that duplicates operations by long
existing and well established business process relationship management
infrastructures.
One might conjecture that since most such PKI-oriented deployments
didn't provide the components of the end-to-end actual authentication
environment (hardware tokens, singing environments, validation
environments) ... that it was in their interest to maximize the
perceived value of the (mostly redundant and superfluous digital
certificates duplicating existing business process of long existing
and well established relationship management infrastructures) digital
certificates and minimizing the perceived value of the other really
important assurance components of interest to relying parties.
ID "theft" -- so what?
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: ID "theft" -- so what?
Date: Thu, 21 Jul 2005 16:48:49 -0600
To: Jerrold Leichter <jerrold.leichter@xxxxxxxx>
CC: Jeffrey I. Schiller <jis@xxxxxxxx>, John Denker <jsd@xxxxxxxx>,
Perry E. Metzger <perry@xxxxxxxx>, cryptography@xxxxxxxx
Jerrold Leichter wrote:
If this is all you need, then using a 1-way hash of the card number
for identification and the card number itself for security would
give you much of what you need. There are databases out there which
identify customers by their CC numbers, not because they are willing
to use the stored CC number for charging, but just becauses it's a
good unique ID. If what were stored were the 1-way hash, there
would be nothing worth stealing in the database. This kind of thing
is actually implemented, though people rarely think of it in these
terms. You can see it on many printed charge slip these days: Your
CC number no longer appears, being replaced by a one-way hash that
produces 12 X's and the last 4 digits of your number. Hardly
cryptographically strong in the usual sense, and not generally
applicable, but for ID purposes - letting you identify which of your
cards you used when making the charge - this particular one-way hash
is perfectly good. (It's also common on Web forms that tell you
which of your cards a charge will be applied to.)
there was a vulnerability where attackers took the published algorithm
for valid account numbers and attacked using account numbers that
satisfied the published algorithm. somewhat as a result, guite some
time agao, the CVV field was added to the magstripe ... which could be
considered a kind of one-way hash of the contents of the magstripe ...
with some other stuff that is not predictable from the algorithm (as a
countermeasure to attacks from automatically generated account
numbers).
one of the "business processes" is that somebody calls their issuing
bank and disputes a charge by a specific merchant on such & such a
date. the issuing bank eventually provides notice to the merchant
(giving the account number, date, and purchase details). the merchant
then looks for a transaction (in their transaction log) for that
account number on that date. In some cases, the merchant bank
processor may provide an online service for merchants ... where the
merchant processor keeps the online merchant transaction log on behalf
of merchants for things like dispute resolution (this may include
things like online library of digital images of the original
reciepts).
There was a least one processing specification (possibly even
mandatory) during the 90s ... where each transaction was giving a
unique transaction identifier ... and transaction logs were only to be
referenced by the transaction identifier. However, consumers only
identified their account number by their account number ... and so
processes, like dispute resolution, continued to use the account
number as the identifier (and you need something else to be used for
authentication ... since the use of the account number as the
identifier is so ingrained into so many processes ... including the
minds of the consumers).
however, with regard to the magstripe, there are lots of widely
published reports about magstripe being skimmed at point-of-sale
devices, at ATM machines (and/or the value of the magstripe being
skimmed in transit) ... and counterfeit magstripe/cards being produced
for fraudulent transactions.
here is a news article from yesterday about magstripe from
credit/debit cards being skimmed (including the CVV field) and used to
rewrite the magstripe on (magstripe) gift cards:
Gift Cards Carrying Cloned Data Used To Steal Gas
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1121867212622215212&block=
Online ID Thieves Exploit Lax ATM Security
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Online ID Thieves Exploit Lax ATM Security
Date: Wed, 03 Aug 2005 10:25:27 -0600
To: R.A. Hettinga <rah@xxxxxxxx>
CC: cryptography@xxxxxxxx
two-factor authentication nominal objective is to have different
vulnerabilities, i.e. PINs (something you know) is nominally
countermeasure to lost/stolen cards (something you have).
However, skimming exploits can copy both magstripe and pin for
producing a counterfeit magstripe card that can be used with stolen
PIN (common vulnerability) ... minor reference found with search
engine:
http://wiki.whatthehack.org/index.php/Time_to_Ditch_the_Magstripe
The phishing vulnerability can steal both account number and PIN for
producing counterfeit magstripe card for use with the stolen pin;
again, common vulnerability defeating objective of using two-factor
authentication.
back in the dark ages there were attacks on magstripe credit cards
that used the algorithms for valid account numbers to generate
counterfeit magstripe credit cards. magstripes then acquired
effectively a kind of hash code as countermeasure to counterfeit
mastripes with algorithm generated account numbers. this turns out to
also be a countermeasure for counterfeit magstripe credit cards that
have been created from phished account number (however this isn't a
countermeasure to skimmed magstripe exploit that produces counterfeit
magstripe with all the exact information). description of magstripe
(and descretionary data field) format:
https://en.wikipedia.org/wiki/Magnetic_stripe_card
PINs have also been used as countermeasure to counterfeit magstripe
debit cards ... possibly based on assumption that counterfeit debit
magstripe from phishing exploits were similar threat to lost/stolen
card. However, this isn't a effective countermeasure when both the PIN
and the account number (magstripe) have a common vulnerability
(phishing)
As an aside, a countermeasure for lost/stolen cards is also early
reporting (owner is aware of the missing card). However this is not
applicable to skimmed/phished information since the card owner might
not even be aware that it has happened (until after discovering
fraudulent transactions).
...
spate of recent articles on phishing and ATM/debit
Analysts Say ATM Systems Highly Vulnerable To Fraud
http://www.banktech.com/aml/showArticle.jhtml?articleID=167100238
Something Phishy's Going On
http://www.banktech.com/aml/showArticle.jhtml?articleID=167100396
E-Fraud | Cybercrooks Target ATM And Debit Cards, Steal Billions
http://www.techweb.com/wire/security/167100202
Analysts Say ATM Systems Highly Vulnerable To Fraud
http://www.fincen.gov/statutes_regs/frn/pdf/Prepaid%20Access%20NPRM.pdf
Phishers exploiting lax ATM security - Gartner
http://www.finextra.com/fullstory.asp?id=14058
Banks let phishers get away with $2.75bn
http://www.vnunet.com/vnunet/news/2140690/banks-let-phishers-away-75b
Banks let phishers get away with $2.75bn
http://www.pcw.co.uk/vnunet/news/2140690/banks-let-phishers-away-75b
Phishing attacks highlight banks' weaknesses
http://news.zdnet.co.uk/internet/security/0,39020375,39211852,00.htm
Phishers cash in on ATM cards
http://www.zdnetasia.com/news/security/0,39044215,39246973,00.htm
ATM Systems Highly Vulnerable
http://www.newsfactor.com/story.xhtml?story_id=003000002F1U
[Clips] Escaping Password Purgatory
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: [Clips] Escaping Password Purgatory
Date: Fri, 05 Aug 2005 14:24:59 -0600
To: Jerrold Leichter <jerrold.leichter@xxxxxxxx>
CC: Bill Frantz <frantz@xxxxxxxx>, cryptography@xxxxxxxx
Jerrold Leichter wrote:
Hmm. I came up with the same idea a while back - though with a
different constraint: I think it's reasonable to trade off the
one-wayness of the hash for the ability to work out the password with
pencil and paper when necessary. Various classic pencil-and-paper
encryption systems can be bent to this purpose. Since the volume of
data "encrypted" is very small and it's hard for an attacker to get
his hands on more than tiny samples - a given web site only sees its
own password - you don't need much strength to give a reasonable
degree of protection.
note that rfc2289 is one time password
https://www.garlic.com/~lynn/rfcidx7.htm#2289
... takes passphrase, a site supplied salt, and iterative hashing.
supposedly this was to allow transmission in the clear and resistance
to man-in-the-middle attacks. the idea was also that the person only
had to remember a single passphrase
however, the following discusses a man-in-the-middle exploit ...
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003o.html#46 What 'NSA'?
https://www.garlic.com/~lynn/2003p.html#10 Secure web logins w random passwords
Cross logins
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Cross logins
Date: Fri, 05 Aug 2005 14:37:29 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx
James A. Donald wrote:
Is it possible for two web sites to arrange for cross
logins?
The goal is that if someone is logged into website
https://A.com as user127, and then browses to
https://B.com/A_com_registrants, he will be
automatically logged in on b.com as user127@A.com
project athena was being funded to the tune of $50m split between dec
and ibm. my wife and I got to go by periodically and review their
projects. on one of the visits we were on the leading edge of working
out the details of kerberos cross-domain operation.
in the following years ... it turns out that the protocol wasn't the
big issue ... it was establishing the business trust between two
independent organizations (not the protocol issues) ... random past
kerberos posts
https://www.garlic.com/~lynn/subpubkey.html#kerberos
however, maybe two years ago, i saw a presentation on a saml
cross-domain deployment ... that went into some details on the message
flows. I happened to observe that the basic message flows looked
exactly like the kerberos cross-domain message flows (dating back to
start of kerberos cross-domain). first, the person doing the
presentation was surprised that anybody in the audience had ever heard
of kerberos ... and then they finally allowed that there might just
be a limited number of ways of doing cross-domain operation.
saml reference:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
[Clips] Does Phil Zimmermann need a clue on VoIP?
From: Anne & Lynn Wheeler <lynn@xxxxxxx
Subject: Re: [Clips] Does Phil Zimmermann need a clue on VoIP?
Date: Sat, 06 Aug 2005 09:18:14 -0600
To: mxe20@xxxxxxx
CC: cryptography@xxxxxxxx
Mark Allen Earnest wrote:
*yawn* Yet another person who confuses PK with PKI. Almost NOBODY has
ever done PKI right. The I is the part everyone conveniently forgets
when they claim otherwise.
when we were doing this stuff related to e-commerce ... we also had to
go out and audit some number of these certificate issuing
institutions. we frequently explained to them what a service
operation was. at the time, we coined the term certificate
manufacturing to help differentiate from a PKI. one of the largest
organization commented that they originally thot it somehow involved
computers and technology and other fancy stuff ... and they were
finding out that even simple certificate manufacturing was 95
percent or more bookkeeping, accounting and paper work. there were
frequently questions about how they might outsource even that little
part of service oriented operation.
random past posts on ssl domain name certificates ... some number dating
back to the period of the original payment gateway.
https://www.garlic.com/~lynn/subpubkey.html#sslcert
one of the big issues for real businesses with extensive and well
established relationship management infrastructure ... it readily
became apparent that even trivial certificate manufacturing
operation represented a significant redundant and superfluous activity
... unnecessarily duplicating existing business operations.
[Clips] Does Phil Zimmermann need a clue on VoIP?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: [Clips] Does Phil Zimmermann need a clue on VoIP?
Date: Sat, 06 Aug 2005 15:18:19 -0600
To: cryptography@xxxxxxxx
CC: mxe20@xxxxxxxx
Anne & Lynn Wheeler wrote:
random past posts on ssl domain name certificates ... some number dating
back to the period of the original payment gateway.
https://www.garlic.com/~lynn/subpubkey.html#sslcert
oops, finger slip, that should be
https://www.garlic.com/~lynn/subpubkey.html#sslcert
... oh, and there are some slightly related postings regarding the
period from another thread:
https://www.garlic.com/~lynn/2005n.html#30 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2005n.html#26 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2005n.html#27 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2005n.html#28 Data communications over telegraph circuits
https://www.garlic.com/~lynn/2005n.html#29 Data communications over telegraph circuits
solving the wrong problem
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: solving the wrong problem
Date: Tue, 09 Aug 2005 13:08:42 -0600
To: John Denker <jsd@xxxxxxxx>
CC: Adam Shostack <adam@xxxxxxxx>,
cryptography@xxxxxxxx, perry@xxxxxxxx
John Denker wrote:
That's an interesting topic for discussion, but I don't think
it answers Perry's original question, because there are plenty
of situations where the semblence of protection is actually a
cost-effective form of security. It's an example of statistical
deterrence.
i've frequently used a metaphor about a bank vault door installed in the
middle of an open field.
https://www.garlic.com/~lynn/aadsm15.htm#9 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/2002l.html#12 IEEE article on intelligence and security
https://www.garlic.com/~lynn/2003h.html#26 HELP, Vulnerability in Debit PIN Encryption security, possibly
https://www.garlic.com/~lynn/2003n.html#10 Cracking SSL
the other metaphor is the one about if all you have is a hammer, then
all problems become nails.
and for some of the PKI related ... frequently they start out claiming
the answer is PKI ... before asking what the problem is.
one of the current issues is that some financial operations are using
a value for a userid-like capability and at the same time using the
same value as a password-like capability. userid requires fairly high
security integrity ... aka from PAIN
- privacy
- authentication
- integrity
- non-repudiation
and the userid capability also requires fairly general availability in
order to establish permissions and as the basis for other business
operations.
however, the password capability requires very high privacy and
confidentiality. the result is relatively high diametrically opposing
use critiaria ... high integrity and generally available ... vis-a-vis
high confidentiality.
pure encryption might claim that they could meet the high
confidentialilty requirements ... but that then tends to break all the
"generally available" requirements for its userid function (and/or
esposing it in the clear for all its business use operations creates
enormous number of points for the value to leak out)
the fundamental threat model then turns out not to be there isn't enuf
encryption ... the fundamental threat model is a dual-use vulnerability
... where the same information is being used to select permissions
(aka userid) and needs to be generally available ... while at the same
time serving as a password (for authentication).
How much for a DoD X.509 certificate?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: How much for a DoD X.509 certificate?
Date: Thu, 11 Aug 2005 12:55:48 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx
Peter Gutmann wrote:
$25 and a bit of marijuana, apparently. See:
http://www.wjla.com/news/stories/0305/210558.html
http://www.wjla.com/news/stories/0105/200474.html
although the story doesn't mention this, the "ID" in question was
the DoD Common Access Card, a smart card containing a DoD-issued
certificate. To get a CAC, you normally have to provide two forms
of verification... in this case I guess the two were photo ID of
dead presidents and empirical proof that you know how to buy weed.
The cards were issued by Yusuf Khalil Jackson, a man with a long
criminal history (including, ironically, identity fraud):
one might claim that part of this is the lingering affinity to offline
credentials ... when most really secure operations have gone to online
and realtime operations ... leaving any physical object primarily a
feature of something you have authentication that might be used in
conjunction with other authentication factors.
the issue of many offline credentials are that they are left over from
a bygone era that is rapidly disappearing, but some of the legacy
mindsets still linger on.
the issue was raised in the mid-90s in financial infrastructures ...
that such offline credentials ... even tho redundant and superfluous
(in a modern online world) wouldn't actually be hurting anything
(other than possibly the out-of-pocket expense to support such
operations).
the danger did show up when operations were tempted to use the
redundant and superfluous credential in lieu of doing an actual online
operation.
How much for a DoD X.509 certificate?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: How much for a DoD X.509 certificate?
Date: Fri, 12 Aug 2005 10:43:20 -0600
To: John Saylor <johns@xxxxxxxx>
CC: Peter Gutmann <pgut001@xxxxxxxx>, cryptography@xxxxxxxx
John Saylor wrote:
as i understand it, the problem here was that credentials were issued
by an untrustworthy agent. you can have this scenario both online and
off. how does being online solve the problem of a compromised issuing
authority?
the justification for having offline credentials typically has been
because 1) the technology isn't available for doing an online
infrastructure for accessing the real data or 2) the value of the
operation doesn't justify the cost & expense of having a real online
infrastructure.
the statement was that most modern day infrastructures have gone to
real online operations where the real information is accessed rather
than substitute offline credential .... this transition has been
- the online technology to access the real information is becoming
more ubiquitous,
- the cost of doing online access to the real information has been
dropping,
- many of the security sensitive infrastructures realize that they
now can easily justify any incremental expense of full online
operation (including the additional benefits of being able to analyze
activity across multiple sequences of security related events
... rather than each individual security event occuring in offline
isolation purely based on the contents of the offline credential).
I've frequently explained the analogy that offline credentials are
basically a read-only cache of the real information stored in a
repository some place. they are a direct analogy (modulo possibly the
read-only characteristics) of distributed cpu cache/memory,
distributed databases, ... any kind of distributed operation where
specific activities go on referencing in isolation the local read-only
copy.
so if you physically compare direct access operation to the real
information (including the ability to have a global view of operations
across individual events and be able to re-act and correct in real
time) ... vis-a-vis offline, isolated, distributed operation involving
the copies .... there are a significantly larger number of places that
directly touch the distributed read-only copies which can possibly
result undetected corruption (compared to direct accesses to the real
information).
it isn't that there aren't touch points that can corrupt the real
information ... it is just that there possibly are several orders of
magnitude fewer touch points that can corrupt the real information.
in a PKI, certification authority operations ...
- the "real information" is the authoritative agency responsible for
the actual information.
- typically a certification authority then will create its own
repository operation duplicating the real information
- it creates a certificate containing some subset of the real
information which is relatively freely released into the widld
the issue is that in the real respository #1 and possibly any
certification authority's shadow #2, the possible value of criminal
corruption of the real information is a lot higher ... but there tends
to be significantly larger number of security countermeasures against
there being any sort of corruption.
the individual certificate copies released into the wild tends to have
much fewer countermeasures and a much large number of infrastructure
attack points. in the case of the original ... the information is
either correct or it is not correct. in the offline credential copy
... the offline credential copy can 1) be a copy of incorrect
information (from the original) or 2) possibly be one of many
counterfeit copies containing fraudulent information.
so the online infrastructure is not concerned about there being
counterfeit copies of the information or ficticious counterfeits (of
information that doesn't even exist at the original) ... because
copies don't exist.
online infrastructure, however is concerned about valid authentication
and the counterfeiting of valid authentication information. i contend
that this is a much narrower exposure than the exposure of having
generalized counterfeit information floating around random locations in
the infrastructure. furthermore, the online infrastructure has much
greater capability for tracking and potentially recognizing counterfeit
authentication operation and furthermore, being able to react to it in
real time.
So somewhat after I was making statements about online infrastructure
having much fewer and narrower corruption points, having more
capability for recognizing compromises (being able to analyze patterns
across multiple security related events) and doing real-time re-acting
... there started appearing things like OCSP.
However, i claim that if you can do an a real-time, online operation
... you are incurring the majority of the expense of doing a
real-time, online operation ... and therefor you would have much
higher integrity simply transitioning to a real-time, online operation
... and eliminate the offline information that is floating around out
in the wild.
slightly related recent posting regarding sanity check about whether
you have a fundamental online system or a fundamental offline system
... and if you have a fundamental online system ... then it is trivial
to show that digital certificates are redundant and superfluous in a
fundamental online system, and if you can show digital certificates
are redundant and superfluous in a fundamental online system ... then
you can also show that certification authorities and PKI are also
redundant and superfluous.
https://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline situation
https://www.garlic.com/~lynn/2005n.html#43 X509 digital certificate for offline situation
aka ... fundamentally digital certificates were designed to
specifically address the offline situation. frequently the use of
digital certificates in online situations are contrived and results in
being able to trivially show that they are redundant and superfluous.
The summer of PKI love
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The summer of PKI love
Date: Fri, 12 Aug 2005 15:09:51 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx
James A. Donald wrote:
PKI's deployment to identify ssl servers is near one
hundred percent. PKI's deployment to sign and secure
email, and to identify users, is near zero and seems
unlikely to change. PGP has substantially superior
penetration.
PKI deployment to authenticate SSL servers almost doesn't exist.
we were called in to work with this small client/server startup that
wanted to do payments on their server ... and had this technology
called SSL. we had to do a lot of laying out the business ground work
for the payment stuff ... and because they wanted to use SSL for
pieces of it and certification authorities issuing digital
certificates were involved ... we also had to go audit the major
digital certificate issuing institutions.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
in the course of doing this ... we coined the term certificate
manufacturing to describe what we were finding ... as one way of
differentiating it from the industry accepted definition for PKI.
https://www.garlic.com/~lynn/subpubkey.html#sslcert
another place that it came up ... was that we had a SSL encrypted
session defined between webservers (doing payment transactions) and
the payment gateway. special digital certificates were issued for both
the webservers and the payment gateway as part of initializing the
encrypted tunnel (and we forced the implementation of mutual
authentication ... rather than the simple one-way that was available
at the time). At this point it became readily apparent that the
digital certificates part of all this were redundant and
superfluous. All the webservers had the public key of the payment
gateway pre-installed in the webserver ... and the payment gateway had
a separate mechanism (once the encrypted tunnel was set up) for
authenticating the webserver (based on established payment processing
conventions). while there was movement of digital certificates during
the setup of this encrypted tunnel ... it was purely an artificial
artifact of the existing code implementation and didn't actually serve
any other useful purpose.
this then resulted in re-examing the design-point and requirements for
digital certificates, certification authorities, and PKI ... which was
to address an introduction issue where a relying party was facing
first time communication with a total stranger and had no access to
any other means for obtaining information (aka the letters of credit
model from the sailing ship days). In situations where there was an
established relationship between the two parties ... it was fairly
trivial to demonstrate that the digital certificates were redundant
and superfluous.
so the original justification for server domain name digital
certificates in SSL was
- key exchange ... which can be done via other mechanism
- address perceived integrity issues with the domain name
infrastructure so that the user has some level of confidence that the
server they think they are talking to actually is the server they are
talking to.
basically, the browser checks the typed-in URL against the domain name
in the server's certificate. this originally was specified as
happening at the time the user typed in the URL that initially
contacted the server and the SSL session existed for the complete
period that the user interacted with the server.
however, most servers very quickly discovered that SSL operation cut
their thruput by 80-90 percent and so you found e-commerce servers
moving to straight HTTP w/o SSL for the browsing and shopping
experience and providing a "checkout/pay" button that moved into SSL
for actual payment. As been repeatedly described before, this creates a
large vulnerability in the SSL use for real live environments
... since if a user was initially interacting with a fraudulent site
(because SSL wasn't used for the original typed in URL) ... when the
user got to clicking on the "checkout/pay" button ... a fraudulent
site was more than likely to specify a URL for which they had a valid
server domain name SSL certificate.
the other issue ... is most of the certification authorities in the
world aren't actually the authoritative agency for the information
they are certifying. the actual trust root for many digital
certificates ... are the authoritative agencies that the certification
authority has to check with regarding the validaty of the digital
certificate application.
Now, it happens that the authoritative agency for domain name
ownership, is the domain name infrastructure ... the very same domain
name infrastructure that has the integrity concerns giving rise to the
requirement for ssl domain name certificates.
so there has been some proposals for improving the integrity of the
domain name infrastructure ... in part from the certification
authority industry so that the certification authority process can
better trust the information that they are certifying.
Part of this proposal is to have domain name owners register their
public key with the domain name infrastructure. Future communication
between the domain name owner and the domain name infrastructure would
be digitally signed and the domain name infrastructure can verify the
digital signature using the on-file public key (note no digital
certificates required)
https://www.garlic.com/~lynn/subpubkey.html#certless
The other benefit is to the ssl domain name certificatin authority
industry ... they can change an expensive, error-prone, and
time-consuming identification process (matching the identity of the
certificate applicant with the identity of the domain name owner on
file with the domain name infrastructure) into a simpler, less
expensive, and more reliable authentication process (by requiring that
certificate applicants digitally sign their applications and the
certification authority then verify the digital signature by doing a
realtime, online retrieval of the onfile public key).
Of course, this represents a signficant catch-22 for the ssl domain
name certification authority industry;
- if you improve the integrity of the domain name infrastructure it
reduces the requirement for having ssl domain name certificates
- if the certification authority can base their trust infrastructure
on realtime retrieval of online public keys for verifying digital
signatures ... it is possible that the rest of the world could also
start doing realtime retrieval of online public keys for
verifying digital signatures (eliminting the requirement that a
webserver needs to transmit a digital certificate to a relying party
in order for them to verify a digital signature).
One could even imagine an enhanced, optimized hostname->ipaddress
transaction with the domain name infrastructure ... where the
ipaddress, any public key, and other optional information all
piggybacked in a single response. Then the client could do a real,
transaction oriented operation ... they piggyback the encrypted random
transaction symmetric key and the encrypted transaction data in a
single transmission (to the webserver) ... with the webserver being
able to do a single transmission reply. None of the certificate
related protocol chatter needs to even occur ... you have a single
round-trip with the domain name infrastructure (if the information
isn't already cached locally) and it is possible to also have a single
tround-trip transmission with the webserver.
slightly related post in another thread
https://www.garlic.com/~lynn/2005n.html#43 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
How many wrongs do you need to make a right?
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: How many wrongs do you need to make a right?
Date: Wed, 17 Aug 2005 09:52:14 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx
Peter Gutmann wrote:
- In the 1950s we had cheque blacklists, which were used in an attempt
to manage bad cheques.
- They didn't work well, and were abandoned as soon as better
mechanisms became available.
- In the 1960s and 70s we had credit card blacklists, which were used
in an attempt to manage bad credit cards.
- They didn't work well, and were abandoned as soon as better
mechanisms became available.
basically you can have offline & non-electronic, offline &
electronic, online & non-electronic (maybe null), and online &
electronic.
the credit card model of the 60s was a manual credential in an offline
environment (aka offline & non-electronic). they started by mailing
monthly booklets (push model) to all registered merchants, as system
grew, the size of the booklets grew, the number of registered
merchants grew, and the aggregate risk grew ... so they started
reducing the risk window by pushing out booklets more frequently. this
was growing enormously cumbersumb and obviously couldn't continue
scalling.
in the 70s, they started deploying an online system and added a
magstripe to the plastic ... the plastic could continue to operate in
the old-fashion offline credential mode ... but the magstripe would
act as something you have authentication for the online paradigm
(aka online & electronic). the online infrastructure could scale much
easier as well as significantly reducing the risk and adding function
- any cancelation was effective immediate for all relying-parties
- was able to add credit limit function which involved real-time
aggregated information ... which is possible in an online environment
put enormously difficult with offline, stale, static certificates.
- real-time patterns of use that could indicate other kinds of fraud
or possibly lost/stolen
so long ago and far away ... the payment gateway and e-commerce
infrastructure
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
added ssl domain name certificates as a countermeasure for various
MITM-attacks (but almost totally certificate manufacturing w/o
bothering with revokation)
https://www.garlic.com/~lynn/subpubkey.html#sslcert
there were some efforts in the following time-frame that was
advocating consumer PKI digital certificate deployment as a mechanism
for moving electronic payments into the modern world (aka offline &
electronic).
I repeatedly observed that the stale, static PKI digital certificate
paradigm actually would regress the electronic payments environment to
the ancient 60s (a fundamental issue was giving up the scallable
online functions).
If you went purely with the offline stale, static PKI digital
certificate paradigm you lost 1) scallable immediate concelation for
all relying-parties and 2) credit limit real-time aggregated
information, 3) real-time patterns of use.
If you kept the scallable online transaction infrastructure ... it
would be possible to upgrade the magstripe something you have
authentication by registering the public key for the account and doing
digital signatures verification (using the onfile public key in the
account record). This kept the online & electronic paradigm with
upgrading the magstripe technology to something that was more
counterfeit resistant
https://www.garlic.com/~lynn/subpubkey.html#certless
but not requiring a certification authority to produce a stale,
static, redundant and superfluous certification for use by other
parties..
as I recently posted in another thread
https://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005o.html#7 X509 digital certificate for offline solution
that a fundamental characteristic of a PKI certification authority
infrastructure is that the certification authority is certifying the
validity of some information for use by other parties (trust
propagation)... where the other parties lack any means of otherwise
determining the validity of the information aka don't have their own
copy and/or don't have online access to the authoritative
agency responsible for the information and/or don't have online
access to a related certification authority.
There was some effort in the mid-90s for relying-party-only
certifcates ... where the relying-party registered the public key,
stored it in an account record, generated a digital certificate,
stored that in the account record ... and finally provided the key
owner with a copy of the digital certificate
https://www.garlic.com/~lynn/subpubkey.html#rpo
however, it is trivially shown that such relying-party-only
certificates are redundant and superfluous since the relying-party has
both the original ceritifcate as well as real-time copy of all the
related information.
the other way of looking at it is that this violates the fundamental
requirements justifying the use of PKI digital certificates.
some old posts mentioning PKI digital certificates would be throwing
the payment card industry back into the 60s.
https://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
https://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
https://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction?
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#23 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#1 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#31 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#32 More Phishing scams, still no SSL being used
How many wrongs do you need to make a right?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: How many wrongs do you need to make a right?
Date: Wed, 17 Aug 2005 11:42:21 -0600
To: cryptography@xxxxxxxx
CC: Peter Gutmann <pgut001@xxxxxxxx>
as an aside, PKIs have attempted to move into the no-value
market segment.
as internet and online have become more and more ubiquitous, the
original offline market segment for PKI has drastically dwindled
... i.e. a certification authority certifying information and freely
distributing that certified information for the benefit of other
parties that don't have access to the information themselves
... i.e. turning them into relying parties, parties that rely on the
digital certificates (certification of information by certification
authorities).
In the past, these relying parties were operations that didn't have
their own information and no capability for contacting any
authoritative agency directly responsible for the information
and/or directly contacting certification authorities. This is my
analogy to the "letters of credit" from the sailing ship days.
As internet and online have become more and more ubiquitous
(as well as the general decline in dataprocessing costs), situations
where parties don't have their own copy of the information and/or
aren't directly able to contact somebody with the information ... is
rapidly disappearing.
What is remaining are operations that still can't justify the cost of
their own copy of the information (rapidly disappearing with the
drastic decline in the general cost of dataprocessing) and/or can't
justify the cost of directly contacting somebody with the information
... becoming more and more difficult to find such a no-value
market niche as the cost of online operation is rapdily declining and
becoming ubiquitously available.
misc. past no-value postings
https://www.garlic.com/~lynn/aepay10.htm#74 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
https://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
https://www.garlic.com/~lynn/aadsm19.htm#8 GeoTrust says existing PKI practices are worthless
https://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
https://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
https://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
https://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2004b.html#25 Who is the most likely to use PK?
https://www.garlic.com/~lynn/2004b.html#52 The SOB that helped IT jobs move to India is dead!
https://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#13 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#24 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005k.html#29 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#11 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#21 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
https://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
https://www.garlic.com/~lynn/2005l.html#33 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
Another entry in the internet security hall of shame
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Another entry in the internet security hall of shame....
Date: Thu, 25 Aug 2005 15:16:01 -0600
To: Trei, Peter <ptrei@xxxxxxxx>
CC: Peter Saint-Andre <stpeter@xxxxxxxx>, cryptography@xxxxxxxx
Trei, Peter wrote:
Ironically, Peter's message above kicked off warning dialogs from MS
Outlook, since it was signed using a keypair signed with Peter's own
self-signed root, which was not in MSO's list of trusted roots.
Self-signed certs are only useful for showing that a given set of
messages are from the same source - they don't provide any
trustworthy information as to the binding of that source to
anything.
basically somebody may eventually load the public key from the
self-signed digital certificate into their local trusted public key
repository ... possibly based on some out-of-band trust process.
that isn't any different than almost every certification authority
public key that is in use today. almost every certification authority
public key is represented by some sort of self-signed certificate and
is loaded into the trusted public key repositories of relying parties.
in that sense, it is frequently possible to show (from an information
theory standpoint) that such digital certificates are redundant and
superfluous ... they however may not be not useful (double negative?)
or may not be unuseful.
given that there exists deployed software that thinks that it requires
some sort of digital certificate in order to perform some processing
... then even if the digital certificates are redundant and
superfluous (from an information theory standpoint) they can still
serve some useful when attempting to have compatibility with existing
deployed software.
recent posting in sci.crypt on slightly related subject
https://www.garlic.com/~lynn/2005o.html#31
https://www.garlic.com/~lynn/2005o.html#33
Federal Information Assurance Conference 2005, Oct 25-26
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Federal Information Assurance Conference 2005, Oct 25-26
Date: Fri, 26 Aug 2005 10:24:12 -0600
To: cryptography@xxxxxxxx
Federal Information Assurance Conference 2005, Oct 25-26, Univ. of
Maryland
http://www.fbcinc.com/fiac/
agenda
http://www.fbcinc.com/fiac/agenda_full.asp
and one of the sessions from above:
A5 - NIST and IBM Discuss Draft Publication SP 800-53A
Another entry in the internet security hall of shame
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Another entry in the internet security hall of shame....
Date: Fri, 26 Aug 2005 13:11:16 -0600
To: cryptography@xxxxxxxx
periodically, some of the PKI related comments remind me of some
stories about power production from the 70s.
some of the '70s energy stories focused on the different quality of
support for power generation technologies based on whether they were
institutional centric (and would be able to charge for delivery)
vis-a-vis individual oriented generation technologies (even when they
involved identical/same/similar solar, wind, etc energy sources). one
of the issues from the energy stories of the 70s was that
institutional centric solutions frequently collected a lot more
backing because proponents were willing to put the effort into the
activity in anticipation of revenue flows.
however, there are significant differences between the PKI
institutional centric operations and institutional power generation
operations. The power being generated (and delivered) tends to be
relatively standard and individuals may view it a reasonable trade-off
to have it supported by large institution rather than being
responsible for their own power generation installations.
There tends to be a much larger variation in the types of things which
PKI relying-parties are interested in having certified by some PKI
certification authority (somewhat different from bland uniform power
production operation).
Furthermore, PKI relying-parties frequently may still operate a
significant relationship management infrastructure of their own ...
where the information being certified by a trusted 3rd-party
certification authority represents a tiny fraction of the information
that a production relying party will be keeping. In these situations,
once a relying-party has to operate their own relationahip management
infrastructure of any significance, then the benefit of any
certification added value by a trusted 3rd-party certification
authority becomes marginal at best.
Once a relying-party is operating any significant relationship
management infrastructure of their own, any certification done by some
3rd party certification authority frequently becomes redundant and
superfluous. It then follows, if the certification by some 3rd party
certification authority becomes redundant and superfluous, the
associated digital certificate (representing that certification
operation) then also becomes redundant and superfluous.
A trivial example in p2p ... is an individual doesn't necessarily know
that the presentation of a "John Smith" x.509 identity certificate in
any way corresponds to a specific "John Smith" that the relying-party
individual is familiar with. They are frequently going to still rely
on some locally maintained repository as well as additional
out-of-band and/or other communication processes. Once they have done
that ... then the incrmeental effort to also include the other
individual's public key becomes trivial (at least from a high-level
business process and information theory standpoint). This, in turn,
renders any added value from a trusted 3rd party certificate authority
(and their digital certificaes) marginal at best.
Another entry in the internet security hall of shame
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Another entry in the internet security hall of shame....
Date: Mon, 29 Aug 2005 10:50:49 -0600
To: Dave Howe <DaveHowe@xxxxxxxx>
CC: cryptography@xxxxxxxx
Dave Howe wrote:
Indeed so - however, if Google makes it "just work" then there
will be a large swathe of people out there wondering "what does this
*DIGITAL SIGNATURE* button do in gmail?" plus a smaller subset who
have google talk and can perform secure e2e voip using x509 certs
that they don't even know they have.
Its not ideal, but its not a bad thing either - a little more
security, using a known method, without any individual user having
to know or care how it works (and lets face facts here, no solution
that requires an end user to get his finger out and do something
without being forced to, no matter how trivial the task is, ever had
a decent update)
the major ISPs are already starting to provide a lot of security
software to their customers.
a very straight forward one would be if they provided public key
software ... to (generate if necessary) and register a public key in
lieu of password ... and also support the PPP & radius option of
having digital signature authentication in lieu of password checking
https://www.garlic.com/~lynn/subpubkey.html#radius
at that point your public key is now registered with your ISP ... and
possibly could be used for other things as well ... and scaffolding
for a certificate-less trust infrastructure.
in much the same way i've commented about some of the implications of
the SSL certificae industry backing for having onfile public keys in
the domain name infrastructure (and anybody being able to do real time
retrieval of public key) ... something similar could happen with
onfile public keys for general public with their ISP (and possibly
allowing real time retrieval of public keys).
so it would be convenient if such public keys were then integrated
with various client email programs as part of the address book
(automatic process for adding email addresses to address book, then
possibly also automatically add public key as part of the same address
book entry). you could then, at least have a button that would
cross-check that the public key that came with the email was the same
public key onfile with the sender's ISP. it would still be up to the
recipient to provide a mapping/binding between an email address and an
entity in the real world (if they so desired).
the automatic add to the address book ... can work the same way
automatic add to address book works today.
part of the issue might be considered separating the trust
infrastructure from the standard addressing infrastructure.
one of the downsides (comparable to some of the downsides in the
domain name infrastructure onfile public keys) for the certification
authority industry ... is that public keys no longer require
independent certification ... they just become part of the general
addressing landscape.
lots of past postings on SSL landscape
https://www.garlic.com/~lynn/subpubkey.html#sslcert
Another entry in the internet security hall of shame
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Another entry in the internet security hall of shame....
Date: Thu, 01 Sep 2005 10:47:56 -0600
To: Stephan Neuhaus <neuhaus@xxxxxxxx>
CC: James A. Donald <jamesd@xxxxxxxx>, cryptography@xxxxxxxx
Stephan Neuhaus wrote:
That's because PSKs (as I have understood them) have storage and
management issues that CA certificates don't have, four of which are
that there will be a lot more PSKs than CA certificates, that you
can't preinstall them in browsers, that the issue of how to exchange
PSKs securely in the first place is left as an exercise for the reader
(good luck!), and that there is a revocation problem.
To resolve any of those issues, code will need to be written, both on
the client side and on the server side (except for the secure exchange
of PSKs, which is IMHO unresolvable without changes to the business
workflow). The client side code is manageable, because the code will
be used by many people so that it may be worthwhile to spend the
effort. But the server side? There are many more server applications
than there are different Web browsers, and each one would have to be
changed. At the very least, they'd need an administrative interface
to enter and delete PSKs. That means that supporting PSKs is going to
cost the businesses money (both to change their code and to change
their workflow), money that they'd rather not spend on something that
they probably perceive as the customer's (i.e., not their) problem,
namely phishing.
Some German banks put warnings on their web pages that they'll never
ask you for private information such as passwords. SaarLB
(http://www.saarlb.de) even urges you to check the certificate
fingerprint and provides well-written instructions on how to do
that. In return, they'll assume no responsibility if someone phishes
your PIN and TANs. They might, out of goodwill, reimburse you. Then
again, they might not. I believe that SaarLB could win in court. So
where is the incentive for SaarLB to spend the money for PSK support?
an alternative view of the server side is to recognize that the two most
widest used authentication infrastructures are radius and kerberos
https://www.garlic.com/~lynn/subpubkey.html#radius
https://www.garlic.com/~lynn/subpubkey.html#kerberos
furthermore both radius and kerberos not only have facilities for
abstracting authentication function ... but also abstracting
authorization functions.
one of the short-comings of PKIs, CAs, and digital certificates was the
issue of incorporating authorization information along with the
authentication information into a single paradigm ... for one thing
digital certificates tended to be publicly available .. and
authorization information frequently tends to be sensitive.
frequently then the issue is that attempting to replace existing
authentication infrastructures with PKIs, CAs, and digital
certificates still leaves the rest of the infrastructure for
authorization in place. It is then frequently trivial to demonstrate
that the stale, static digital certificates are redundant and
superfluous ... and it is more efficient and less expensive to have an
integrated authentication and authorization environment by simply
registering public keys in lieu of passwords in an existing integrated
authentication/authorizatin environment.
https://www.garlic.com/~lynn/subpubkey.html#certless
for example ... the original pk-init draft for kerberos specified
registering public keys in lieu of passwords ... giving a integrated
authentication/authorization environment using digital signature
verification in place of passwords for authentication. later PKI, CAs,
and digital certificate operation was added to the pk-init draft.
Another aspect was that in the early 90s ... certification authorities
were starting to wonder just what set of information would really be
useful for unknown and undefined relying parties ... as a result there
was some direction to start grossly overloading x.509 identity
certificates with enormous amounts of personal information.
It was in the mid-90s that some institutions were starting to realize
that x.509 identity certificates, grossly overloading with huge
amounts of personal information represented significant privacy and
liability issues. As a result you started to see the appearance of
relying-party-only certificates (in fact, it may have been a german
bank that started producing the first relying-party-only certificates)
https://www.garlic.com/~lynn/subpubkey.html#rpo
A relying-party-only certificate basically contains some sort of
database lookup value (like userid, account number, etc) where the
real information is kept and a public key. However it is trivial to
demonstrate that a relying-party-only certificate is redundant and
superfluous when the real information has to be directly accessed
... by demonstrating that the body of the signed message/transaction
can also include the same database index value ... and the real
information will be where the registered public key is recorded. That
makes the public key in the digital certificate redundant and
superfluous. Simple scenarios like transactions have to include the
identifier ... and in certificate-based scenarios ... the identifier
in the transaction needs to match the identifier in the certificate
(or otherwise you could have somebody with a valid account doing
transactions against any account at the same bank). With the
identifier in the body of the message/transaction and the registered
public key in the account record, the relying-party-only digital
certificate becomes redundant and superfluous.
Another entry in the internet security hall of shame
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Another entry in the internet security hall of shame....
Date: Thu, 01 Sep 2005 11:04:36 -0600
To: Stephan Neuhaus <neuhaus@xxxxxxxx>
CC: James A. Donald <jamesd@xxxxxxxx>, cryptography@xxxxxxx
in fact, the first time i heard the term relying-party-only
certificates was in a presentation by somebody from a german bank at a
nissc conference ... describing all the horrible privacy and liability
problems represented by x.509 identity certificates.
https://www.garlic.com/~lynn/subpubkey.html#rpo
Another entry in the internet security hall of shame
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Another entry in the internet security hall of shame....
Date: Thu, 01 Sep 2005 14:28:21 -0600
To: Alaric Dailey <alaricd@xxxxxxxx>
CC: cryptography@xxxxxxxx
Alaric Dailey wrote:
If I may inject my humble opinion(that isn't necessarily a response to
this peticular email), I may not be as informed as some but....
While I admit that PKI is flawed, I don't see anyway that PSK could used
effectively.
How are PSKs going to be shared in a secure way?
are we talking about generating a new key for every connection?
if so how do you validate the key?
if not, how do you validate that the key hasn't been compromised by
someone who put up a phishing site?
on the business/server side ... where x.509 identity certificates
represent horrible privacy and liability issues ... and they've
migrated to relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
by definition, the institution needs to have already registered the
clients public key ... in order to even issue a relying-party-only
certificate ... they client/customers "public key" has been preshared
(otherwise it would have been impossible for the institution to have
issued the certifivate).
at this point it is trivial to demonstrate that the issuing of the
relying-party-only certificate is redundant and superfluous ... since
by definition the institution has the PSK.
so if you look at existing business process where "pre-shared"
passwords are part of an authentication administration infrastructure
that is integrated with the permissions and authorization
administrative infrastructure ... say like either radius or kerberos
https://www.garlic.com/~lynn/subpubkey.html#radius
https://www.garlic.com/~lynn/subpubkey.html#kerberos
it is possible to register public keys in place of password, retaining
the existing business process and integrated administration of
authentication and authorization.
https://www.garlic.com/~lynn/subpubkey.html#certless
one of the issues when we started dealing with this small
client/server startup that wanted to do payments on their server
platform
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
had this new thing called SSL which were dependent on PKI, certification
authorities, and digital certificates. As part of that effort, we had to
do various kinds of business process and end-to-end audits of these
things called certification authorities. There was a lot of discussion
in these audits about certification authorities having very little to
do with security and technology ... and primarily involved in a
traditional service operation with loads of administrative work.
One of the characteristics of businesses that have existing
relationship management administrative relationship management
operations ... like financial institutions with accounts or business
with accounts payable and accounts billable or ISPs ... is that they
have tried to provide some amount of administrative scale-up and
integrity to the operation.
Frequently it is possible to show a trivial toy PKI demo as an add-on
w/o impacting the core authentication and authorization business
processes. The big expenses quickly dawns on them when it starts to
appear that PKI operation might have some impact on real business
operations. At that point of time, it becomes quickly apparent that
any full-scale PKI authentication infrastructure deployment will have
an enormous cost duplication (especially after there has been possibly
scores of years developing scaleable and integrated authentication and
authorization infrastructures).
At that point, the ongoing duplicate PKI operational costs totally
dominate ... any trivial software technology deployment issue. Part of
the issue is that the promise of having x.509 identity certificates
groslly overloaded with enormous amounts of privacy information along
with authorization and permissions ... has been shown to be
false. That the organization isn't able to use the deployment of a
X.509 PKI operation (with the digital certificates containing enormous
amounts or privacy and senstive information) to eliminate their
existing integrated relationship management and administrative
infrastructure costs ... it possible turns out to be possibly doubling
the actual business costs (in any sort of full-scale production
deployment used for actual business purposes.). It may actually be
worse than doubling ... the basic PKI administrative infrastructure
may be replicated ... doubling the costs ... however the actual costs
may be tripled if the existing production business operation and the
replicated PKI administrative operation then has to also be kept in sync.
From a business/server standpoint ... upgrading an existing
integrated authentication/authorization/permission infrastructure to
use digital signature authentication with public key registration
... conforms to existing business practices and doesn't introduce
duplicate and unnecessary administrative operation.
Another entry in the internet security hall of shame
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Another entry in the internet security hall of shame....
Date: Wed, 07 Sep 2005 10:49:08 -0600
To: Alaric Dailey <alaricd@xxxxxxxx>
CC: cryptography@xxxxxxxx, anti-fraud@xxxxxxxx
Alaric Dailey wrote:
ATMs would be infeasible if they were not a 2-factor authentication
system, and every day we see more cracks in the way that system is
implemented. Starting with the way the PSKs are shared.
http://news.bbc.co.uk/1/hi/technology/4183330.stm
ATMs use something you have authentication ... a card with a magstripe
that is sent out. There is a 2nd factor, PIN, that is also distributed
... as a countermeasure to lost/stolen cards.
note that both credit cards and many debit cards can be used in
non-PIN, signature mode (i.e. if the card is lost/stolen, crook may
still be able to use it w/o PIN).
multi-factor authentication presumes that the different factors are
subject to different kinds of vulnerabilities and exploits.
PINs are a form of shared-secrets ... security requirements typically
mean that there is a unique shared-secret for every environment. the
result is vast proliferation of PINs and passwords leading to people
writing down their pins & passwords (there was some study that
claimed 30percent of atm cards have pins written on them). As a
result, multi-factor infrastructure is undermined because of
shared-secret based environments has led to scores of shared-secrets
that people are required to keep track of.
https://www.garlic.com/~lynn/subintegrity.html#secrets
the short-coming of shared-secret environment, is that a shared-secret
can be used for both origination as well as verification (the same
value used for authentication can also be used for impersonation),
which has led to requirement that there are large number of unique
shared-secrets, which has led to the huge proliferation in the number
of shared-secrets ... which has also led to underminning principle of
multi-factor authentication ... having unique failure modes .... sorry
for that ... I spent some large amount of time producing high
availability systems ... where security exploit/vulnerabilities were
just another kind of system failure.
https://www.garlic.com/~lynn/subtopic.html#hacmp
it isn't so much that the key distribution/sharing mechanism is flawed
... it is that there are flaws in shared-secret based infrastructures
(including swamping nominal human factors with an impossible number of
different things to memorize).
The other short-coming in current ATM environment is skimming that can
go on at the POS or ATM terminal ... where the attackers can record
the card and pin information. This results in both 1) common
vulnerability for two factor authentication ... defeating purpose of
having multi-factor authentication and 2) that existing technology is
quite vulnerable to replay attacks (aka creating copy of magstripe in
counterfeit card and being able to reproduce the pin).
So fundamental public key operation can address a number of these
short-comings w/o resorting to PKI infrastructure and/or changing the
key and card distribution operation.
- upgrade magstripe to hardware token that does digital signature
authentication. the digital signature is unique each time and is
therefor resistant to existing replay attacks, vulnerability, and
threats. attacks
- since public key is not a shared-secret based infrastructure ... it
is practical to record the same public key in multiple different
environments, in theory transitioning to a person-centric environment
(from the existing institutional-centric environment). this also is
more resistant to data breaches ... since any exposure of the recorded
public key can't be used for impersonation.
- there is still the issue of using a PIN as countermeasure to
lost/stolen token ... which is a significantly lower threat compared
to crooks being able to harvest tens of thousands or millions of
pieces of information for purposes of account fraud (skimming
recording devices at ATM & POS terminals or data breaches).
- with hardware token, the PIN can be used directly with the token
for token operation ... as opposed to be transmitted and recorded in
the infrastructure. That eliminates the PIN as a shared-secret. In
theory a person-centric environment can use the same PIN/token with
multitude of different infrastructures and/or use the same PIN with
multitude of different tokens. This last becomes a trade-off between
remembering lots of PINs (and threat of having them written down)
vis-a-vis compromise of single PIN can expose several tokens. However,
in person-centric environment, it is possible to leave such a threat
trade-off decision to the individual.
The issue of PKI, certificatin authorities, and digital certificates
were that the original digital certificate design point was for first
time communication between strangers where the relying party also had
not timely, direct (possibly online) access to a trusted party. The
digital certificates filled this trust void in a manner siumilar to
letters of credit from the sailing ship days.
In an environment where relying parties have long-standing and
extensive relationship management operations keeping track of large
number of bits of information ... it is trivial to show that digital
certificates are redundant and superfluous.
Furthermore, even in the first time communication between strangers
... where the relying party has no prior interaction with the subject
... digital certificates may still be redundant and superfluous
standin for the real information, if the relying party is able to
directly contact some authoritative agency responsible for the
information (aka real-time communication obtaining the real current
information in lieu of a redundant and superfluous, stale, staic
digital certificate).
misc. past person-centric related postings:
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
https://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
https://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005m.html#37 public key authentication
https://www.garlic.com/~lynn/2005p.html#6 Innovative password security
Another entry in the internet security hall of shame
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Another entry in the internet security hall of shame....
Date: Wed, 07 Sep 2005 14:44:43 -0600
To: Alaric Dailey <alaricd@xxxxxxxx>
CC: cryptography@xxxxxxxx, anti-fraud@xxxxxxxx
Alaric Dailey wrote:
Thus ATMs and the weak 2-factor authentication system they use are
untrustworthy, I knew that already, but as I said, its better than not
having the multifactor authentication. The fact that many cards may be
used as credit card and you thus bypass the second factor, is a HUMAN
failing, the entity accepting the cards are supposed to check the
signature, against a photo id, ESPECIALLY if the card says "See ID".
But this overabundance of text doesn't solve my problems with the
assertion that PSKs are somehow more secure than Public/Private key
encryption with a trusted third party as verifier, and specifically the
X.509 Certificate Authority System that is the backbone for SSL.
No one is touching on the key issues
sharing of keys securely and how to validate that they haven't been
comprimised.
how a user is supposed to keep track of the secure keys (kind of a side
point)
how the validation of identity of these systems would work
Note that the "see ID" has the bank transfer the responsibility for
authentication to some retail clerk. There has been huge amount of
information that this is not a good idea ... for all sorts of reasons.
It is also one of the violations of the EU data privacy directive.
Basically the name on piece of plastic ... is so a retail clerk can
check the name on the plastic card, see if a provided government
picture ID has the same name, and then check to see if the picture
matches the real person. This effectively amounts to an identification
process ... rather than an authentication process. Related to the EU
data privacy directive is that point-of-sale plastic transactions
should be as anonymous as cash .... effectively the name is removed
from the plastic card ... also eliminating the possibiity that an
identification operation can be subsituted for an authentication
operation (this also points up another of the reasons why the x.509
identity certificates were a bad idea).
there are two parts of the PKI operation
- trust certification
- digital certificates
so first, quicky overview of trust certification ...
trust certification can be done by somebody ... and they then retain
the information in there relationship management repository. the trust
certification can be done by the relying party (like a financial
institution) and they maintain the information in a long-established
mature relationship management repository ... which not only contains
information that occured at single point in time ... but may represent
aggregation of ongoing real-time information that accumulates over
time.
the trust certification by some authoritative agency might also be
made available to other parties. credit bureaus are one example that
tends to make the information available in real time. online debit and
credit card transactions are another form ... where the financial
institution is simultaneously making real-time assertion about the
validatity as well effectively standing behind the
transactions. having the transactions aggregate in real time is both
more valuable for the authority agency (financial institution
... since it can do things like look for fraud use patterns) and the
relying party (they have real-time corroboration).
and second, digital certificates
... digital certificates from a business model standpoint are
essentially read-only, stale, static cached copy of some information
that is resident in some repository. digital certificates have some
additional technology compared to cpu caches and database caches
... in that they have armoring technology to protect the integrity of
the data when it is freely floating around in pontentially hostile
environment. note that the armoring of the information integrity
contained in the digital certificate ... has no effect on the original
validity of the information contained in the digital certificate
... it just provides some level of assurance that it hasn't changed
since the information was placed in the digital certificate.
in effect, digital certificates are stale, static cached entry
stand-ins for relying parties that don't have access to the real
information ... either the information doesn't other wise exist, or
the relying party isn't keeping the information themselves, and/or the
relying party doesn't have online, real-time access to the real,
current information.
in the early 90s, the idea was that PKI certificate authorities would
operate as independent business ... acting as a trust intermediary
between the authoritative agencies that were responsible for the real
information and relying parties that had no other recourse to
information (about strangers that they were dealing with) AND that the
relying parties had no online access to the better quality real-time
information.
furthermore, in attempts to make x.509 identity certificates more
valuable ... w/o actually knowing the set of relying parties that
might be depending on such digital certificates over an extended
period of time in the future ... there was some direction to include
more and more information, horribly overloading x.509 identity
certificates with personal information.
by the mid-90s, many institutions were beginning to realize that x.509
identity certificates horribly overloaded with enormous amounts of
personal information represented significant privacy and liability
issues. As a result, you saw institutions falling back to
relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
where the digital certificate just contained some sort of database
index/pointer into a repository containing the real information.
However, it is trivial to show that such digital certificates are
redundant and superfluous ... since by definition the relying party
has access to the information w/o needing to resort to the index from
the digital certificate.
for some topic drift ... when we working on ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
i got to develop the distributed lock implementation as well as a
model for maintaining database consistency across a wide range of
faults involving distributed caching and distributed logging (where
recovery might first require the merge/integration of several
distributed logs).
slightly more drift
https://www.garlic.com/~lynn/95.html#13
The facet here is that the mechanism used for armoring and maintaining
the integrity of the (stale, static) data in a digital certificate
.... can be considered totally separate from the issue of what
information does the content of a digital certificate actually
represent.
One of the illustrations is a six foot thick bank vault door installed
in the middle of open field. The characteristic of the bank vault door
can be considered independent of the contents of the vault and/or any
other vault characteristics (worse case, it might be an open field).
From an information theory standpoint ... looking at the value of the
information in a digital certificate ... can always be shown to be no
better than original and real-time version of the original.
One of the current target market segments for PKI, CAs, and digital
certificates (since the original target offline market segment is
rapidly disappearing) ... is where the cost of directly accessing the
higher value original information is more than the incremental value
of having access to that information. The issue here is as the cost of
directly accessing original information is rapidly declining, the
no-value target marget segment for PKI stale, static redundant
superfluous digital certificates is repidly shrinking.
As a side observation ... before it started dawning on institutions
that x.509 identity certificates horribly overloaded with personal
information represented significant privacy and liability issues ...
there was some push that such x.509 identity certificates represent
modern driver's license .... thru some magic process ... the person's
digital certificate contained in a smartcard driver's license would
have real-time digital certificates (i.e. the information in a stale,
static digital certificate would have some magical incarnation that
would always display the real time information about the individual)
... and therefor officials in an offline environment would always have
access to the real-time information.
However, even by the mid-90s, most traffic infrastructures were
starting to move online. The person would make some assertion about
who they were ... and the officer would do an online lookup for the
real information and cross-check a picture with the individual. For
official purposes there was a rapid dwindling justification for having
stale, static, redundant and superfluous representations of
information ... officers would just access the information in real
time (either with portable data input/output unit or over radio having
somebody else do the actual real time access).
misc past posts on possibly confusing identification with authentication
https://www.garlic.com/~lynn/aepay11.htm#13 Microsoft Fixes Passport to Meet EU Privacy Rules
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#58 PKI's not working
https://www.garlic.com/~lynn/aepay11.htm#60 PKI's not working
https://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#71 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
https://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#2 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#4 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
https://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
https://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
https://www.garlic.com/~lynn/aadsm7.htm#rhose4 Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose11 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose14 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose15 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#rhose16 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki9 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm8.htm#3dvulner3 3D Secure Vulnerabilities?
https://www.garlic.com/~lynn/aadsm9.htm#3dvulner5 3D Secure Vulnerabilities?
https://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
https://www.garlic.com/~lynn/aadsm10.htm#anonpay Crypto Winter (Re: Looking back ten years: Another Cypherpunks failure)
https://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#17 Alternative to Microsoft Passport: Sunshine vs Hai
https://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
https://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
https://www.garlic.com/~lynn/aadsm11.htm#43 PKI: Only Mostly Dead
https://www.garlic.com/~lynn/aadsm12.htm#4 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#32 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
https://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction?
https://www.garlic.com/~lynn/aadsm12.htm#50 Frist Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#53 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm13.htm#12 Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
https://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
https://www.garlic.com/~lynn/aadsm14.htm#13 A Trial Balloon to Ban Email?
https://www.garlic.com/~lynn/aadsm14.htm#26 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#29 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#33 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#40 The real problem that https has conspicuously failed to fix
https://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
https://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
https://www.garlic.com/~lynn/aadsm14.htm#48 basic question: semantics of "map", "tie", etc in PKI
https://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#7 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm15.htm#11 Resolving an identifier into a meaning
https://www.garlic.com/~lynn/aadsm15.htm#16 End of the line for Ireland's dotcom star
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
https://www.garlic.com/~lynn/aadsm15.htm#26 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm15.htm#38 FAQ: e-Signatures and Payments
https://www.garlic.com/~lynn/aadsm16.htm#16 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
https://www.garlic.com/~lynn/aadsm17.htm#1 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm17.htm#2 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#4 Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
https://www.garlic.com/~lynn/aadsm17.htm#16 PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#20 PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#21 Identity (was PKI International Consortium)
https://www.garlic.com/~lynn/aadsm17.htm#23 PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#26 privacy, authentication, identification, authorization
https://www.garlic.com/~lynn/aadsm17.htm#46 authentication and authorization (was: Question on the state of the security industry)
https://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda
https://www.garlic.com/~lynn/aadsm17.htm#50 authentication and authorization (was: Question on the state of the security industry)
https://www.garlic.com/~lynn/aadsm17.htm#51 authentication and authorization
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#18 Any TLS server key compromises?
https://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#31 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#43 SSL/TLS passive sniffing
https://www.garlic.com/~lynn/aadsm19.htm#11 EuroPKI 2005 - Call for Participation
https://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
https://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
https://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
https://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#44 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
https://www.garlic.com/~lynn/aadsm19.htm#48 Why Blockbuster looks at your ID
https://www.garlic.com/~lynn/aadsm19.htm#49 Why Blockbuster looks at your ID
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#8 UK EU presidency aims for Europe-wide biometric ID card
https://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#14 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#22 ID "theft" -- so what?
https://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
https://www.garlic.com/~lynn/aadsm20.htm#32 How many wrongs do you need to make a right?
https://www.garlic.com/~lynn/aadsm20.htm#38 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/2000b.html#53 Digital Certificates-Healthcare Setting
https://www.garlic.com/~lynn/2000e.html#50 Why trust root CAs ?
https://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2001c.html#8 Server authentication
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
https://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security' site.
https://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#54 Computer security: The Future
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
https://www.garlic.com/~lynn/2002f.html#22 Biometric Encryption: the solution for network intruders?
https://www.garlic.com/~lynn/2002g.html#66 Formal Classification for Security Topics
https://www.garlic.com/~lynn/2002g.html#78 Is it safe to use social securty number as intranet username?
https://www.garlic.com/~lynn/2002.html#24 Buffer overflow
https://www.garlic.com/~lynn/2002.html#39 Buffer overflow
https://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
https://www.garlic.com/~lynn/2002m.html#14 fingerprint authentication
https://www.garlic.com/~lynn/2002m.html#19 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#53 Authentication of others is a privilege, not a right
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
https://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003e.html#71 GOSIP
https://www.garlic.com/~lynn/2003f.html#35 Public Encryption Key
https://www.garlic.com/~lynn/2003f.html#37 unix
https://www.garlic.com/~lynn/2003h.html#18 Authentication protocol
https://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
https://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate
https://www.garlic.com/~lynn/2003l.html#33 RSA vs AES
https://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#30 Is this right? Question about SSL and PKI
https://www.garlic.com/~lynn/2003o.html#22 securID weakness
https://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
https://www.garlic.com/~lynn/2003p.html#6 Does OTP need authentication?
https://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
https://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA application
https://www.garlic.com/~lynn/2004g.html#6 Adding Certificates
https://www.garlic.com/~lynn/2004h.html#13 Two-factor Authentication Options?
https://www.garlic.com/~lynn/2004h.html#52 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#9 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#12 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#20 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004k.html#22 Public key authentication defeats passwd age warning
https://www.garlic.com/~lynn/2004k.html#27 Vintage computers are better than modern crap !
https://www.garlic.com/~lynn/2005e.html#22 PKI: the end
https://www.garlic.com/~lynn/2005e.html#25 PKI: the end
https://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
https://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
https://www.garlic.com/~lynn/2005g.html#0 What is a Certificate?
https://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
https://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#51 Security via hardware?
https://www.garlic.com/~lynn/2005g.html#54 Security via hardware?
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005h.html#8 keysigning: identity checks
https://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
https://www.garlic.com/~lynn/2005h.html#36 Security via hardware?
https://www.garlic.com/~lynn/2005.html#35 Do I need a certificat?
https://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom
https://www.garlic.com/~lynn/2005i.html#3 General PKI Question
https://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
https://www.garlic.com/~lynn/2005i.html#27 REPOST: Authentication, Authorization TO Firewall
https://www.garlic.com/~lynn/2005i.html#36 Improving Authentication on the Internet
https://www.garlic.com/~lynn/2005j.html#64 More on garbage
https://www.garlic.com/~lynn/2005k.html#23 More on garbage
https://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#13 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#15 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
https://www.garlic.com/~lynn/2005l.html#34 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains
https://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
https://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
https://www.garlic.com/~lynn/2005m.html#37 public key authentication
https://www.garlic.com/~lynn/2005m.html#45 Digital ID
https://www.garlic.com/~lynn/2005n.html#51 IPSEC and user vs machine authentication
https://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005o.html#9 Need a HOW TO create a client certificate for partner access
https://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
https://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
Another entry in the internet security hall of shame
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Another entry in the internet security hall of shame....
Date: Wed, 07 Sep 2005 15:25:40 -0600
To: Alaric Dailey <alaricd@xxxxxxxx>
CC: cryptography@xxxxxxxx, anti-fraud@xxxxxxxx
Alaric Dailey wrote:
But this overabundance of text doesn't solve my problems with the
assertion that PSKs are somehow more secure than Public/Private key
encryption with a trusted third party as verifier, and specifically the
X.509 Certificate Authority System that is the backbone for SSL.
and to repeat this off-told tale.
when were asked to work with this small client/server startup in
menlo part that wanted to do payment transactions
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
they had this stuff called SSL for hiding/encrypting session and
countermeasure for MITM-attack ... however we had to help work out the
actual business applications. Part of this was auditing the majority
operations called Certification Authorities. It was then that we
coined the term certificate manufacturing to differentiate what the
SSL Certification Authorities were doing from what is commoningly
written in the literature about PKIs.
https://www.garlic.com/~lynn/subpubkey.html#sslcert
So there is this proposal somewhat sponsored by the SSL Certification
Authority industry for having domain name owners register public keys
with the domain name infrastructure.
The issue is that the authoritative agency for domain names (that get
certified by certification authorities for SSL domain name
certificates) is the domain name infrastructure.
Currently, SSL domain name certificate applicate must provide a lot of
identification information ... and then the SSL certification
authority attempts to match the applicant's identification information
with the identification information on-file with the domain name
infrastructure. If it appears to match, the SSL certification
authority then goes ahead and issues an SSL domain name certificate
(aka this kind of certificate and the process is the majority of all
SSL certificates issued).
There are various exploits possible in the domain name infrastructure
that leads to integrity issues with the basic information that the SSL
certification authority is attempting to certify. One of the purposes
of having the domain name applicant supply a public key with their
other information ... is that in the future, the domain domain owner
will digitally sign all communication with the domain name
infrastructure. The domain name infrastructure then can verify with
the digital signatures with the on-file (PSK) public key ... which is
intended to close some possible vulnerabilities in the domain name
infrastructure.
There is another advantage for the SSL Certification Authority
industry. They can also require that all SSL domain name certificate
applicants digitally sign their applications. Then the SSL
certification authority can turn a time-consumer, error-prone, and
expensive identification operation into a much simpler, reliable and
less expensive authentication operation ... by retrieving the on-file,
certificate-less
https://www.garlic.com/~lynn/subpubkey.html#certless
public key for the domain name owner from the domain name
infrastructure ... to verify the digital signature on the SSL domain
name certificate application. The use of PSK, on-file, certificate-less
public key is intended to eliminate several possibly integrity
problems in the existing SSL domain name certification authority
process.
The issue then turns into something of a catch-22 for the SSL domain
name certification authority industry. If the SSL domain name
certification authority industry can base their whole trust
infrastructure on real-time, PSK, on-file certificate-less public keys
... it is possible that other operations in the world might also be
able to establish trust based on the real-time retrieval of PSK,
on-file, certificate-less public keys from the domain name
infrastructure.
One could imagine a highly optimized SSL protocol where the domain
name infrastructure piggy-backs any SSL options and public key on the
host->ip-address replay. At that point in time, the client has
real-time information that would have taken several message exchanges
and a digital certificate to obtain (making the availability of any
stale, static digital certificate redundant and superfluous). Then in
the initial client contact with the server .... they could piggyback
the public key encrypted session key ... and the initial encrypted
session request. In theory, almost a single round-trip SSL transaction
is possible ... modulo the TCP issue.
Minimum TCP session requires seven packet exchange (and the existing
SSL negotiation and protocol stuff is over and above that).
RFC1045, VMTP defined a minimum of five packet exchange for reliable
communication
XTP
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
defined a minimum of three packet exchange for reliable communication.
So theoretically, a transaction SSL-like operation is possible
piggybacked into XTP with minimum 3 packet exchange ... once the
response is obtained and cached from the domain name infrastructure.
Another entry in the internet security hall of shame
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Another entry in the internet security hall of shame....
Date: Wed, 07 Sep 2005 18:16:40 -0600
To: Alaric Dailey <alaricd@xxxxxxxx>
CC: cryptography@xxxxxxxx, anti-fraud@xxxxxxxx
Alaric Dailey wrote:
But this overabundance of text doesn't solve my problems with the
assertion that PSKs are somehow more secure than Public/Private key
encryption with a trusted third party as verifier, and specifically the
X.509 Certificate Authority System that is the backbone for SSL.
there may be some other confusing factors in play here ... besides
possibly the fact that there is periodic confusion over difference
between identification and authentication.
i've frequently raised the issue that there may be semantic confusion
with digital signatures and human signatures ... because both terms
contain the word "signature". a posting that touches on this subject
especially with early inclusion of the term non-repudiation in x.509
standards work
https://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
in this particular case ... it is frequent, popular short-hand reference
to certification authority as certificate authority system.
PKI nominally talks about
- RA ... registration authority ... typically involved in the
registration of the public key
- CA ... certification authority ... typically involved in the
certification of some information.
- digital certificate ... an "armored", stale, static set of bits that
typically represent some combination of the RA and CA operations ...
that can be used in offline environments where the relying party is not
expected to have their own information sources and/or have no direct
method of accessing the certification authority.
- trusted 3rd party ... nominally a certification authority that is
different than both a) the authoritative agency that nominally is
responsible for the information being certified. this is frequently the
case involving standard SSL domain name certificates where the
institution performing the domain name certification is different than
the domain name infrastructure responsible for the integrity of the
information, and also different than b) relying party that is dependent
on the certified information. A trusted 3rd party typically combines
both the RA and CA functions but frequently is a total different
organization that the operation actually responsible for the information
being certified.
https://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
- PKI nominally also defines administrative and management operations
for trying to maintain the accuracy of the certified information.
When we were working with this small client/server starting that had
come up with this thing called SSL ... and auditing some number of these
organizations refered to as certification authority ... we observed that
there was actually no "infrastructure" for the administrative and
management operations for the certified information. This is what
prompted us to come up with the term certificate manufacturing to
differentiate the difference.
However, to get back to possible confusion created when using
certificate authority in lieu of the correct term certification
authority; the business operation is the certification of the
information with regard to the accuracy and integrity of that
information. Independent from the certification of the accuracy and
integrity of the information ... is the packaging of bits into a stale,
static certificate representing that certification (and the integrity
characteristics of the packaging as divored from the integrity
characteristics of the actual information).
I frequently contend that it is equally possible to represent the
accuracy and integrity of some information with either online, realtime
operations or stale, static digital certificates. Realtime
representation can involve higher quality information like realtime
aggregation of whole sequence of events. Stale, static digital
certificates have an advantage in situations where the relying party has
no other way of obtaining the information (aka the letters of credit
scenario from the sailing ship days) and/or involve no value operations
that can't justify the possible higher cost of online access to higher
quality realtime and possibly aggregated information.
for some possible additional drift .... past posts mentiioning semantic
confusion involving the term digital signature
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm19.htm#7 JIE - Contracts in Cyberspace
https://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm19.htm#25 Digital signatures have a big problem with meaning
https://www.garlic.com/~lynn/aadsm20.htm#8 UK EU presidency aims for Europe-wide biometric ID card
https://www.garlic.com/~lynn/aadsm3.htm#kiss5 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))
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/2002m.html#43 It is GNU/Linux, not just Linux
https://www.garlic.com/~lynn/2003k.html#6 Security models
https://www.garlic.com/~lynn/2004i.html#27 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005f.html#20 Some questions on smart cards (Software licensing using smart cards)
https://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
https://www.garlic.com/~lynn/2005n.html#51 IPSEC and user vs machine authentication
AADS Postings and Posting Index,
next, previous
- home