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:
  1. the message/document hasn't been altered (since the digital signature)
  2. 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
  1. the PKI-oriented protocols provided no mechanism for proving which certificate had been originally attached to the transaction
  2. 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
  1. 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)
  2. 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
http://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
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
http://www.garlic.com/~lynn/2005j.html#64 More on garbage

misc. past posts discussing dual-use attacks on digital signatures
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
http://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
http://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols

numerous pasts posts discussing the non-repudiation characteristic
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#ocrp Online Certificate Revocation Protocol
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm6.htm#nonreput Sender and receiver non-repudiation
http://www.garlic.com/~lynn/aadsm6.htm#nonreput2 Sender and receiver non-repudiation
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11-> PKCS12
http://www.garlic.com/~lynn/aadsmail.htm#complex AADS/CADS complexity issue
http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
http://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses "Authority-stamp-signatures"
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
http://www.garlic.com/~lynn/aadsm14.htm#48 basic question: semantics of "map", "tie", etc in PKI
http://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
http://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm16.htm#11 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
http://www.garlic.com/~lynn/aadsm16.htm#14 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#17 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#18 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#23 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#55 MD5 collision in X509 certificates
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID?
http://www.garlic.com/~lynn/aadsm19.htm#12 EuroPKI 2005 - Call for Participation
http://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private information to improve security
http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002j.html#24 Definition of Non-Repudiation ?
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
http://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2003f.html#37 unix
http://www.garlic.com/~lynn/2003h.html#29 application of unique signature
http://www.garlic.com/~lynn/2003h.html#38 entity authentication with non-repudiation
http://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003.html#29 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
http://www.garlic.com/~lynn/2003k.html#6 Security models
http://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the same key for authentication and encryption
http://www.garlic.com/~lynn/2003o.html#22 securID weakness
http://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
http://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
http://www.garlic.com/~lynn/2003p.html#11 Order of Encryption and Authentication
http://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
http://www.garlic.com/~lynn/2004e.html#20 Soft signatures
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005d.html#32 Is a cryptographic monoculture hurting us all?
http://www.garlic.com/~lynn/2005e.html#41 xml-security vs. native security
http://www.garlic.com/~lynn/2005e.html#42 xml-security vs. native security
http://www.garlic.com/~lynn/2005g.html#51 Security via hardware?
http://www.garlic.com/~lynn/2005j.html#64 More on garbage
http://www.garlic.com/~lynn/2005k.html#23 More on garbage
http://www.garlic.com/~lynn/2005k.html#26 More on garbage
http://www.garlic.com/~lynn/2005k.html#55 Encryption Everywhere? (Was: Re: Ho boy! Another big one!)
http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
http://www.garlic.com/~lynn/2005m.html#6 Creating certs for others (without their private keys)
http://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
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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 succesfully 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
http://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 succesful 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
http://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 ...
  1. something you have authentication
  2. 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
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://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:
http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://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 succesful ... 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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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 succesful 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.
http://www.garlic.com/~lynn/2001h.html#38 Credit Card # encryption
http://www.garlic.com/~lynn/2001h.html#39 Credit Card # encryption
http://www.garlic.com/~lynn/2001i.html#53 Credit Card # encryption
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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 http://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.
  1. 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).
  2. 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).
  3. 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
  4. 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
    http://www.garlic.com/~lynn/subpubkey.html#certless
  5. 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
  6. 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,
    1. the $100/annum/certificate would exceed the costs of upgrading mainline production system,
    2. 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.
  7. 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 ...
    http://www.garlic.com/~lynn/x959.html#x959
    http://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.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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 http://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:
http://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 unsuccesful ... 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 succesful ... 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:
http://www.garlic.com/~lynn/ansiepay.htm#x959demo X9.59/AADS demos operational
http://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature
http://www.garlic.com/~lynn/aepay11.htm#65 E-merchants Turn Fraud-busters (somewhat related)
http://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aadsm18.htm#15 In Search of Eve - the upper boundary on Mallory
http://www.garlic.com/~lynn/aadsm19.htm#39 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
http://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#19 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#13 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#13 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#14 The Worth of Verisign's Brand
http://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
http://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:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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:
http://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
http://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.
http://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 ...
http://www.garlic.com/~lynn/x959.html#x959
http://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:
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki11 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#28 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm15.htm#27 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and authentication
http://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
http://www.garlic.com/~lynn/2001j.html#0 e-commerce security????
http://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site
http://www.garlic.com/~lynn/2002n.html#14 So how does it work... (public/private key)
http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004m.html#9 REVIEW: "Biometrics for Network Security", Paul Reid
http://www.garlic.com/~lynn/2005k.html#26 More on garbage
http://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:
http://www.garlic.com/~lynn/aadsm20.htm#10 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#15 the limits of crypto and authentication
http://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
  1. 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)
  2. 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:
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking

ID "theft" -- so what?

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,
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959 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. http://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
http://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
http://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 ...
http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003o.html#46 What 'NSA'?
http://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
http://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.
http://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.
http://www.garlic.com/~lynn/subpubkey.html#sslcert


oops, finger slip, that should be
http://www.garlic.com/~lynn/subpubkey.html#sslcert

... oh, and there are some slightly related postings regarding the period from another thread:
http://www.garlic.com/~lynn/2005n.html#30 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005n.html#26 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005n.html#27 Data communications over telegraph circuits
http://www.garlic.com/~lynn/2005n.html#28 Data communications over telegraph circuits
http://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.
http://www.garlic.com/~lynn/aadsm15.htm#9 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/2002l.html#12 IEEE article on intelligence and security
http://www.garlic.com/~lynn/2003h.html#26 HELP, Vulnerability in Debit PIN Encryption security, possibly
http://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 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
  1. the online technology to access the real information is becoming more ubiquitous,
  2. the cost of doing online access to the real information has been dropping,
  3. 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 ...
  1. the "real information" is the authoritative agency responsible for the actual information.
  2. typically a certification authority then will create its own repository operation duplicating the real information
  3. 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.
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline situation
http://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.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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.
http://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
  1. key exchange ... which can be done via other mechanism
  2. 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)
http://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;
  1. if you improve the integrity of the domain name infrastructure it reduces the requirement for having ssl domain name certificates
  2. 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
http://www.garlic.com/~lynn/2005n.html#43 X509 digital certificate for offline solution
http://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
  1. any cancelation was effective immediate for all relying-parties
  2. 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.
  3. 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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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)
http://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
http://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
http://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution
http://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
http://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.
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction?
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#23 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#1 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#31 More Phishing scams, still no SSL being used
http://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 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
http://www.garlic.com/~lynn/aepay10.htm#74 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
http://www.garlic.com/~lynn/aadsm19.htm#8 GeoTrust says existing PKI practices are worthless
http://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
http://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2004b.html#25 Who is the most likely to use PK?
http://www.garlic.com/~lynn/2004b.html#52 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#13 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#24 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005k.html#29 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#11 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#21 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
http://www.garlic.com/~lynn/2005l.html#33 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://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
http://www.garlic.com/~lynn/2005o.html#31
http://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
http://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
http://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
http://www.garlic.com/~lynn/subpubkey.html#radius
http://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.
http://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)
http://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.
http://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
http://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
http://www.garlic.com/~lynn/subpubkey.html#radius
http://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.
http://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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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 scaleup 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 writting 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.
http://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.
http://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.
  1. 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
  2. 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.
  3. 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).
  4. 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:
http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
http://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
http://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
http://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
http://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://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
  1. trust certification
  2. 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
http://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
http://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
http://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
http://www.garlic.com/~lynn/aepay11.htm#13 Microsoft Fixes Passport to Meet EU Privacy Rules
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#58 PKI's not working
http://www.garlic.com/~lynn/aepay11.htm#60 PKI's not working
http://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#71 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#2 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#4 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/aadsm7.htm#rhose4 Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose11 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose14 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose15 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#rhose16 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki9 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm8.htm#3dvulner3 3D Secure Vulnerabilities?
http://www.garlic.com/~lynn/aadsm9.htm#3dvulner5 3D Secure Vulnerabilities?
http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
http://www.garlic.com/~lynn/aadsm10.htm#anonpay Crypto Winter (Re: Looking back ten years: Another Cypherpunks failure)
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#17 Alternative to Microsoft Passport: Sunshine vs Hai
http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm11.htm#43 PKI: Only Mostly Dead
http://www.garlic.com/~lynn/aadsm12.htm#4 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#32 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction?
http://www.garlic.com/~lynn/aadsm12.htm#50 Frist Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#53 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm13.htm#12 Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#13 A Trial Balloon to Ban Email?
http://www.garlic.com/~lynn/aadsm14.htm#26 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#29 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#33 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#40 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
http://www.garlic.com/~lynn/aadsm14.htm#48 basic question: semantics of "map", "tie", etc in PKI
http://www.garlic.com/~lynn/aadsm15.htm#4 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#7 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm15.htm#11 Resolving an identifier into a meaning
http://www.garlic.com/~lynn/aadsm15.htm#16 End of the line for Ireland's dotcom star
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm15.htm#26 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm15.htm#38 FAQ: e-Signatures and Payments
http://www.garlic.com/~lynn/aadsm16.htm#16 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
http://www.garlic.com/~lynn/aadsm17.htm#1 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#2 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#4 Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
http://www.garlic.com/~lynn/aadsm17.htm#16 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#20 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#21 Identity (was PKI International Consortium)
http://www.garlic.com/~lynn/aadsm17.htm#23 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#25 Single Identity. Was: PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#26 privacy, authentication, identification, authorization
http://www.garlic.com/~lynn/aadsm17.htm#46 authentication and authorization (was: Question on the state of the security industry)
http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda
http://www.garlic.com/~lynn/aadsm17.htm#50 authentication and authorization (was: Question on the state of the security industry)
http://www.garlic.com/~lynn/aadsm17.htm#51 authentication and authorization
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#18 Any TLS server key compromises?
http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#31 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#43 SSL/TLS passive sniffing
http://www.garlic.com/~lynn/aadsm19.htm#11 EuroPKI 2005 - Call for Participation
http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#44 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#45 payment system fraud, etc
http://www.garlic.com/~lynn/aadsm19.htm#48 Why Blockbuster looks at your ID
http://www.garlic.com/~lynn/aadsm19.htm#49 Why Blockbuster looks at your ID
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#8 UK EU presidency aims for Europe-wide biometric ID card
http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#14 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#22 ID "theft" -- so what?
http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
http://www.garlic.com/~lynn/aadsm20.htm#32 How many wrongs do you need to make a right?
http://www.garlic.com/~lynn/aadsm20.htm#38 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/2000b.html#53 Digital Certificates-Healthcare Setting
http://www.garlic.com/~lynn/2000e.html#50 Why trust root CAs ?
http://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#54 Computer security: The Future
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
http://www.garlic.com/~lynn/2002f.html#22 Biometric Encryption: the solution for network intruders?
http://www.garlic.com/~lynn/2002g.html#66 Formal Classification for Security Topics
http://www.garlic.com/~lynn/2002g.html#78 Is it safe to use social securty number as intranet username?
http://www.garlic.com/~lynn/2002.html#24 Buffer overflow
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002m.html#14 fingerprint authentication
http://www.garlic.com/~lynn/2002m.html#19 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#53 Authentication of others is a privilege, not a right
http://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003e.html#71 GOSIP
http://www.garlic.com/~lynn/2003f.html#35 Public Encryption Key
http://www.garlic.com/~lynn/2003f.html#37 unix
http://www.garlic.com/~lynn/2003h.html#18 Authentication protocol
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
http://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate
http://www.garlic.com/~lynn/2003l.html#33 RSA vs AES
http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003m.html#51 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#30 Is this right? Question about SSL and PKI
http://www.garlic.com/~lynn/2003o.html#22 securID weakness
http://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
http://www.garlic.com/~lynn/2003p.html#6 Does OTP need authentication?
http://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
http://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA application
http://www.garlic.com/~lynn/2004g.html#6 Adding Certificates
http://www.garlic.com/~lynn/2004h.html#13 Two-factor Authentication Options?
http://www.garlic.com/~lynn/2004h.html#52 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#9 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#12 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#20 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#13 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004k.html#22 Public key authentication defeats passwd age warning
http://www.garlic.com/~lynn/2004k.html#27 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2005e.html#22 PKI: the end
http://www.garlic.com/~lynn/2005e.html#25 PKI: the end
http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
http://www.garlic.com/~lynn/2005g.html#0 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#51 Security via hardware?
http://www.garlic.com/~lynn/2005g.html#54 Security via hardware?
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005h.html#8 keysigning: identity checks
http://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
http://www.garlic.com/~lynn/2005h.html#36 Security via hardware?
http://www.garlic.com/~lynn/2005.html#35 Do I need a certificat?
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom
http://www.garlic.com/~lynn/2005i.html#3 General PKI Question
http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2005i.html#27 REPOST: Authentication, Authorization TO Firewall
http://www.garlic.com/~lynn/2005i.html#36 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2005j.html#64 More on garbage
http://www.garlic.com/~lynn/2005k.html#23 More on garbage
http://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#13 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#15 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#22 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
http://www.garlic.com/~lynn/2005l.html#34 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains
http://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005m.html#45 Digital ID
http://www.garlic.com/~lynn/2005n.html#51 IPSEC and user vs machine authentication
http://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005o.html#9 Need a HOW TO create a client certificate for partner access
http://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
http://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 were asked to work with this small client/server startup in menlo part that wanted to do payment transactions
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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.
http://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
http://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
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

defined a minimum of three packet exchange for reliable communication.

So theoritically, 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
http://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
  1. RA ... registration authority ... typically involved in the registration of the public key
  2. CA ... certification authority ... typically involved in the certification of some information.
  3. 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.
  4. 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.
    http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
  5. 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
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm19.htm#7 JIE - Contracts in Cyberspace
http://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private information to improve security
http://www.garlic.com/~lynn/aadsm19.htm#25 Digital signatures have a big problem with meaning
http://www.garlic.com/~lynn/aadsm20.htm#8 UK EU presidency aims for Europe-wide biometric ID card
http://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))
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/2002m.html#43 It is GNU/Linux, not just Linux
http://www.garlic.com/~lynn/2003k.html#6 Security models
http://www.garlic.com/~lynn/2004i.html#27 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005f.html#20 Some questions on smart cards (Software licensing using smart cards)
http://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
http://www.garlic.com/~lynn/2005n.html#51 IPSEC and user vs machine authentication

AADS Postings and Posting Index, next, previous - home