Misc AADS & X9.59 Discussions


AADS Postings and Posting Index,
next, previous - home

two-factor authentication problems
Do You Need a Digital ID?
Do You Need a Digital ID?
Do You Need a Digital ID?
Do You Need a Digital ID?
Do You Need a Digital ID?
Do You Need a Digital ID?
JIE - Contracts in Cyberspace
GeoTrust says existing PKI practices are worthless
PKI News
Security as a "Consumer Choice" model or as a sales (SANS) model?
EuroPKI 2005 - Call for Participation
EuroPKI 2005 - Call for Participation
What happened with the session fixation bug?
To live in interesting times - open Identity systems
Loss Expectancy in NPV calculations
Loss Expectancy in NPV calculations
What happened with the session fixation bug?
Citibank discloses private information to improve security
"SSL stops credit card sniffing" is a correlation/causality myth
Citibank discloses private information to improve security
Citibank discloses private information to improve security
Citibank discloses private information to improve security
Citibank discloses private information to improve security
Citibank discloses private information to improve security
Digital signatures have a big problem with meaning
Trojan horse attack involving many major Israeli companies, executives
Citibank discloses private information to improve security
"SSL stops credit card sniffing" is a correlation/causality myth
[Clips] Paying Extra for Faster Airport Security
Digital signatures have a big problem with meaning
[Clips] Paying Extra for Faster Airport Security
Using Corporate Logos to Beat ID Theft
Digital signatures have a big problem with meaning
encrypted tapes (was Re: Papers about "Algorithm hiding" ?)
de-identification
expanding a password into many keys
expanding a password into many keys
massive data theft at MasterCard processor
massive data theft at MasterCard processor
massive data theft at MasterCard processor
massive data theft at MasterCard processor
massive data theft at MasterCard processor
massive data theft at MasterCard processor
massive data theft at MasterCard processor
payment system fraud, etc
the limits of crypto and authentication
the limits of crypto and authentication
Why Blockbuster looks at your ID
Why Blockbuster looks at your ID

two-factor authentication problems

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: two-factor authentication problems
Date: Tue, 08 Mar 2005 07:08:16 -0700
To: gabriel@xxxxxxxx
CC: 'Matt Crawford' <crawdad@xxxxxxxx>, 'Ed Gerck' <egerck@xxxxxxxx>,
cryptography@xxxxxxxx
Gabriel Haythornthwaite wrote:
RSA SecureID and OATH technology have some great virtues:
- they cost nothing to integrate at the client end - there is no client "footprint" so there's nothing to go wrong
- they are relatively easy to understand and use
- they're unquestionably better than reliance on user IDs and passwords.

ref:
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems

note that there is typically some close relationship between a secureid and the relying party .... that if everything is working correctly ... the relying party is pretty sure that (most of the times) the response originated from a valid token .... although there are various kinds of attacks and vulnerabilities associated with originating that information and/or transmitting it to the relying party.

most PKIs tend to focus on the integrity of the indiciation arriving at the relying party. the digital signature is an indication that something occured at the remote end ... namely some entity accessed and used a private key. however, almost all PKI descriptions fail to focus on the primary event (that a digital signature is suppose to indicate) is that some form of 3factor authentication actually occured in the access and use of a private key. A lot of PKI has shifted the focus from the fundamental authentication business process (the integrity of the access and use of a private key) to the integrity of the communication that some (any arbitrary) access and use of a private key (while failing to establish the there was any fundamental integrity actually associated with the actual access and use of the private key).

aka ... digital signatures are a secondary factor associated with the primary integrity event of concern. the primary integrity business process is the actual access and use of the private key. a digital signature is a secondary integrity factor ... the indication or communication that some access and use of a private key has occured (w/o having any indication about the actual integrity of that access and use).

the actual access and use of the private key would be the primary integrity event of concern. the (high integrity) communication that such an access and use has concerned is secondary to the actual access and use (although both can be considered as attack targets or vulnerabilities).

note that integrity of the actual access and use of the private key, establishing some form of 3factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor

and the communication that some actual access and use of the private key has occured with a digital signature

is orthogonal whether the relying party is relying on a (offline, unconnected) PKI model or a certificate-less
https://www.garlic.com/~lynn/subpubkey.html#certless

The PKI model was original met to target the scenario where the relying party has had no prior relationship with the originating party and/or has no access and/or recourse to any other source of information (especially online access) about the originating party.

However, PKI descriptions have frequently obfuscated that there is other business processes requiring integrity issues (aka anything other than those related to certificate generation and use).

The actual core process that everything depends on is the integrity surronding the access and use of the private key .... and all other processes are scaffolding intended to provide a remote relying party some indication that the access and use of a private key has occured.

PKI models frequently fail to even bother to describe that the primary integrity issue is the access and use of the private key (and everything else is secondary). PKI models also frequently fail to describe that they are intended for the offline, unconnected business environment ... which has become the small minority of actual business processes in the world today.

Do You Need a Digital ID?

Refed: **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Do You Need a Digital ID?
Date: Tue, 15 Mar 2005 12:40:59 -0700
To: R.A. Hettinga <rah@xxxxxxxx>
CC: cryptography@xxxxxxxx
R.A. Hettinga wrote:
http://www.pcworld.com/resource/printable/article/0,aid,120008,00.asp

i've been asked to flush out my merged security taxonomy and glossary
https://www.garlic.com/~lynn/index.html#glosnote

to highlight the distinction between identity theft and account theft. typically identity theft is that enuf information is obtained to fraudulently be able to open new accounts in the victim's name (among other things) while account theft is that the thief has enuf information to perform fraudulent transactions against an existing account of the victim.

account theft tends to be attacks on poor authentication procedures by account institutions and/or use of social engineering or phishing to obtain the victim's account authentication information (which shares a lot in common with straight identity theft).

a common exploit is the use of skimming/sniffing of static authentication verification data that enables creating counterfeit tokens/cards that enables fraudulent transactions.

given 3-factor authentication: there can be a great deal of confusion whether a token/card represents something you have authentication or not. If a token/card contains valid authentication information and if that token/card is lost/stolen and a new account has to be created .... then it is likely the token/card represents something you have authentication.

however, some infrastructure just utilize a token/card to provide the equilvalent of userid (say an account number which isn't required to be secret) and the actual authentication is in the form of a password/PIN ... i.e. something you know authentication. just because a token/card is involved along with a PIN/password doesn't automatically imply that two-factor authentication is involved.

if a re-issued a new token/card (to replace a lost/stolen token/card) is identical to the lost/stolen token/card ... then it is likely that there is no something you have authentication involved (even tho a token/card is involved in the process) ... and therefor the infrastructure is just single factor authentication.

at the basics, a digital signature is an indirect indication of something you have authentication .... aka the existance of a digital signature implies that the originator accessed and utilized a private key in the generation of the digital signature. a digital signature by itself says nothing about the integrity of that something you have authentication ... since the digital signature doesn't carry any indication of the integrity measures used to secure and access the associated private key.

there is some temptation to claim that the a lot of the problems with establishment of digital signature technology is that the basic trust building blocks haven't been established. numerous institutions have spent a lot of time focusing on the trust infrastructures associated with certification authority operation and digital certificates .... which have nothing directly to do with any form of 3-factor authentication.

the basic building block is that a financial (or other) institutions have ongoing relationships represented by established accounts and that the entities associated with those accounts have established authentication material. In the case of digital signatures, that would be public keys. To the degree that a relying party institution (financial or other) can trust what is represented by a digital signature is the integrity level of the environment that protects the access and use of the associated private key .... w/o additional knowledge, the relying party simply knows that some entity accessed and utilized a specific private key ... as in a simple, single factor, something you have authentication.

A digital signature by itself has no indication of the security and integrity level associated with the private key protection, access and use ... and/or if there is anything more than simple, single factor, something you have authentication.

Furthermore, in the great majority of the transactions involving established relationships, there is no need for digital certificates to establish identication information .... straight-forward authentication tends to be sufficient.

misc. past 3-factor authentication posts
https://www.garlic.com/~lynn/subintegrity.html#3factor

Do You Need a Digital ID?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Do You Need a Digital ID?
Date: Mon, 21 Mar 2005 08:27:53 -0700
To: Jerrold Leichter <jerrold.leichter@xxxxxxxx>
CC: R.A. Hettinga <rah@xxxxxxxx>,  cryptography@xxxxxxxx
now, i've said that all of these comments are within the 3-factor authentication paradigm ... if you back up a couple paragraphs in the original postings ... you will find the comments:
given 3-factor authentication:

aka the comments/postings are within the framework/paradigm of 3-factor authentication. so is the issue with the 3-factor authentication framework ... or is the issue that the comments are inconsistent given a 3-factor authentication framework?

I assert (as stated in the original posting) that the comments/posting is within the context of 3-factor authentication framework and the definition of the public/private key business process. you are free to define something other than 3-factor authentication framework .... or a totally different business process for the treatment of asymmetric cryptography keys.

a digital signature is something that is supposedly hard to counterfeit .... and just represents the application of a private key to some data (the digital signature is an indication/expression that a private key has been accessed and used). for most entities, a private key is not something that is memorized, but rather it is contained by something that the human has. the integrity of the process is based on the integrity of the infrastructure that controls the access and use of that private key ... therefor a digital signature infrastructure typically represents a something you have technology.

the whole asymmetric cryptography technology (of which a digital signature is just a part) has been taken and a business process wrapped afound it which is frequently referred to as public/private key cryptography (an abbreviation frequently to simple public key technology). the foundation of the public/private key (or public key technology for short) business process is based on keeping the "private key" actually "private". If everybody is allowed to have as free access to the "private keys" as there is access to the "public key" ... the whole infrastructure (including digital signatures) falls apart.

So if you are looking at a threat assessement ... the public/private key business process allows for both digital signatures and public keys to be readily known ... the whole foundation that holds the whole "public key" business process together is based on keeping the private key actually unknown and unaccessible to others than the authorized entities.

so i've haven't seen any private key deployments which are based on a human actually memorizing the private key ... so it can't be a (at least directly) a something you know operation. of the private key deployments i've seen, there has been the requirement that an entity possesses a "private key" and is able to access and make use of that "private key" ... since it isn't something you know (and since a "private key" is also not typically something you are biometrics) then that leaves a "private key" representing something you have.

so if you look at typical something you have infrastructures, their integrity is based on the protection of the operations that access and utilize the something you have.

as i pointed out in one of the earlier postings, much of the literature in the mid-90s grossly confused the terms digital signature and digital certificates and private key ... to the point that it sometimes represented that a digital ceritifcate was responsible for generating a digital signature (or by implication the public key included in a digital certificate). Since the public/private key business process allows for both digital signatures and public keys to be readily known, it is fairly obvious that they can't be the integrity/security foundation for the business process.

so when a digital signature is validated with a public key ... what is it doing ... it is validating that the private key (of a public/private key pair from asymmetric cryptography) generated that digital signature. "private key" isn't a characteristic of asymmetric cryptography ... it is a characteristic of public/private key business process requiring that the "private key" be kept private. a digital signature is just an expression of the business process use of that private key.

so from 3-factor authentication paradign there are three things: now, i know of no public/private key business process deployments that require humans to memorize the private key ... that eliminates (at least direct use of) something you know authentication.

the most common deployments of public/private key business process deployment aren't based on biometrics ... which then eliminates something you are authentication.

that just leaves "private keys" as a type of something you have technology ... (since it isn't memorized or biometrics). therefor the foundation of public/private key business process deployments (frequently abbreviated to simply public key ... with the existance of a corresponding pviate key assumed) is based on the possession of a private key and the business processes of keeping that private key actually private (and the business processes of uniquely being able to use the private key and not having it widely available to large numbers of unauthorized people).

now, usually once past the description of public key business processes for public consumption (where it might actually be stated that the digital signature was generated by the digital certificate) .... you quickly get into the foundations which are based on
  1. asymmetric key cryptography
  2. business process of allowing one of the asymmetric key pair to be made public
  3. business process of allowing one of the asymmetric key pair to be kept private
  4. business process of consistently maintaining the privacy of the designated private key.
repeating 3-factor authentication paradign digital signature is an expression of the private key business process that consistently and reliably maintains the privacy of the private key. private key isn't a technology (like asymmetric key cryptography is a technology). private key is a business process application to asymmetric key cryptography. the access and use of a private key is supposedly for the purpose of reliably authenticating the entity associated with that private key. so by process of elimination: by process of elimination, if the "public key" deployments aren't typically something you know or something you are ... then that just leaves "public key" deployments to be something you have authentication.

now it is obvious that a specific physical object can be in unique possession of a specific entity (modulo physical object counterfeiting). however, the business process for public/private key defines that a private key is in the unique possesion of a specific entity. not by law of physics ... but by law of the business process. if you violate the law of the business process and allow multiple entities to possess the private key (say you include both the private key and the public key in a widely published digital certificate) then the whole public/private key business process would come apart.

lots of past postings on 3-factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor

I do agree that (possibly because of the syntactic similarity) lots of people confuse digital signature and real human signatures. A human signature carries with it the connotation of understanding, aggreement, approval, authorization, etc. A digital signature is simply the expression of the access and use of a private key ... and the definition/law of the public/private key business process is that the private key be consistently protected and kept private so that relying parties ... when verifying a particular digital signature ... can associate it with the authentication of a specific entity.

There are several deployed infrastructures of the application of the public/private key business process, where the digital signature generation is simply for authentication purposes ... there is a human that is responsible for activating the access and operation of the private key for the generation of the digital signature ... w/o a requirement that the human ever observes the contents of what the digital signature is being applied to.

As previously mentioned numerous times before ... there is a dual-use attack on public/private key infrastructures where there are procedures in place that require a human to observe, read, and understand any bits that are being digital signed. However, if the same private key that is used in real "signature" applications, is also ever used in authentication applications where the human doesn't observe and read the contents, then the attacker just supplies a valid document masguerading as authentication bits (which the human won't be reading and/or understanding).

note that non-repudiation is sometimes referenced with regard to some aspects of digital signatures being similar to human signatures (aka read, observe, understand, approve, authorize, agree). the eu finread definition tried to include some aspects of read, observe, understand, approx, authorize, agree ... misc. past finread postings:
https://www.garlic.com/~lynn/subintegrity.html#finread

Jerrold Leichter wrote:
This is a rather bizarre way of defining things. Something you have is a physical object. On the one hand, any physical object can be copied to an arbitrary degree of precision; on the other hand, no two physical objects are *identical*. So a distinction based on whether a replacement is "identical" to the original gets you nowhere.

A digital signature is just a big number. In principal, it can be memorized, thus becoming something you know. As a *number*, I don't see how it can, in and of itself, *ever* be something you *have*.

From a purely information point of view, there is not, and cannot be, any difference among the different authentication modalities. A house key can be represented as a fairly short number (the key blank number and the pinning). Even a very fancy and elaborate key - or any physical object - can, in principle, be represented as a CAD file. While "something I am" is difficult to represent completely this way (at least today!), it doesn't matter: A "something I am" *authentication element* has to ultimately be testable for veracity on the basis of information the tester has access to.

The meaningful distinction here has to do with possible modes of attack, constrained by the *physical* characteristics of the system. An authentication element is something you have if an attacker must gain physical possession of it to be able to authenticate as you. The "closeness" and length of time the attacker must possess the element form the fundamental "measures of quality" of such an element. A house key is a prototypical something you have. Duplicating it requires the ability to physically hold it. (One can, of course, imagine taking very detailed photographs from a distance, or using some other kind of remote sensing technology. While possible in principle, this would be a very expensive and difficult attack in practice, and we generally ignore the possibility.) Keys with restricted blanks are relatively difficult to duplicate even if you have physical possession. We generally assume that you can take a key back, thus revoking access. This is also a general property of any something you have authentication element - and is truely present only to some degree. Still, one can meaningfully ask of such an element "How many copies are in existence? Who has access to them?"

Conversely, something you know can, in principle, only be learned by you revealing it. Once revealed, a something you know element cannot be revoked. It can be copied easily, and determining who might know it is usually impractical once there is any suspicion of compromise.

A key card by itself is like a blank house key. It becomes something you have when it's encoded with a password, a digital signature private key, or some other secret that's, say, part of an interactive zero-knowledge proof system. The quality of the key card depends on how easy it is to extract the information and produce another key card that can be used in its place.

Of course, quality is a *system* property. A house key "reveals its secret" when placed in a lock - any lock. While I could easily enough build a lock that would read off the pinning of any key inserted into it and send it to me on the Internet, this doesn't at present appear to be a threat that needs to be defended against. We generally assume that locks are simple physical devices that don't leak any information. On the other hand, a key card by its very nature sends information into a digital system, and protecting information once it is in digital form is challenging. If I could know to a sufficient degree of certainty that my keycard would only be used in "secure" readers which would send the information no further, there would be relatively little difference between a key card with a simple password encoded on a magnetic strip, and a house hey. Both would provide a something you have element.

A "digital signature" isn't an authentication element at all! We incorrectly analogize it to a traditional signature, because inherent in the notion of the latter is a whole system embodying assumptions like (a) a signature instance is physically created by the party being authenticated; (b) we can effectively distinguish an instance thus created from a duplicate. I can photocopy a signature perfectly. If it were impossible to distinguish a photocopy from an original - based on pen pressure on the paper, ink vs. toner, etc. - signatures would be completely worthless as authentication elements. To decide whether a "digital signature" is something you have, something you know, or perhaps even something you are - a signature based somehow on biometrics; or not a reaonable authentication element at all; requires knowing how the abstract bits that define that signature are actually used in the total physical system.

Do You Need a Digital ID?

Refed: **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Do You Need a Digital ID?
Date: Mon, 21 Mar 2005 09:13:57 -0700
To: Jerrold Leichter <jerrold.leichter@xxxxxxxx>
CC: R.A. Hettinga <rah@xxxxxxxx>,  cryptography@xxxxxxxx
minor addenda ... ref:
https://www.garlic.com/~lynn/aadsm19.htm#1 Do You Need a Digital ID?
https://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID?

there are 2nd order implementations of public/private key authentication business process where keeping the private key private might involve note in the old fashion identity digital certificates from the early 90s ... there was frequently little or no discussion as to the integrity requirements regarding the ability to access and use a specific private key (which is what the whole private/public key business process is fundamentally built on). there was frequently lots of documentation on what a certification authority might do in the integrity around the generation of an identity digital certificate .... but very little or nothing about what the key owner was required to do in order to enable the whole fundamental public/private key business process to operate correctly.

Do You Need a Digital ID?

From: Anne & Lynn Wheeler <lynn@xxxxxxx>
Subject: Re: Do You Need a Digital ID?
Date: Mon, 21 Mar 2005 20:11:51 -0700
To: Jerrold Leichter <jerrold.leichter@xxxxxxxxx>
CC: R.A. Hettinga <rah@xxxxxxxx>, cryptography@xxxxxxx
Jerrold Leichter wrote:
I don't think the 3-factor authentication framework is nearly as well-defined as people make it out to be.

Here is what I've always taken to be the core distinctions among the three prongs:

Something you know
Can be copied.
If copied illicitly, you can't tell (except by noticing illicit uses).

Something you have
Cannot be copied.
Can be transferred (i.e., you can give it to someone else, but then you no longer have it)
Hence, if transferred illicitly, you can quickly detect it.

Something you are
Cannot be transferred.
Cannot be changed.
Inherently tied to your identity, not your role.

This classification, useful as it is, certainly doesn't cover the space of possible authentication techniques. For example, an RFID chip embedded under the skin and designed to destroy itself if removed doesn't exactly match any of these sets of properties: It's not something you have because it can't be transferred, but it's not something you are because it can be changed. Attempting to force-fit everything into an incomplete model doesn't strike me as a useful exercise.

but business rules for public(/private) key infrastructure can describe that the associated authenticated entity is the only one in possession of the private key (something you have) .... as a way of relating the objective of having a specific entity's exclusive ability to access and utilize a private key to three factor authentication.

almost all of the existing something you have authentication objects are capable of being counterfeited to a greater or lesser degree. possibly the widest deployed something you have authentication objects are magstripe plastic cards ... and it turns out they have been proven to be remarkably easy to counterfeit/copied. the distinction between the ease or difficulty of counterfeiting/copying a magstripe plastic card vis-a-vis a private key ... depends on the level of security used to prevent it from being copied. obviously a private key can be copied with relative ease (possibly much easier than a magstripe plastic card).

in general, you will find that almost all something you have authentication objects are subject to being copied ... the issue is the degree to which security processes are in place to prevent them from being copied. just because a private key ... represented by some sequence of bits can be easily copied ... when no protections are in force ... doesn't mean that there can't be security procedures put into place that would make it extremely difficult to achieve copying of a private key.

most models serve a useful purpose until somebody comes up with a better or more applicable model.

many of the 3-factor authentication implementations actually use some representation that allows the actual occurence to be implied by something else.

for instance something you know authentication can be done as a shared-secret where both the originator and the relying party are both in possession of the shared-secret. an example are keys in symmetric key cryptography.

however, it is possible to have something you know authentication where the secret is not shared. For instance if there is a hardware token that is certified to only operate when the correct PIN has been entered .... the PIN represents something you know authentication w/o having to share the secret with any other party (the relying party assumes that the correct PIN has been entered by a) being confident of the operation of the particular hardware token and b) the hardware token having done something known & expected).

similarly, biometrics systems are frequently implemented as a form of shared-secret. an entity's biometric template is registered with some relying party .... and subsequent transactions are authenticated by checking a new biometric template with the biometric template on file. the x9.84 biometric standard devotes a great deal to the security for centrally stored biometric templates .... treating them as a greater security risk than traditional something you know shared-secrets. the threat is that somebody can obtain files of registered biometric templates and be able to subsequently retransmit them electronicly attempting to impersonate the associated person. The issue in the traditional something you know shared-secret is that a PIN compromise can be reported and a new, replacement PIN/password created. However, it is somewhat more difficult to replace a thumb or iris when there has been a reported compromise of something you are shared-secret.

in any case, for all of the deployed existing authentication systems involving any one of the three factor authentication paradigms, all of the methods are vulnerable to copying to one degree or another. as a result, I would assert that criteria of being able to copy or not is not useful .... in all of the different three factors, it isn't whether they are copyable .... it is the difficulty with which they can be copied. The difficulty that any of them can be copied or counterfeited can be a combination of their native characteristics and the level of security that they are wrapped in.

i would further assert that the meaningful aspects represented by the three=factor authentication model is not the native characteristic of the components but how the individual being authenticated interacts with the components .... i.e.
  1. something you know .... implies that the person has to know the value
  2. something you have ... implies that the person is in possession of the thing or value ... but doesn't actually know or have it memorized
  3. something you are .... implies that it represents some physical characteristic of the person ... w/o the person needing to either know or otherwise possess the object or value.
all three methods can be implemented as static value or shared-secret implementations ... where the characteristic of the particular authentication mode is expressed as some static value and is vulnerable to shared-secret eavesdropping or skimming. Something you know shared-secrets can be eavesdropped and fraudulently used. A magstripe plastic card something you have is expressed as transmission of the contents of the magstripe, which can be skimmed and used to create counterfeit/copied cards. A something you are feature is expressed as biometric template which can be eavesdropped and used in fraudulent transmissions (or counterfeited in things like the gummy bear attack).

rather than interpret 3-factor authentication as physical characteristics which are classified as being copyable or not-copyable ... 3-factor authentication is frequently interpreted as how the entity being authentication relates to the authentication process.

Do You Need a Digital ID?

Refed: **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Do You Need a Digital ID?
Date: Wed, 23 Mar 2005 09:41:21 -0700
To: Jerrold Leichter <jerrold.leichter@xxxxxx>
CC: R.A. Hettinga <rah@xxxxxxxx>,  cryptography@xxxxxxxx
Jerrold Leichter wrote:
That's fine for *describing* the system, and useful for analyzing its usability or acceptability. But it's not the whole story.

3-factor authentication paradigm obviously doesn't take into account whether the authentication material is treated as a secret or a shared-secret i.e. both biometrics and something you know can be implemented as either secret or shared-secret .... shared-secret tends to have copies of the authentication material in the possession of the relying party ... while "secret" tends to be an infrastructure where the relying-party can infer the existance of the "secret" by other characteristics. it is one of the reasons that the x9.84 biometric standard goes to great deal of description when biometrics are implemented as shared-secrets ... with the biometric templates stored at a central site.

3-factor authentication paradigm obviously also doesn't cover whether the authentication is direct fact-to-face or that the relying party is infering authentication taking place by the existance of other kinds of evidence. for instance, a relying party validating a digital signature with a public key will infer that the other party is in possession of the corresponding private key. the relying party may not have direct knowledge of the other party being in possession of the corresponding private key ... the relying party just infers it from the validation of a digital signature with the public key.

which then takes us back to your original response:
This is a rather bizarre way of defining things. Something you have is a physical object. On the one hand, any physical object can be copied to an arbitrary degree of precision; on the other hand, no two physical objects are *identical*. So a distinction based on whether a replacement is "identical" to the original gets you nowhere.

ref:
https://www.garlic.com/~lynn/aadsm19.htm#2 Do you Need a Digital ID?
or
http://www.mail-archive.com/cryptography%40metzdowd.com/msg03734.html

3-factor authentication paradigm obviously also doesn't cover all the sort of business rules that allow a relying party to infer something to be true ... even when they don't have direct evidence that it is true aka for a public/private key infrastructure where the relying party normally is inferring that the private key owner has in fact attempted to consistantly and reliably maintained the confidentiality and privacy of the private key and therefor its usefullness as part of any 3-factor authentication paradigm.

3-factor authentication paradigm might also help people designing and/or analysing authentication infrastructures. something you know operations may be some what more vulnerable to electronic sniffing, phishing, and/or information harvesting attacks. something you have hopefully are more resistant to electronic sniffing, phishing, and/or information harvesting attacks ... although the transmission of static data in non-face-to-face operations that allow the relying party to infer the possession of the something you have has been shown to be extremely vulnerable to skimming attacks (that enable the manufactur of counterfeit magstripe plastic cards). Obviously sniffing and skimming exploits involve very similar threat model.

One application would be to choose a multi-factor authentication implementation where the different factors represent countermeasure to different threats. A multi-factor authentication implementation, where the different factors are vulnerable to the same threats, doesn't provide a great deal of additional security. However, there are obviously a lot of variouscharactistics like

a difficult human factors has been the issue of something you know shared-secrets. shared-secret pin/passwords have had two kinds of guidelines 1) make it hard to guess (which tends to make it difficult to memorize) 2) different shared-secret for every security domain (where most institutions viewed that they were the only security domain, but in reality many people now are faced with scores of different security domains with scores of extremely difficult to remember shared-secrets).

lots of past posts on threats, vulnerabilities, exploits
https://www.garlic.com/~lynn/subintegrity.html#fraud
and lots of 3-factor authentication posts:
https://www.garlic.com/~lynn/subintegrity.html#3factor
and various past posts on general subject of designing high-assurance systems
https://www.garlic.com/~lynn/subintegrity.html#assurance

we have somewhat viewed assurance and high-availability as similar ... where a system needs to be resistant to all kinds of failures ... regardless of whether they were failures due to attacks/exploits or just plain simple failures. it is part of building real, industrial strength infrastructures .... misc. posts on our high-availability project/product
https://www.garlic.com/~lynn/subtopic.html#hacmp

i have some ancient archived threads about (remote) 2-factor authentication where plastic card is used with biometrics in place of pin/password ... and the counter-argument was that they could show biometrics was easier to counterfeit than pin/password .... ignoring the fact that 30 percent of the audience that biometrics were being offered to, routinely wrote their pin on their plastic card. it wasn't part of the institutional design. Futhermore, the issue of having a 2nd factor (pin/password or biometric) was suposedly a countermeasure for the lost/stolen card threat. It was fairly trivial to show (regardless of the theoritical strength of the particular biometrics versus an ideal pin/password) that it would be more difficult to counterfeit the biometrics than it would be for an criminal to utilize a pin/password written on a lost/stolen card. ... refs:
https://www.garlic.com/~lynn/99.html#165 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/aadsm10.htm#bio2 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
https://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002g.html#72 Biometrics not yet good enough?
https://www.garlic.com/~lynn/2002h.html#6 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002h.html#8 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002o.html#62 Certificate Authority: Industry vs. Government
https://www.garlic.com/~lynn/2002o.html#63 Certificate Authority: Industry vs. Government
https://www.garlic.com/~lynn/2002o.html#64 smartcard+fingerprint
https://www.garlic.com/~lynn/2002o.html#65 smartcard+fingerprint
https://www.garlic.com/~lynn/2003o.html#44 Biometrics

Do You Need a Digital ID?

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Do You Need a Digital ID?
Date: Wed, 23 Mar 2005 13:57:13 -0700
To: Jerrold Leichter <jerrold.leichter@xxxxxxxx>
CC: R.A. Hettinga <rah@xxxxxxxx>, cryptography@xxxxxxxx
Anne & Lynn Wheeler wrote:
3-factor authentication paradigm obviously also doesn't cover whether the authentication is direct fact-to-face or that the relying party is infering authentication taking place by the existance of other kinds of evidence. for instance, a relying party validating a digital signature with a public key will infer that the other party is in possession of the corresponding private key. the relying party may not have direct

i.e.
https://www.garlic.com/~lynn/aadsm19.htm#5 Do You Need a Digital ID?

one of the possible side-effects of applying 3-factor authentication paradigm ... and observing that
  1. the verification of a digital signature is just a method of inferring the possession of a specific private key
  2. the possession of a private key obviously (theoretically possible, but i know of not instances of people memorizing private keys as part of a deployed authentication infrastructure) isn't something you know authentication and a private key isn't something you are authentication ... leaving it to be something you have authentication (aka in your possession)
  3. private keys in their simplest form are just electronic bits that are relatively easy to copy
then in order for a private key to be useful in a something you have authentication, it follows fairly staight-forwardly that significant security procedures and countermeasures are required to prevent such copying (in order to provide some level of assurance that the assumed entity is consistantly and uniquely in possession of the specific private key).

JIE - Contracts in Cyberspace

Refed: **, - **, - **, - ** 
From: lynn@xxxxxxxx
Date: Sun, 3 Apr 2005 14:36
Subject: JIE - Contracts in Cyberspace
MailingList: Financial Cryptography
re:
http://www.financialcryptography.com/mt/archives/000429.html

some recent posts on public key operations

TLS-certificates and interoperability-issues sendmail/Exchange/postfix
https://www.garlic.com/~lynn/2005e.html#45

xml-security vs. native security
https://www.garlic.com/~lynn/2005e.html#38
https://www.garlic.com/~lynn/2005e.html#39
https://www.garlic.com/~lynn/2005e.html#40
https://www.garlic.com/~lynn/2005e.html#41
https://www.garlic.com/~lynn/2005e.html#42

PKI: the end
https://www.garlic.com/~lynn/2005e.html#22
https://www.garlic.com/~lynn/2005e.html#24
https://www.garlic.com/~lynn/2005e.html#25
https://www.garlic.com/~lynn/2005e.html#26
https://www.garlic.com/~lynn/2005e.html#27

there is the issue of possible semantic confusion with the term "digital signature" containing the word "signature" and possibly implying something related to human signature. digital signature basically provides
  1. indication of whether message has been altered
  2. from 3-factor authentication, the validation of a digital signature implies that the originator had access to and used a specific private key (aka something you have authentication).
typically, a human signature indicates that somebody has viewed, read, understood, agreed, approved, and and/or authorized something .... none of which is implied by the standard digital signature process.

in fact, some number of digital signature based authentication schemes have a server sending random data (that is never viewed) for digital signature (authentication, random data as countermeasure against replay attack).

if the same digital signature mechanism were to be used to also imply human signatures ... then a possible attack on the infrastructure would be to transmit a valid document under the guise of random data (in an authentication protocol) for digital signature.

GeoTrust says existing PKI practices are worthless

Refed: **, - **, - ** 
From: lynn@xxxxxxxx
Date: Tues, April 12, 2005 21:51
Subject: GeoTrust says existing PKI practices are worthless
MailingList: Financial Cryptography
re:
http://www.financialcryptography.com/mt/archives/000441.html

somewhat related posting on the subject earlier today:
https://www.garlic.com/~lynn/2005f.html#20

part of the issue with generalized 3rd party certification authorities ... is what should they go about certifying (and putting into a certificate) that might be of some use for future relying parties (hoping to hit on sufficient information that relying parties might find of use and value).

in the early 90s ... there was the idea of x.509 identity certificates. however it wasn't necessarily known what all future relying parties might find of use ... so there was a tendency to put more and more information in, grossly overloading certificates with privacy information.

in the mid-90s ... there started to be some awareness that such certificates represented extreme privacy and liability issues ... and there was some retrenchment to relying-party-only certificates. however, it is trivial to show that relying-party-only certificates are redundant and superfluous
https://www.garlic.com/~lynn/subpubkey.html#rpo

finally there is the whole issue that the original digital certificates design point were for offline relying parties that had no previous contact with the originating party and had no recourse to any (other) information about the originating party (other than what was provided by a possible digital certificate ... i.e. the paper letters of credit paradigm from the sailing ship days).

that market niche is rapidly disappearing in the pervasive and ubiquitous online world.

what is primarily left are the no-value business processes that can't justify the higher quality and more valuable online, real-time information ... and resort to stale, static offline digital certificates (as being less expensive). however, no-value business processes can't hardly justify the expenses associated with any high assurance and high integrity certification processes.

PKI News

From: lynn@xxxxxxxx
Date: Sun, 24 Apr 2005 11:36
Subject: PKI News
MailingList: Financial Cryptography
re:
http://www.financialcryptography.com/mt/archives/000445.html

there is my standard refrain ... there are normal business process/contracts have relying party paying (and/or with contracts) with certification authorities.

in the TTP business model ... the key owners are paying the TTP/CAs and not the relying parties ... even tho it is the relying parties that are depending on the TTP/CA activity. As a result there is no contractual and/or other legal obligation that the TTP/CA has done anyhting for the relying party. an issue with most TTP/CA business model is that it is inconsistant with most standard business operations (i.e. the people dependent on TTP/CA operation, aren't paying for TTP/CA operation).

Of course the other issue is with the digital certificates which were devised as a solution for the offline email model of the late 70s and early 80s ... sepcifically where the receiving party had no previour contact and/or communication with the sending party ... and had no other means of establishing the bonifides of the sender in real time. This target environment was never very significant to begin with and has gotten much smaller in the interim.

various and sundry posts about SSL certs
https://www.garlic.com/~lynn/subpubkey.html#sslcert

misc. posts about certificate-less operation
https://www.garlic.com/~lynn/subpubkey.html#certless

recent thread in comp.security.misc on "what is a Certificate"
https://www.garlic.com/~lynn/2005g.html#0
https://www.garlic.com/~lynn/2005g.html#1
https://www.garlic.com/~lynn/2005g.html#3

Security as a "Consumer Choice" model or as a sales (SANS) model?

Refed: **, - **, - **, - **, - **, - **, - ** 
From: lynn@xxxxxxxx
Date: Tue, 3 May 2005 09:40 AM
Subject: Security as a "Consumer Choice" model or as a sales (SANS) model?
MailingList: Financial Cryptography
re:
http://www.financialcryptography.com/mt/archives/000455.html

i've periodically made reference to situation being at the stage of the automobile industry in the 70s or possibly even the 60s aftermarket seatbelt stage ... a recent comment that kicked off a slew of followup comparisons
https://www.garlic.com/~lynn/2005g.html#7

old reference that it may possibly require regulatory compliance
https://www.garlic.com/~lynn/aepay3.htm#riskm

some recent news items:

Sarbanes Oxley for IT security?
http://www.theregister.co.uk/2005/05/03/sarbanes_oxley_for_it_security/
Business Inaction Could Lead to Cybersecurity Law
http://www.eweek.com/article2/0,1759,1791566,00.asp
Inaction Could Lead to Cybersecurity Law
http://www.reuters.com/newsArticle.jhtml?storyID=8353808

EuroPKI 2005 - Call for Participation

Refed: **, - **, - **, - **, - ** 
From: Lynn Wheeler
Date: 05/18/05 12:40 PM
To: David Chadwick <d.w.chadwick@xxxxxxxx>
cc: PKIX <ietf-pkix@xxxxxxxx>
Subject: Re: EuroPKI 2005 - Call for Participation
at 8:14 am 5/18/05, d.w.chadwick@salford.ac.uk wrote:
CALL FOR PARTICIPATION

The EuroPKI 2005 Conference will be held in Canterbury, England, 30 June - 1 July 2005.

Registration is now open. See

http://sec.cs.kent.ac.uk/europki2005/registration.shtml

Early registration closes on 1 June, so book now to secure your place.

The Keynote Speech will be given by Dr Carlise Adams, and is entitled "PKI: Views from the Dispassionate I", in which he will present his thoughts on why PKI has been available as an authentication technology for many years now, but has only enjoyed large-scale success in fairly limited contexts to date. He will also present his thoughts on the possible future(s) of this technology, with emphasis on the major factors hindering adoption and some potential directions for future research in these areas.

from 3-factor authentication paradigm
https://www.garlic.com/~lynn/subintegrity.html#3factor that verification of a digital signature with a public key is a form of something you have authentication ... i.e. the subject has access and use of the corresponding private key.

note, however, it has seemed that the majority of certification authorities (mainstay of most formal PKIs) are embroiled in identification issues, not authentication ... aka the certification binding of some information to a public key (and the production of the resulting certificate).

i've frequently claimed that this paradigm was disigned to address the offline email scenario from the early 80s ... where the recipient had absolutely no recourse to information about an otherwise anomomous sender that the recipient never had any previous communication with (aka the letters of credit model from the sailing ship days).

the recipient, dialed their local electronic postoffice, exchanged email, and then hungup. the recipient then found themself with an email from a total stranger, there had never been any prior communication, and the recipient lack any means for discoverying any information about the stranger.

the early 90s saw x.509 identification certificates. however, there was some tendency by certification authorities looking at significantly overloading such certificates with enormous amounts of personal information (not really being able to predict the future about what relying parties and/or what business processes might be targets for such certificates, and therefor not reliably being able to predict what relying parties might expect in the way of identification information).

in the mid-90s some of the institutions (like financial) industry) ... looking at such identity certificates realized that they represented enormous privacy and liability issues and you saw some retrenchment to relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

these certificates frequently contained little more certified information than some form of account number bound to a public key. however, it was trivial to show that such reply-party-only certificates not only violated the original certiicate design point (total stranger communicating for the first time with a offline relying-party that had no other recourse to information about the originator), but also were redundant and superfluous (aka the relying-party having registered the public key and issued the relying-party-only certificate ... would have a superset of every bit of information contained in a certificate ... including the public key).

in the financial industry situation ... where the redundant and superfluous certificates were being targeted at payment transactions ... aka a consumer would create a payment transaction, digitally signed it and transmit the transaction, the digital signature, and the reply-party-only certificate back to the issuing institution. Not only did the relying-party (destination of the payment transaction) already have access to a superset of the information contained in a redundant and superfluous digital certificate ... but it turns out that the nominal payment transaction size is on the order of 60-80 bytes. The typical redundant and superfluous relying-party-only certificate from the period could be on the order of 4k-12k bytes. So not only were the relying-party-only certificates redundant and superfluous, but in such situations they also represented a factor of 100 times payload bloat.

It is actually possible to deploy authentication infrastructures that use digital signature verification
https://www.garlic.com/~lynn/subpubkey.html#certless

that avoid getting embroiled in the identification issues that seem to accompany many PKI deployments.

EuroPKI 2005 - Call for Participation

From: Lynn Wheeler
Date: 05/19/05 10:19 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "David Chadwick" <d.w.chadwick@xxxxxxxx>,
     PKIX <ietf-pkix@xxxxxxxx>
Subject: Re: EuroPKI 2005 - Call for Participation
at 3:25pm 5/18/05, anders rundgen wrote:
The problem is that none these systems are supported by PCs as this industry have shown to be incapable of defining a mobile, secure container. Esoteric explanations may be more fun to talk about but they have little validity as ID TTP liability etc.has not been put to test in any major way yet. non-repudiation, has probably not happened once!

BTW, maybe you guys should begin to look on the next ID "revolution" Microsoft's InfoCard stuff?

slightly related thread in
https://www.garlic.com/~lynn/2005h.html#36 Security via hardware?

includes some reference to patent activity on authentication token integrity.

and a press release from today
http://www.gamesindustry.biz/press_release.php?aid=9008

an aads offering
https://www.garlic.com/~lynn/x959.html#aads

a couple minor other postings in somewhat related threads:
https://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom

What happened with the session fixation bug?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 20 May 2005 22:07:40 -0600
Subject: Re: What happened with the session fixation bug?
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx,  cypherpunks@xxxxxxxx
James A. Donald wrote:
PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.

all of them may have been less than expected ... the comoningly recognized SSL certificate issuers (that have their public key preloaded into common browsers) sell their certificates and have processes that look at whether you have a validly registered corporation. For most practical purposes this has been for e-commerce sites and the objective for the majority is protecting credit card numbers.

however, the reported exploits .... and what seem to represent a significantly larger ROI (fraud for effort invested) is to harvest the merchant transaction file (containing all the accumulated transaction information that would have taken months of listening to gather) ... aka it is much easier to let the merchant gather and organize all the information on behalf of the crook. slightly related posting ...
https://www.garlic.com/~lynn/2001h.html#61 Security proportional to risk

the original ssl e-commerce work
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

had the user typing in the merchant webserver URL as a HTTPS session from the start and then it would check the domain name in the returned certificate (after all the digital signature gorp) with the domain name typed in. this is rarely if ever happening ... the common justification is running SSL during the shopping experience cuts the thruput by 80-90 percent. as a result, SSL is typically saved for the "check-out" button.

so lets say you have been redirected to a fraudulent site and don't know it because the SSL domain name stuff hasn't been done yet. then comes time to do the check-out button. if it is a fraudulent site ... and since the crooks would then be supplying the URL with the check-out button ... the crooks are likely to have obtained a valid SSL certificate for some domain and that domain will match whatever the check-out button supplies.

random past ssl certificate posts
https://www.garlic.com/~lynn/subpubkey.html#sslcert

crooks are capable of setting up valid dummy front companies ... it isn't a very large effort.

most of what the CA TTPs do when they are verifying stuff ... is that the person applying for a certificate is in some way associated with a valid company that they claim to be associated with.

then the CA TTPs check with the domain name infrastructure to see if the corporation that they just checked on ... is the same one listed as the owner of the subject domain name (modulo the issue that there can be a common company name, a DBA company name, and a legal company name ... all for the same corporation and all completely different names ... you sometimes will see this in credit card statements where the store-front name and the company name on the statement are different).

As observed, one of the things SSL was for a countermeasure for integrity problems in the domain name infrastructure involving domain name hijacking (where the mapping of the domain name to an ip-address was altered to be a different ip-address, potentially fraudulent website).

However, there have been more sophisticated domain name hijackings that have occured where the domain name infrastructure records had both the name of the corporate owner as well as the ip-address altered. In this more sophisticated form, a crook with a perfectly valid dummy front corporation ... that has done the more sophisticated form of domain name hijacking ... could apply for a perfectly valid SSL domain name certificate ... and pass all the tests.

in any case, that was my perception of what we were doing with SSL ten years ago.

PKI is slightly different. One of the reasons that we coined the term certificate manufacturing was to try and differentiate what was commonly being referred to as PKI ... and what SSL domain name certificate stuff was actually doing.

Note that there has been a proposal to somewhat address the more complex form of domain name hijacking (both the company name take-over as well as the ip-address take-over) ... which involves having domain name owners register a public key when they get a domain name. Then all future correspondance with the domain name infrastructure is digitally signed ... which then can be verified with the onfile public key. as a side note ... this is a non-PKI, certificate-less implementation of public key. In any case, with authenticated correspondance ... there supposedly is less chance of domain name hijacking occuring.
https://www.garlic.com/~lynn/subpubkey.html#certless

This has somewhat been supported by the CA SSL domain name certification industry. The have a complex, expensive, and error-prone identification process to try to establish a valid corporation. And even then they are at the mercy of whether the company name listed in the domain name infrastructure is actually the correct company (i.e. their whole infrastructure otherwise is useless).

The other advantage ... is that the Certification Authority can require that SSL domain name certificate applications also be digitally signed. Then the CA can turn an expensive, time-consuming, and error-prone identification process into a much simpler, cheaper, and reliable authentication process ... by retrieving the onfile public key from the domain name infrastructure for verifying the applicants digital signature (again note that this is a non-PKI, certificate-less implementation that they would use as the trust basis for the whole SSL domain name certificate operation).

There is some slight catch-22 to this for the SSL domain name certificate business. First off, improving the integrity of the domain name infrastructure for the Certification Authority industry ... would also improve the integrity for everybody ... somewhat mitigating one of the original supposed requirements for having SSL domain name certificates in the first place. The other is that if the SSL certification industry found it viable to base their trust infrastructure on the certificate-less, onfile public keys at the domain name infrastructure... it might be possible that the rest of the world might find them acceptable also. One could imagine a slightly modified SSL process where the public key didn't come from a certificate ... but was an onfile certificate-less public key retrieved directly from the domain name infrastructure (in much the same way the CA industry has proposed doing).

To live in interesting times - open Identity systems

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: lynn@xxxxxxxx
Date: May 21, 2005 10:30 AM
Subject: To live in interesting times - open Identity systems
MailingList: Financial Cryptography
re:
https://www.financialcryptography.com/mt/archives/000474.htm

there is a somewhat related issue that could be raised regarding person-centric tokens vis-a-vis institution-centric issued tokens. the current infrastructure tends to be institutional-centric and there is a different, unique token (actually potentially several) per institution. periodically these are referred to as identity tokens ... but being institutionally-centric they more often actually are autentication tokens (a one-to-one mapping for a specific domain).

the opposite extreme is if institutional-centric tokens take off and you are issued one or more in lieu of every pin/password, every physical key, and every magstripe card ... that you currently possesss or utilize. this potentially results in at least scores of tokens per individual (if not hundreds).

sort of the opposite would be person-centric token paradogm. a person would have one or more tokens that they own ... and they would have the discretion to register the token of their choice with institutions as the authentication token for interactions with that institution (transactions, access, open the door, etc).

most institutional interactions are looking for a authentication one-to-one mapping for autherization purposes (are you the authorized entity for performing transactions on a specific account ... or are you an authorized entity allowed to open a specific door).

a lot of confusion occurs when identification is mistaken for authentication. authentication wants to know if you are authorized to do something .... w/o needing to actually pick out what person from possibly millions you might actually happen to be (identification). i can assert that i authorized to use a certain account or open a certain door and provide authentication information to back up that assertion. that doesn't require me to identity myself ... just to authenticate myself.

this was one of the mistakes of the x.509 identity certificates from the early 90s. part of the issue was that certification authorities weren't confident that they could predict what information about you that might be required by some unknown, random relying-party at some point in the future. so there was a tendency to believe that x.509 identity certificates should be grossly overloaded with excessive amounts of personal information.

some number of institutions in the mid-90s came to the realization that x.509 identity certificiates, grossly overloaded with excessive amounts of personal information represented significant liability and privacy issues. at that point you saw some retrenchment into relying-party-only certificates ... basically containing some sort of index or key that could be used to lookup a specific record in a database (aka an account number or a userid) ... which was, in turn bound to a public key. however, a typical relying-party interaction involved some sort of digitally signed message that also contained the record index. It was at this point that you could demonstrate that relying-party-only certificates were redundant and superfluous since the relying-party could retrieve the indicated record and utilize the onfile public key for verifying the digital signature w/o ever having to resort to use of the digital certificate.

numerous past postings on relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

a couple past postings on person/institutional centric issues:
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?

Loss Expectancy in NPV calculations

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: lynn@xxxxxxxx
Date: May 27, 2005 07:47 PM
Subject: Loss Expectancy in NPV calculations
MailingList: Financial Cryptography
ref:
https://www.financialcryptography.com/mt/archives/000477.html

You find this sort of stuff also under parameterised risk management ... especially in insurance industry (or self-insured operations) attempting to calculate costs against all possible risk exposures. talk to some corporate risk managers ... they view life thru these sort of glasses all the time.

a couple past mentions on the thread between information security and risk management:
https://www.garlic.com/~lynn/aepay3.htm#riskm
https://www.garlic.com/~lynn/aepay3.htm#riskaads

and then security proportional to risk:
https://www.garlic.com/~lynn/2001h.html#61

somewhat related scenario were risk manager (related to calculating insurance premiums) comments on certificate-based infrastructures vis-a-vis certificate-less, online-based infrastructure.
https://www.garlic.com/~lynn/subpubkey.html#certless

the issue was how many places could a subject use their certificate in value related transactions ... if the certification authority was standing behind such a certifcate (using the letter of credit scenario from the sailing ship days) ... what might be the avg. value at risk and how many such events might there be creating risk exposure to the certifying institution.

the counter example is the current online payment card scenario ... whether they maintain an open-to-buy for the subjects they certify ... and every value transaction aggregates against the subject's open-to-buy. at all times, the certifying institution has real-time management on the subject's open-to-buy (and therefor the actual risk exposure to the institution). open-to-buy ceiling (aka credit limit) may undergo numerous adjustments as the risk taking institution updates its expected liabilities.

Loss Expectancy in NPV calculations

From: lynn@xxxxxxxx
Date: May 27, 2005 11:23 PM
Subject: Loss Expectancy in NPV calculations
MailingList: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm19.htm#15

oops that should have been "aepay3.htm" instead of "aadsm3.htm" ... i.e.
https://www.garlic.com/~lynn/aepay3.htm#riskm
https://www.garlic.com/~lynn/aepay3.htm#riskaads

... while i'm posting ... i might also point out that the situation has some similarities to performance bottleneck ... the old adage ... that when you "elimiante" one ... there is always another waiting right behind

I had done a lot of kernel performance rewrites as an undergraduate (sometimes getting a 100:1 improvement in cpu cycles), inventing page replacement algorithms and scheduling algorithms .... which were being shipped in commercial products ... recent post that is somewhat related to security issues (as an undergraduate being responsible for resource management algorithms ... it was therefor my responsibility to address low-bandwidth information security leakage issues)
https://www.garlic.com/~lynn/2005i.html#15

in the later half of the 70, i started pointing out the significant shift from systems performance thruput being cpu and memory constrained to being i/o constrained. i made some claim that the relative system disk thruput had declined by a factor of ten over a period of years.

the disk division didn't like it and assigned their performance modeling organization to refute the claim. after a couple months, the group came back and said that i had slightly understated the problem.
https://www.garlic.com/~lynn/93.html#31

memory and cpu had increased by approx. a factor of 50 while disk arm performance had increased by a factor of 3-5 (resulting in a relative system thruput deline of at least 10 times).

What happened with the session fixation bug?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: What happened with the session fixation bug?
Date: Tue, 31 May 2005 11:55:37 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx,  cypherpunks@xxxxxxxx
James A. Donald wrote:
PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.

asymmetric cryptography has a pair of keys ... the other of the key-pair decodes what has been encoding by one of them. a business process was defined using this technology where one of the key-pair is designated as public ... and freely distributed and the other of the key-pair is designated as confidential and never divulaged. an authentication business process was defined using public/private business process called digital signature .... where a hash of a message is taken and encoded with the private key. the recipient can recompute the hash of the received message and compare it to the digital signature that has been decoded with the corresponding public key. this catches whether the message has been altered and from 3-factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor implies something you have authentication ... i.e. the originator has access and use of the corresponding private key.

PKI was somewhat targeted at the offline email model of the early 80s; the relying party dials up their (electronic) post office, exchanges email, and hangs up. They then may be dealing with first time correspondance from a total stranger with no (offline or online) recourse for determining information about the sender. Relying parties could be seeded with trusted public key repository of trusted third party certification authorities. Stangers could be issued "certificates" (digitally signed by one of these certification authorities) containing informoation about themselves bound to their public key. Email recipients in the offline email days of the early 80s ... could now of source of information regarding first time communication from total strangers (sort of the "letters of credit" model from the sailing ship days).

we were asked to work this small client/server startup in menlo park
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

that wanted to do payments on something they called a commerce server. In the year we worked with them ... they moved from menlo park to mountain view and changed their name (trivia question ... who previously had the rights to their new name? also what large corporate entity was providing most of the funding for the commerce sever?). some topic drift ... recent postings referencing this original e-commerce work as an example of service oriented architecture (SOA):
https://www.garlic.com/~lynn/2005i.html#42
https://www.garlic.com/~lynn/2005i.html#43

they had this technology called SSL which was configured at addressing two issues: a) is the webserver that the user had indicated to the browser ... the actual webserver the browser was talking to and b) encryption of the transmitted information.

SSL digital certificates would be issued
https://www.garlic.com/~lynn/subpubkey.html#sslcert

which would contain the domain name of the webserver bound to their public key. the browsers would have trusted public key repository seeded with the public keys of some number of trusted third party certification authorities. the browser SSL process would compare the domain name indicated by the user to the domain name in the digital certificate (after validating the certificate).

(at least) two (other) kinds of vulnerabilities/exploits have shown up.
  1. in the name of convenience, the browsers have significantly obfuscated the certificate operation from the end-user. attackers have devised ways for the end-users to indicate incorrect webservers ... which the browser SSL process (if it is even invoked) will then gladly validate as the webserver the user indicated.
  2. a perceived issue (with knowing that the webserver that a browser is talking to is the webserver the user indicated) were integrity issues in the domain name infrastructure. however, as part of doing this consulting with this small client/server startup ... we also had to do detailed end-to-end business process due diligence on some number of these certification authorities. it turns out that a certification authority typically has to check with the authoritative agency for the information they are certifying. the authoritative agency for domain name ownership is the domain name infrastructure ... the very institution that there are integrity questions giving rise to the requirement for SSL domain name server certificates.
In the second vulnerability, the certification authority industry is somewhat backing a proposal that when somebody registers a domain name with the domain name infrastructure ... they also register their public key. then in future communication with the domain name infrastructure, they digitally sign the communication. the domain name infrastructure then can validate the digital signature using the (certificate-less) public key onfile for that domain.
https://www.garlic.com/~lynn/subpubkey.html#certless

This supposedly improves the integrity of the communication between the domain name owner and the domain name infrastructure .... mitigating some possible domain name hijacking exploits (where some other organization becomes recorded as the domain name owner).

It turns out that the certification authority industry also has an issue. When somebody makes an application for an SSL domain name certificate, they need to supply a bunch of identification information. This is so the certification authority can perform the expensive, time-consuming and error-prone identification process ... and then do the same with the information on file at the domain name infrastructure as to the owner of the domain name ... and then see if the two domain name owner identifications appear to match. Having an on-file public key for the domain name owner ... the certification authority industry can also require that an SSL domain name applicant, digitally sign their application. Then the certification authority can retrieve the onfile (certificate-less) public key and change an expensive, error-prone, and time-consuming identification process into a simple and more reliable authentication process (by retrieving the onfile public key and validating the digital signature).

From an e-commerce perspective ... the SSL process was to protect against credit card information havesting for use in fraudulent transactions. However, the major vulnerability/exploit before SSL and after the introduction of SSL ... wasn't against credit card information in flight ... but against huge repositories of credit card information (information at rest). It was much easier for the crooks to steal the information already collected in huge repositories than go to the effort of evesdropping the information inflight and creating their own repositories (fraud return-on-investment, much bigger benefit in stealing large repositories of already collected and organized information). related reference regarding security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

the financial standards working group, x9a10 was given the task of preserving the integrity of the financial infrastructure for all retail payments (as well as some number of other requirements) for x9.59 standard
https://www.garlic.com/~lynn/x959.html#x959

so some earlier work on PKI-oriented protection for retail payments involved digitally signed transaction oriented protocol with attached digital certificates.

in the early 90s, there was some work on x.509 identity certificates. however, there was some issues with ceritifcation authorities predicting exactly what information might be needed by unknown future relying parties ... and so there was some direction to grossly overload these certificates with excessive amounts of personal information. In the mid-90s, some number of institutions were starting to realize that such overloaded repositories of excessive personal information representing significant liability and privacy issues. As a result you saw some retrenchment to relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

these were digital certificates that basically contained some kind of database record locator (like an account number) bound to a public key (the database record contained all the real information). however, it became trivial to demonstrate that such relying-party-only certificates were redundant and superfluous. This was, in part, because they violated the original design point for certificates ... the relying party not having any other recourse to the necessary information. By definition if all the information was in a relying-party's database ... then by definition the certificate was redundant and superfluous.

in this later part of the mid-90s payment scene, these relying-party-only certificates were on the order of 4k-12k bytes. It turns out that a typical retail payment message is 60-80 bytes. Not only were the stale, static, relying-party-only certificates redundant and superfluous ... but they also would contribute to enormous payload bloat (on the order of one hundred times).

the other problem with the relying-party-only, redundant and superfluous, stale, static, enormous payload-bloat digital certificate based infrastructure ... were that they effectively were targeted only at protecting credit card information in-flight ... something that SSL was already doing. They were providing no countermeasure for the major vulnerability to the data at rest. the information at rest was still vulnerable (and was the major exploit already with or w/o SSL)

So one of the things in the x9a10 financial standards working group was to do a treat and vulnerability analysis ... and design something that could preserve the integrity of the financial infrastructure for all retail payments (credit, debit, stored-value, online, offline, pos, etc).

X9A10 defined a light-weight digitally signed transaction that wouldn't contribute to the enormous payload bloat of the stale, static, redundant and superfluous certificate-based infrastructures.

Another issue was the analysis demonstrated that the major treat and vulnerability was to data at rest. So for X9.59, a business rule was defined ...
for account numbers used for X9.59 transactions ... only authenticated transactions (verified digital signatures) could be authorized.

An x9.59 transaction was digitally signed, and the relying party could use an on-file public key to validate the digital signature .... showing the transaction wasn't modified in transit and providing something you have authentication as to the originator (they had access and use of the corresponding private key). furthermore, evesdropping of the transaction in flight ... and/or harvesting the large transaction databases (information at rest) wouldn't yield information for the crook to perform a fraudulent transaction. the current exploits where knowledge from an existing transaction is sufficient to generate fraudulent transaction has gone away ... for vulnerabilities involving both data in flight as well as data at rest.

The issue wasn't that SSL being designed to protect data-in-flight ... the issue was that the major threat/vulnerability has been to data-at-rest ... so to some extent, SSL (and the various other countermeasures to data-in-flight vulnerabilities) wasn't responding to the major threats. To some extent, e-commerce/internet was opening a theoritical, new vulnerabilities (data-in-flight) compared to the non-internet world ... and so SSL was somewhat theoretically demonstrating that e-commerce/internet use wouldn't make the situation any worse.

Recent studies have indicated that at least 77% of the id theft exploits have involved insiders (supporting the long standing premise that the majority of fraud is by insiders). The introduction of e-commerce and internet have created new avenues for attacking data-at-rest by outsiders. As a result, e-commerce/internet potential threats to data-at-rest has contributed to obfuscating responsible insiders in cases of exploits against data-at-rest.

Citibank discloses private information to improve security

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Citibank discloses private information to improve security
Date: Tue, 31 May 2005 13:23:34 -0600
To: Adam Fields <cryptography23094893@xxxxxxxx>
CC: James A. Donald <jamesd@xxxxxxxx>,
    cryptography@xxxxxxxx
Adam Fields wrote:
Moreover, in my experience (as I've mentioned before on this list), noticing an invalid certificate is absolutely useless if the banks won't verify via another channel a) that it changed, b) what the new value is or c) what the old value is.

I've tried. They won't/can't.

one might claim then that a solution is to go to a PGP-like repository of trusted public keys (in addition to and/or in conjunction of typical browser repostiory of trusted certification authority public keys). the URL & public key are loaded into the repository and some out-of-band process is used to establish the "trust" level of the information ... and you are involving the end-user in the trust establishment process.

For convenience ... enable this from bookmark and end-user clicks on trusted URLs. then rather than browser using webserver supplied certificate as part of SSL process, the browser uses the onfile trusted public key for that URL.
https://www.garlic.com/~lynn/subpubkey.html#certless

a threat is social-engineering can convince some number of naive users to do just about anything ... including things like updating a trusted public key repository ... and clicking on email obfuscated URLs (what the email claims to be the URL ... in unrelated to what the URL actually is). a major problem is that a large percentage of the population seems to be extremely naive about trust.

some large amount of the skimming and harvesting related fraud is because of existing authentication paradigms that make extensive use of static data and/or shared-secrets
https://www.garlic.com/~lynn/subintegrity.html#secrets

a countermeasure could be public key and digital signature verification based authentication. extensive use of file-based private keys make them vulnerable to harvesting by viruses ... but also vulnerable to social engineering attacks getting naive users to divulge contents of private key files.

a countermeasure might be hardware tokens where the private key can't be divulged ... even by the token owner. however, social engineering attacks can still get naive users to perform fraudulent transactions on behalf of crooks (even in hardware token based infrastructures). however, the percentage of the population vulnerabile to such attacks might go down as complexity of the social engineering and/or the awareness of the user population goes up.

"SSL stops credit card sniffing" is a correlation/causality myth

Refed: **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 31 May 2005 14:05:51 -0600
Subject: Re: "SSL stops credit card sniffing" is a correlation/causality myth
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Ian G <iang@xxxxxxxx>, "James A. Donald" <jamesd@xxxxxxxx>,
cryptography@xxxxxxxx,  cypherpunks@xxxxxxxx
Steven M. Bellovin wrote:
Given the prevalance of password sniffers as early as 1993, and given that credit card number sniffing is technically easier -- credit card numbers will tend to be in a single packet, and comprise a self-checking string, I stand by my statement.

the major exploits have involved data-at-rest ... not data-in-flight. internet credit card sniffing can be easier than password sniffing .... but that doesn't mean that the fraud cost/benefit ratio is better than harvesting large transaction database files. you could possibly conjecture password sniffing enabling compromise/exploits of data-at-rest ... quick in&out and may have months worth of transaction information all nicely organized.
https://www.garlic.com/~lynn/2001h.html#61 Security proportional to risk

to large extent SSL was used to show that internet/e-commerce wouldn't result in the theoritical sniffing making things worse (as opposed to addressing the major fraud vulnerability & threat).

internet/e-commerce did increase the threats & vulnerabilities to the transaction database files (data-at-rest) ... which is were the major threat has been. There has been a proliferation of internet merchants with electronic transaction database files ... where there may be various kinds of internet access to the databases. Even when the prevalent risk to these files has been from insiders ... the possibility of outsider compromise can still obfuscate tracking down who is actually responsible.

Citibank discloses private information to improve security

Refed: **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Citibank discloses private information to improve security
Date: Tue, 31 May 2005 14:31:13 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Adam Fields <cryptography23094893@xxxxxxxx>,
"James A. Donald" <jamesd@xxxxxxxx>, <cryptography@xxxxxxxx>
Steven M. Bellovin wrote:
Bank of America is adopting some new schemes that might help. First, they're asking users to select a picture the user selected at registration time. The theory is presumably that a phishing site won't have the right image for you. Second, you can "register" your computer; if your account is accessed from another computer, additional authentication is demanded, thus rendering a compromised password much less useful.

I think both schemes will help; I doubt that either will stop the problems.

http://www.bankofamerica.com/newsroom/press/press.cfm?PressID=press.20050526.03.htm

but they appear to be vulnerable to MITM-attacks

recent thread
http://seclists.org/lists/fulldisclosure/2005/May/0629.html
http://seclists.org/lists/fulldisclosure/2005/May/0637.html
http://seclists.org/lists/fulldisclosure/2005/May/0639.html
http://seclists.org/lists/fulldisclosure/2005/May/0644.html

Citibank discloses private information to improve security

Refed: **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Citibank discloses private information to improve security
Date: Tue, 31 May 2005 14:33:44 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Adam Fields <cryptography23094893@xxxxxxxx>,
"James A. Donald" <jamesd@xxxxxxxx>, <cryptography@xxxxxxxx>
a couple more URLs

BofA rolls out authentication tools after data breach incident
http://eyeonit.itmanagersjournal.com/article.pl?sid=05/05/27/1816200
Bank of America looks to protect Online users with SiteKey
http://tech.monstersandcritics.com/news/article_1002765.php/Bank_of_America_looks_to_protect_Online_users_with_SiteKey
Payments News: Bank of America Launches SiteKey
http://www.paymentsnews.com/2005/05/bank_of_america.html
Bank of America | Sign up for the SiteKey Service
http://www.bankofamerica.com/privacy/passmark/
Bank of America takes on cyberscams
http://news.com.com/Bank+of+America+takes+on+cyberscams/2100-1029_3-5722035.html
Bank Of America Fights Phishing With New Authentication
http://informationweek.smallbizpipeline.com/news/163701500
Bank of America Announces Industry-Leading Security Feature ...
http://money.cnn.com/services/tickerheadlines/prn/200505261000PR_NEWS_USPR_____CLTH009.htm
Bank of America's SiteKey scrutinized
http://news.com.com/2061-10789_3-5723556.html?part=rss&tag=5723556&subj=news

Citibank discloses private information to improve security

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Citibank discloses private information to improve security
Date: Tue, 31 May 2005 14:59:43 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Adam Fields <cryptography23094893@xxxxxxxx>,
"James A. Donald" <jamesd@xxxxxxxx>, <cryptography@xxxxxxxx>
just for the heck of it ... something today more from the physical world

ATM scams added to GASA's fraud library
http://www.atmmarketplace.com/news_story_23307.htm
CAPE TOWN, South Africa and BROOKINGS, S.D. The ATM Industry Association's Global ATM Security Alliance launched its online library of ATM fraud, according to a news release. The library is part of Cognito, GASA's global ATM crime data management system.

... snip ...

... and
http://www.globalasa.com/

Citibank discloses private information to improve security

Refed: **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Citibank discloses private information to improve security
Date: Tue, 31 May 2005 15:19:38 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: Adam Fields <cryptography23094893@xxxxxxxx>,
"James A. Donald" <jamesd@xxxxxxxx>, <cryptography@xxxxxxxx>
oops, sorry, forgot to include this one

Hong Kong banks to introduce two-factor authentication for online transactions
http://www.finextra.com/fullstory.asp?id=13744
Banks in Hong Kong are set to introduce two-factor authentication services to the country's 2.7 million Internet banking customers next month.

... snip ...

and lots of collected posts on 3-factor authentication paradigm
https://www.garlic.com/~lynn/subintegrity.html#3factor

Citibank discloses private information to improve security

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Citibank discloses private information to improve security
Date: Tue, 31 May 2005 16:43:09 -0600
To: Ed Gerck <edgerck@xxxxxxxx>
CC: Matt Crawford <crawdad@xxxxxxxx>,  cryptography@xxxxxxxxx
Ed Gerck wrote:
Also, in an effort to make their certs more valuable, CAs have made digitally signed messages imply too much -- much more than they warrant or can even represent. There are now all sorts of legal implications tied to PKI signatures, in my opinion largely exagerated and casuistic.

as discussed in numerous non-repudiation posts, dual-use threat posts, and posts about human signatures .... where the human signature implies that the person has read, understood, authorizes, approves, and/or agrees (with what is read and understood) .,...

the validation of a digital signature with a public key implies that the message hasn't been altered since transmission and there is something you have authentication (the originator has access and use of the corresponding private key). the simple validation of a digital signature doesn't carry with it any of the sense of a human signature and/or non-repudiation.

in most business scenarios ... the relying party has previous knowledge and contact with the entity that they are dealing with (making the introduction of PKI digital certificates redundant and superfluous). Furthermore, x.509 identity certificates possibly horribly overloaded with personal information would reprensent significant privacy issues.

i've claimed that in the aads effort
https://www.garlic.com/~lynn/x959.html#aads

not having to be pre-occupied with trying to interest relying parties in digital certificates containing information they already had .... we were more free to concentrate on general threat, risk and vulnerability analysis. for instance, one of the things that a relying party might be really interested in is the integrity of the environment housing a subject's private key (is it in a software file or a hardware token, if a hardware token, what are the characteristics of the hardware token, etc) and the integrity of the environment in which a digital signature was generated.

one possible scenario is that CAs wanted to convince relying parties in the value of the certificates and not distract them with fundamental business integrity issues ... which might have resulted in businesses diverting money to fundamental business integrity items ... rather than spending on redundant and superfluous digital certificates likely containing information that they already had (i.e. having digital certificates would result in magical fu-fu dust being sprinkled over the rest of the infrastructure automagically precluding any such integrity problems?). furthermore they could spread semantic confusion ... somehow implying that because the term digital signature contained the word signature ... it was somehow related to a human signature.

lots of collected past postings related to fraud, exploits. vulernabilities, etc
https://www.garlic.com/~lynn/subintegrity.html#fraud

some number of posts on account number harvesting
https://www.garlic.com/~lynn/subintegrity.html#harvest

Digital signatures have a big problem with meaning

Refed: **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Digital signatures have a big problem with meaning
Date: Wed, 01 Jun 2005 10:37:51 -0600
To: dan@xxxxxxxx
CC: Ian G <iang@xxxxxxxx>,  cryptography@xxxxxxxx
dan@geer.org wrote:
On the one hand a digital signature should matter more the bigger the transaction that it protects. On the other hand, the bigger the transaction the lower the probability that it is between strangers who have no other leverage for recourse.

And, of course, proving anything by way of dueling experts doesn't provide much predictability in a jury system, e.g., OJ Simpson.

the bigger the transaction that the digital signature verifies .... the more the relying party is going to be interested in fundamental integrity issues surrounding the digital signature generation

from 3-factor authentication paradigm
https://www.garlic.com/~lynn/subintegrity.html#3factor simple digital signature verification is basically something you have authentication ... implying that the originator has access to and use of the corresponding private key (in addition to the transaction not having been modified in transit).

fundamental issues surrounding digital signature can be the integrity level of the infrastructure preventing compromise of the private key aka is the private key protected in a software file, is the private key in a hardware token, was the private key generated in a hardware token and can never leave the hardare token. also if it is a hardware token, is a pin/password also required to make the token operate correctly i.e. knowing characteristics of the hardware token, the relying party might be able to infer two-factor authentication and assess the risk/threats involved.

also what is the integrity level of the infrastructure in which the digital signature was generated ... for instance some of the EU finread standard
https://www.garlic.com/~lynn/subintegrity.html#finread

which try and specify the minimum constraints for generation of a digital signature on a financial transaction.

this isn't so much proving anything ... this is risk management ... what is the likelyhood/exposure of a compromise for the relying party ... or security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

standard types of things that you would find at financial institutions and/or insurance institutions.

part of the confusion possibly is because of the extensive deployment of PKI literature ... which tends to focus the attention on the certification process ... as opposed to the integrity of the authentication process. the issue is that for the majority of business operations ... the PKI certification process tends to be duplication of extensive relationship management infrastructures that they already have in use (which tend to be a large superset of typical PKI certification and therefor PKI is redundant and superfluous) ... and there is much less focus on the basic risk, threat and vulnerability issues related directly to the authentcation.

and as i've frequently postulated ... that same may have an interest in creating semantic confusion ... implying that because the term digital signature includes the word signature ... that it somehow bears some relationship to human signatures

Trojan horse attack involving many major Israeli companies, executives

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Trojan horse attack involving many major Israeli companies,  executives
Date: Wed, 01 Jun 2005 12:52:10 -0600
To: herzbea@xxxxxxxx
CC: <cryptography@xxxxxxxx>
Amir Herzberg wrote:
Nicely put, but I think not quite fair. From friends in financial and other companies in the states and otherwise, I hear that Trojans are very common there as well. In fact, based on my biased judgement and limited exposure, my impression is that security practice is much better in Israeli companies - both providers and users of IT - than in comparable companies in most countries. For example, in my 'hall of shame' (link below) you'll find many US and multinational companies which don't protect their login pages properly with SSL (PayPal, Chase, MS, ...). I've found very few Israeli companies, and of the few I've found, two actually acted quickly to fix the problem - which is rare! Most ignored my warning, and few sent me coupons :-) [seriously]

Could it be that such problems are more often covered-up in other countries? Or maybe that the stronger awareness in Israel also implies more attackers? I think both conclusions are likely. I also think that this exposure will further increase awareness among Israeli IT managers and developers, and hence improve the security of their systems.

there is the story of the (state side) financial institution that was outsourcing some of its y2k remediation and failed to perform due diligence on the (state side) lowest bidder ... until it was too late and they were faced with having to deploy the software anyway.

one of the spoofs of SSL ... originally it was supposed to be used for the whole shopping experience from the URL the enduser entered, thru shopping, checkout and payment. webservers found that with SSL they took a 80-90% performance hit on their thruput ... so they started saving the use of SSL until checkout and payment. the SSL countermeasure to MITM-attack is that the URL the user entered is checked against the URL in the webserver certificate. However, the URL the users were entering weren't SSL/HTTPS ... they were just standard stuff ... and so there wasn't any countermeasure to MITM-attack.

If the user had gotten to a spoofed MITM site ... they could have done all their shopping and then clicked the checkout button ... which might provide HTTPS/SSL. however, if it was a MITM-spoofed site, it is highly probable that the HTTPS URL provided by the (spoofed site) checkout button was going to match the URL in any transmitted digital certificate. So for all, intents and purposes ... most sites make very little use of https/ssl as countermeasure for MITM-attacks ... simply encryption as countermeasure for skimming/harvesting (evesdropping).

in general, if the naive user is clicking on something that obfuscates the real URL (in some case they don't even have to obfuscate the real URL) ... then the crooks can still utilize https/ssl ... making sure that they have a valid digital certificate that matches the URL that they are providing.

the low-hanging fruit of fraud ROI ... says that the crooks are going to go after the easiest target, with the lowest risk, and the biggest bang-for-the buck. that has mostly been the data-at-rest transaction files. then it is other attacks on either of the end-points. attacking generalized internet channels for harvesting/skimming appears to be one of the lowest paybacks for the effort. in other domains, there have been harvesting/skimming attacks ... but again mostly on end-points ... and these are dedicated/concentrated environments where the only traffic ... is traffic of interest (any extraneous/uninteresting stuff has already been filtered out).

Citibank discloses private information to improve security

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Citibank discloses private information to improve security
Date: Wed, 01 Jun 2005 16:38:18 -0600
To: Heyman, Michael <Michael.Heyman@xxxxxxxx>
CC: cryptography@xxxxxxxx
Heyman, Michael wrote:
Defense in depth can help against spoofing - this includes valid certificates, personalization (even if it is the less-than-optimal Citibank-like solution), PetName, etc. Man-in-the-middle is harder given that we have such a high false positive rate on our best weapon.

i would claim that SSL-like protocol with both countermeasure for MITM-attack and eavesdropping attacks should be adequate.

many of the current problems is that browsers and email clients have tended to added multiple layers of obfuscation around the URL process ... so it may be difficult for even experience users to realize what is happening

a semi-counter argument for defense-in-depth is KISS ... lots of complex layers tend to create all sorts of cracks for the attackers to get thru.

in theory, the KISS part of SSL's countermeasure for MITM-attack ... is does the URL you entered match the URL in the provided certificate. An attack is inducing a fraudulent URL to be entered for which the attackers have a valid certificates.

so some of the recent internet phishing countermeasures are trying to rely on clear, un-obfuscated indications recognizable by even naive users. however, the tend to be add-ons, non-integrated with existing countermeasures (like SSL MITM-attack countermeasures) and leave existing systemic vulnerabilities in place. When purely static data un-obfuscated recognizable indications are used independently of MITM countermeasures .... a MITM can create active channels between themselves and the end-user and themselves and the website and transparently pass information between the two end-points.

Rather than complex defense in depth ... all with cracks and vulnerabilities that attackers can wiggle around ... a better approach could be KISS solution that had integrated approach to existing systemic vulnerabilities. For instance, some sort of clear, un-obfuscated indications integrated with URL selection that can leverage the existing SSL MITM-attack countermeasures.

The downside of a KISS integrated solution that eliminates existing systemic problems (and avoids creating complex layers, each with their individual cracks that the attackers can wiggle thru) ... is that the only current special interest for such a solution seems to be the victims. Some sort of fix that allows naive users to relate and enter specific trusted URLs associated with specific tasks could fix many of the existing infrastructure vulnerabilities. The issue is what institutions have "financial interest in designing, implementing, and marketing such a likely "free" add-on to existing mostly "free" based infrastructure"? It appears to be much easier to justify the design, implementation and marketing of a totally new feature that can be separately charge for.

some topic drift ... one person's history of priced software:
https://www.garlic.com/~lynn/2005g.html#51
https://www.garlic.com/~lynn/2005g.html#53
https://www.garlic.com/~lynn/2005g.html#54
https://www.garlic.com/~lynn/2005g.html#57

"SSL stops credit card sniffing" is a correlation/causality myth

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: "SSL stops credit card sniffing" is a correlation/causality myth
Date: Thu, 02 Jun 2005 12:23:13 -0600
To: Adam Shostack <adam@homeport.org>
CC: Perry E. Metzger <perry@xxxxxxxx>, Ian G <iang@xxxxxxxx>,
    cryptography@xxxxxxxx
Adam Shostack wrote:
So, that may be the case when you're dealing with an SSL accelerator, but there are lots of other cases, say, implementing daabase security rules, or ensuring that non-transactional lookups are logged, which are harder to argue for, take more time and energy to implement, and may well entail not implementing customer-visible features to get them in on budget.

Choicepoint and Lexis Nexis seemingly, had neither. Nor are they representational. We lack good data, and while there are a few hundred folks who have the experience, chops, and savvy to help their customers make good decisions, there are tens of thousands of companies, many of whom choose not to pay rates for that sort of advice, and hire an MCSE, instead. People who slap the label "best practice" on log truncation.

I think that we need to promulgate the idea that Choicepoint is creating a shift, that it will be ok to talk about breaches, with the intent of getting better data over time.

we got brought in to work on some word smithing for both the cal. state and the fed. digital signature legislation (we somewhat concentrated on the distinction between digital signature authentication and that human signature implies read, understands, agrees, approves, authorizes, etc .... which isn't present in simple authentication).

one of the industry groups that was active in the effort had done some extensive surveys on driving factors behind various kinds of regulatory and legislative actions. with regard to privacy regulatory/legislative actions ... the two main driving factors were 1) identity theft and 2) effectively institutional (gov, commercial, etc) denial of service.

[Clips] Paying Extra for Faster Airport Security

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: [Clips] Paying Extra for Faster Airport Security
Date: Fri, 03 Jun 2005 07:40:14 -0600
To: R.A. Hettinga <rah@xxxxxxxx>
CC: cryptography@xxxxxxxx
there were several news URLs a month or so ago about the issue of "faster" in conjunction with the orlanda effort and some of the predictions on possibly 40mil (most frequently travelling) people sign up if such programs were rolled out around the country.

the issue raised was that they were effectively paying to have a priority queue for the existing screening stations (effectively could take the place of the first class queue at some airports) ... and what is the characteristic of a priority queue if nearly everybody is standing in the priority queue rather than the regular queue.

having done some work on queuing ... i turned out the mainframe operating system resource manager in the 70s
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

if the service stations are the same ... and you just are re-arranging the order of service ... priority queues have the appearance of meeting their objectives when only a small percentage of the total population is in the priority queue.

R.A. Hettinga wrote:
Security needs identity like a fish needs... well, you get the idea...
Cheers,
RAH
-------

http://online.wsj.com/article_print/0,,SB111767537888648936,00.html

The Wall Street Journal
June 2, 2005

Paying Extra for Faster Airport Security
Orlando Kicks Off Program
Offering Quicker Screenings
To Holders of Special Cards

Digital signatures have a big problem with meaning

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Digital signatures have a big problem with meaning
Date: Fri, 03 Jun 2005 07:51:02 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: dan@xxxxxxxx,  rsalz@xxxxxxxx,  cryptography@xxxxxxxx
Peter Gutmann wrote:
That cuts both ways though. Since so many systems *do* screw with data (in insignificant ways, e.g. stripping trailing blanks), anyone who does massage data in such a way that any trivial change will be detected is going to be inundated with false positives. Just ask any OpenPGP implementor about handling text canonicalisation.

this was one of the big issues in the asn.1 encoding vis-a-vis xml encoding wars.

asn.1 encoding provided deterministic encoding for signed material, although some of the more common applications of digital signature have what is transmitted is the original encoded material along with the signature of that encoded material.

fstc/e-check project wanted to digital sign stuff that was xml encoded ... but not transmit the xml encoded fields. they wanted to take standard financial transaction fields ... momentarily xml encode the standard fields, digitally sign the encoded material ... and then append the resulting digital signature to the (original) standard transaction for transmission.

the problem was that xml didn't have a deterministic definition for encoding fields. when the recipient/relying party received the transmission ... they had to take the standard transaction fields and re-encode in xml in order to verifiy the digital signature. fstc/e-check came up with fsml for deterministic encoding of fields ... so that the encoding done by the originator (of the digital signature) and the encoding done by the relying party (for verifying the digital signature) would have identical bit patterns.

fsml was subsequently contributed to the xml digital signature project.

xml is descendent of gml invented by "G", "M", and "L" in 1969 at the science center
https://www.garlic.com/~lynn/subtopic.html#545tech
and then standardized at ISO in the 70s
https://www.garlic.com/~lynn/submain.html#sgml

[Clips] Paying Extra for Faster Airport Security

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: [Clips] Paying Extra for Faster Airport Security
Date: Sat, 04 Jun 2005 08:10:10 -0600
To: R.A. Hettinga <rah@xxxxxxxx>
CC: cryptography@xxxxxxxx
one of the articles from a couple months ago about what happens if too many people shift into a priority queue. note that it is somewhat cheaper to let a few people to pay to go to the head of the screening line ... so that their queueing wait is reduced. It is a lot more expensive to install significantly more screening stations if you are planning on moving a large precentage of the people to the priority queue.

Frequent fliers' priority perks may lose value
http://www.marketwatch.com/news/story.asp?guid=%7B4CB9FEEC-C6A3-477E-BC79-7E465CDA9BBC%7D&siteid=google&dist=google&cbsReferrer=

an article about making the screening process (itself) significantly faster, rather than just re-ordering how people go thru the screening process.

Design Build Contractor Emmanuel Cabrera Unveils Model for a New Airport Security and Screening Facility
http://www.kltv.com/Global/story.asp?S=2981723

some older stories about going to the head of the screening line

Orlando airport will allow frequent fliers to bypass screening
http://www.usatoday.com/travel/flights/2005-02-17-orlando-bypass_x.htm
OIA, TSA to launch first 'Private Sector Known Traveler Program'
http://orlando.bizjournals.com/orlando/stories/2005/02/14/daily37.html

lots of recent stories about going to the head of the screening line.

Voluntary Security ID to Debut in Florida
http://www.rednova.com/news/general/153608/voluntary_security_id_to_debut_in_florida/
Voluntary Security ID to Debut in Florida
http://www.sierratimes.com/rss/newswire.php?article=/news.yahoo.com/news?tmpl=story&u=/ap/20050603/ap_on_re_us/private_security_pass&time=1117836210&feed=us
Voluntary Security ID to Debut in Florida
http://www.durantdemocrat.com/articles/2005/06/03/ap/hitech/d8agc8180.txt
Voluntary security ID to debut in Florida
http://www.bradenton.com/mld/bradenton/11808773.htm
Voluntary security ID to debut in Florida
http://www.mercurynews.com/mld/mercurynews/news/8263034.htm
Orlando airport first tester of quick-pass voluntary biometric ID
http://www.jacksonville.com/tu-online/apnews/stories/060305/D8AGBC3G1.shtml
Orlando airport to allow use of $80 security ID
http://www.chron.com/cs/CDA/ssistory.mpl/business/3210249
Voluntary Security ID to Debut in Florida
http://wireservice.wired.com/wired/story.asp?section=Breaking&storyId=1043759
Firm's system lets frequent fliers speed through airport's security
http://www.philly.com/mld/inquirer/news/nation/11811618.htm
Passes put fliers in the fast lane
http://www.sun-sentinel.com/business/local/sfl-zairport04jun04,0,939657.story?coll=sfla-business-headlines
Skipping security checks
http://www.mercurynews.com/mld/mercurynews/business/16578350.htm
Bio ID may make airport security easy
http://www.harktheherald.com/modules.php?op=modload&name=News&file=article&sid=56599&mode=thread&order=0&thold=0
Transport Deptt. Wants the Airline Passenger Information
http://archives.moneyplans.net/frontend204-verify-7796.html
Airport fast lanes to get test
http://www.sptimes.com/2005/06/04/Worldandnation/Airport_fast_lanes_to.shtml

Using Corporate Logos to Beat ID Theft

From: Anne & Lynn Wheeler <lynn@xxxxxxxx
Subject: Using Corporate Logos to Beat ID Theft
Date: Mon, 06 Jun 2005 11:41:28 -0600
To: cryptography@xxxxxxxx
former chair of x9a10 working group did quite a bit of work on this approach ... although it was more oriented towards being able to validate websites as opposed to email ... and none of it shows up in the x9.59 standard
https://www.garlic.com/~lynn/x959.html#x959

for some topic drift ... recently i had opportunity to repeat the story about ISO/OSI directive prohibiting work on standards that violated OSI model
https://www.garlic.com/~lynn/2005j.html#33

and happen to remember during the 90s work on x9.59, somebody trying to claim that (some?) ISO organization couldn't do work on standards involving digital signatures unless they were certificate-based infrastructures; collection of certificate-less based postings
https://www.garlic.com/~lynn/subpubkey.html#certless

Using Corporate Logos to Beat ID Theft
http://www.eweek.com/article2/0,1759,1822978,00.asp
....
The Mountain View, Calif., company's technology uses corporate logos to distinguish legitimate e-mail messages from those that fake, or spoof, their origin. Iconix is preparing to announce its first product next quarter, said company officials.

... snip ...

Digital signatures have a big problem with meaning

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Digital signatures have a big problem with meaning
Date: Mon, 06 Jun 2005 15:48:14 -0600
To: Peter Gutmann <pgut001@xxxxxxxx
CC: cryptography@xxxxxxxx,  dan@xxxxxxxx,  rsalz@xxxxxxxx
Peter Gutmann wrote:
Yup, see "Why XML Security is Broken",
http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt
for more on this. Mind you ASN.1 is little better, there are rules for deterministic encoding, but so many things get them wrong that experience has shown the only safe way to handle it is to do an exact bit-for-bit copy from A to B, rather than trying to re-code at any point. I've frequently commented that there is only one workable rule for encoding objects like X.500 DNs, and that's memcpy().

there was another issue with digital signatures supposedly acquiring attributes of human signatures .... aka implication that human had actually read, understood, agrees, approves, and/or authorizes the content ... as well as intent.

so at least some financial institutions in the mid-90s were realizing that x.509 identity certificate ... potentially overloaded with enormous amounts of personal information, represented significant liability and privacy concerns ... were looked at switching to relying-party-only certificates ... basically containing some sort of database record locator (where all the real information was located) and a public key. however, it was trivial to demonstrate that such certificates were redundant and superfluous.
https://www.garlic.com/~lynn/subpubkey.html#rpo

there was another issue involving the typical 4k-12k byte size of such certificates ... when appended to a typical payment transaction of 60-80 bytes ... besides being redundant and superfluous ... also would represent horrendous payload bloat.

now the certificate crazed periods of the 90s also had something called the certificate non-repudiation bit ... which large segments of the market was interpreting as meaning that digital signatures with appended certificates containing the non-repudiation bit ... couldn't be repudiated by the person responsible for the digital signature.

in the retail payments scenario ... the task was to convince consumers to pay $100/annum for redundant and superfluous, payload bloating relying-party-only certificates with the non-repudiation bit set. supposedly the scenario being sold retail merchant industry was that while the current retail payment environment had the burden of proof (in any consumer dispute) placed on the merchant ... if the consumer would be so kind to append an redundant and superfluous, enormous payload bloating certificate with the non-repudiation bit set ... the burden of proof in a dispute would be shifted from the merchant to the consumer.

there was some hypothetical investigation that even if the consumer did digitally sign a retail payment transaction and appended a redundant and superfluous, payload bloating relying-party-only certificate ... but w/o the non-repudiation bit set .... that merchants could possibly substitute a similar certificate which did have the non-repudiation bit turned on ... possibly harvested from some convenient, cooperating LDAP trusted certificate repository.

besides all the other practical and legal issues about digital signatures being interpreted as simply something you have authentication ... from 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor and NOT as human signature implying intent, read, understood, agree, approve, and/or authorize ....

... there was the issue that the non-repudiation bit within a certificate was supposedly creating liability on behalf of the digital signer ... however the PKI protocols contained no provision for proving what specific certificate the person applying a digital signature had actually appended to any specific transaction ... aka the digital signature was only on the transaction itself ... and there was no digital signature armoring/binding which digital certificate might actually have been originally appended to any specific digitally signed transaction (possibly allowing merchants to substitute non-repudiation certificates when none had been intended).

encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)
Date: Tue, 07 Jun 2005 19:59:44 -0600
To: Perry E. Metzger <perry@xxxxxxxx>
CC: Ian G <iang@xxxxxxxx>,  cryptography@xxxxxxxx
a couple past posts (from jan. 1999) on the thread between information security and risk management (in financial institutions, with stuff about encryption, effects of exploits on corporate valuation ... even includes some discussion of citi)
https://www.garlic.com/~lynn/aepay3.htm#riskm
https://www.garlic.com/~lynn/aepay3.htm#riskaads

de-identification

Refed: **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: de-identification
Date: Mon, 13 Jun 2005 13:21:55 -0600
To: Florian Weimer <fw@xxxxxxxx>
CC: dan@xxxxxxxx,  cryptography@xxxxxxxx
Florian Weimer wrote:
We call it pseudonymization ("Pseudonymisierung"). It's a commonly used technique in Germany to detaint personally identifiable information, so you can share it freely for statistics purposes. The methods used in the field are rather crude (time-seeded LCGs are very common, unfortunately).

from privacy glossary and taxonomy
https://www.garlic.com/~lynn/privacy.htm

that i put together when working on x9.99 PIA standard for financial industry ... from HIPAA

anonymized
Previously identifiable data that have been deidentified and for which a code or other link no longer exists. An investigator would not be able to link anonymized information back to a specific individual. [HIPAA] (see also anonymous, coded, directly identifiable, indirectly identifiable)

expanding a password into many keys

Refed: **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: expanding a password into many keys
Date: Mon, 13 Jun 2005 18:16:47 -0600
To: Ian G <iang@xxxxxxxx>
CC: cryptography@xxxxxxxx
Ian G wrote:
I'd like to take a password and expand it into several keys. It seems like a fairly simple operation of hashing the concatonatonation of the password with each key name in turn to get each key.

there is financial standard for derived key per transaction

from x9f taxonomy and glossary
https://www.garlic.com/~lynn/x9f.htm

derived unique key per transaction (DUKPT)
A key management method which uses a unique key for each transaction, and prevents the disclosure of any past key used by the transaction originating TRSM. The unique Transaction Keys are derived from a base derivation key using only non-secret data transmitted as part of each transaction. [X924] (see also cryptographic key, transaction)

........

basically you may be able to brute force an individual key w/o comprimising the "master key" (or any other keys derived from the master key).

derived keys are used in other infrastructures beside financial transactions. some token based systems may simply use derived key per token (as opposed to per transaction) ... brute force of a particular token's key doesn't compromise either the overall infrastructure and/or other tokens in the infrastructure.

expanding a password into many keys

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: expanding a password into many keys
Date: Tue, 14 Jun 2005 10:59:26 -0600
To: Hal Finney <hal@xxxxxxxx>
CC: cryptography@xxxxxxxx
Hal Finney wrote:
The recommended technique I've seen for this (I think David Wagner suggested it on sci.crypt years ago) is to use a MAC:

key = MAC (password, keyname)

The security property of a MAC is that you can get as many messages MAC'd as you want, and you won't be able to guess a MAC on any new messages. That's exactly what you want here, that an attacker can learn keys when he knows or chooses keynames, but be unable to guess any keys for any other keynames. It's a good fit to the security requirements for your problem.

as previously noted ... financial industry has had a standard for derived key for some time.

a variation on this is the interative hash for one-time password (except the keyname became the server specific "salt" and there was added value for the number of hash iterations) ... the claim was that it was targeted for an end-user could walk up to an open environment w/o anything other than their passphrase ... and be able to logon. various MITM attacks against the server were examined ... however there wasn't equal examination of MITM attacks against the end-user (i.e. providing a count of one to the end-user ... so that attacker then can reproduce all subsequent hash iteration values) ... misc. past postings
https://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?
https://www.garlic.com/~lynn/2005i.html#50 XOR passphrase with a constant

massive data theft at MasterCard processor

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: massive data theft at MasterCard processor
Date: Mon, 20 Jun 2005 20:26:25 -0600
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: cryptography@xxxxxxxx
Steven M. Bellovin wrote:
MasterCard reported the exposure of up to 40,000,000 credit card numbers at CardSystems Solutions, a third-party processor of credit card data. CardSystems was infected with a script that targeted specific data. In other words, this wasn't the usual carelessness, this was enemy action, and of a sophisticated nature. See
http://www.mastercardinternational.com/cgi-bin/newsroom.cgi?id=1038 for the official statement.

Designing a system that deflects this sort of attack is challenging. The right answer is smart cards that can digitally sign transactions, but that would require rolling out new readers to all the merchants. That's doable, about once per decade -- and at least one credit card vendor (JP Morgan-Chase) is using the opportunity to push out RFID-based credit card readers instead. So the marketing department outranks the security department -- big surprise there....

reference to posting in a usenet n.g. in a thread that talked about putting encryption everywhere as a solution
https://www.garlic.com/~lynn/2005k.html#55 Encryption Everywhere?
https://www.garlic.com/~lynn/2005k.html#56 Encryption Everywhere?

as referenced in the above ... x9.59
https://www.garlic.com/~lynn/x959.html#x959

has countermeasure against the harvesting vulnerability (w/o requiring any encryption); harvesting is so attractive to attackers because the return is so enormous for the amount of effort
https://www.garlic.com/~lynn/subintegrity.html#harvest

it is NOT a countermeasure to fraudulent terminals. there was some effort in x9a10 working group (which was tasked with preserving the integrity of the financial infrastructure for ALL retail payments, regardless of kind, debit, credit, stored-value, etc ... and/or environment) with regard to trusted terminal modules .... somewhat akin to EU finread standard
https://www.garlic.com/~lynn/subintegrity.html#finread
and existing POS security modules ... but with the addition that the terminal also digitally signed the same transaction. the consumer would digitally sign for authentication ... and the trusted terminal would also digitally co-sign authenticating the terminal used.

the issue is there is still some vulnerability involving terminal overlays ... analogous to what has been read about regarding ATM cash machine overlays ... although not for harvesting ... since x9.59 closed that hole ... but for transaction misrepresentation ... although the payback for crooks isn't nearly as attractive as compared to harvesting tho. nominally in compromised devices for harvesting ... they want to have it go undetected for as long as possible ... transaction misrepresentation may be quickly traced to its source.

so one of the AADS chip strawman suggestions for x9.59 from the 90s
https://www.garlic.com/~lynn/x959.html#aads

was the same protocol and transaction whether it was with the merchant terminals ... or with a consumer owned pda/cellphone device (any kind of wireless to the merchant device) ... where a paranoid consumer would always maintain physical control of their private display and keypad.

massive data theft at MasterCard processor

Refed: **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: massive data theft at MasterCard processor
Date: Tue, 21 Jun 2005 06:27:59 -0600
To: Peter Fairbrother <zenadsl6186@xxxxxxxx>
CC: Steven M. Bellovin <smb@xxxxxxxx>,  cryptography@xxxxxxxx
Peter Fairbrother wrote:
Also there are several attacks on Chip n' PIN as deployed here in the UK, starting with the fake reader attacks - for instance, a fake reader says you are authorising a payment for $6.99 while in fact the card and PIN are being used to authorise a transaction for $10,000 across the street. They get quite complex, there's the double-dip, where the $6.99 transaction is also made, and the delayed double dip, where a reader belonging to a crook makes the $10,000 transaction several days later (the crook has to skip town with the money in this attack - so far. Except of course he never existed in the first place, and maybe ...).

the payment infrastructure requires a financial institution taking responsibility for a merchant to connect into the network ... and the settlement into the merchant account nominally flows thru the sponsoring merchant financial institution. for a merchant not to actually exist would require some lapse on the sponsoring financial institution ... i.e. some of the anonomous stored-value specifications tried to simulate direct cash-like transfer between two tokens .... but the existing payment networks are far from that, requiring a bit more deception on the part of any fraudulent merchant.

note that some of the transaction authentication specifications don't necessarily match x9.59 financial standard in also specifying that a PAN in an authenticated transaction can't be used in a non-authenticated transaction. recent post reference
https://www.garlic.com/~lynn/aadsm19.htm#38
https://www.garlic.com/~lynn/2005k.html#55
https://www.garlic.com/~lynn/2005k.html#56

i.e. which still leaves open the various harvesting vulnerabilities. the x9.59 financial standard specified that both

1) transactions have to be individually authenticated (account-level authentication with the issuing institution) and

2) the same PAN used in authenticated transactions can't be used in non-authenticated transactions (countermeasure to harvesting vulnerability where crook could utilize information for later fraudulent transactions)

misc. x9.59
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy

massive data theft at MasterCard processor

Refed: **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: massive data theft at MasterCard processor
Date: Tue, 21 Jun 2005 09:03:14 -0600
To: cryptography@xxxxxxxx
Anne & Lynn Wheeler wrote:
as referenced in the above ... x9.59
https://www.garlic.com/~lynn/x959.html#x959

has countermeasure against the harvesting vulnerability (w/o requiring any encryption) which is so attractive to attackers because the return is so enormous for the amount of effort
https://www.garlic.com/~lynn/subintegrity.html#harvest

re:
https://www.garlic.com/~lynn/aadsm19.htm#38
https://www.garlic.com/~lynn/aadsm19.htm#39

note that while x9.59 allows for digital signature (as method of strong-authentication) ... and even co-signing by both the consumer and the terminal ... it doesn't mandate certificate-based operation and allows for certificate-less digital signature authentication.
https://www.garlic.com/~lynn/subpubkey.html#certless

we had worked on the original payment gateway for what was becoming e-commerce
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

before starting in the x9a10 financial standards working group on x9.59 standard
https://www.garlic.com/~lynn/x959.html#x959

in that time frame there were some number of specifications for financial transactions that involved digital signatures and mandated a fairly large collection of digital certificates and pki.

the financial industry in the mid-90s was one of the industries that was starting to realize that the x.509 certificates, somewhat from the early 90s, representing significant privacy and liability issues ... especially when grossly overloaded with personal information.

they had retrenched to relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

which effectively bound a public key to an account number or some other form of database lookup value (where the real and relavant information was actually stored). note that it was relatively trivial to show that such digital certificates were redundant and superfluous (repeatedly sending back database lookup value to the institution that had issued the certificate and had direct access to all the real information).

the other issue we saw with some of the financial transactions mandating digital certificates (especially redundant and superfluous relying-party-only certificates) was the enormous payload bloat in typical payment network transaction. A typical payment network transaction has been on the order of 60-80 bytes ... the typical relying-party-only digital certificate for these programs ran 4k to 12k bytes ... which represented an enormous payload bloat of a factor of one hundred times.

Some of the programs realizing that it really wasn't practical to transmit such a redundant and superfluous digital certificate over the typical payment network ... were having an internet boundary gateway validate any digital signature (with the public key in the digital certificate) ... and then transmitting a normal payment network transaction with simply a bit turned on indicating if the digital signature had verified.

Besides violating kindergarten security 101 regarding end-to-end security (or because of it) ... there was an ISO standards meeting where a business person from one of the payment networks gave statistics on there being quite a few payment transactions flowing thru the network with the digital signature verified flag turned on ... and they could prove that there hadn't been any digital signature technology involved (one possibly motivation given was that they were talking about lowering the discount rate for digital signature verified transactions based on presumption of lower fraud rate). The scenario is that the consumer's issuing bank is the financial responsible party ... and fundamental end-to-end security principles would dictate that the responsible party for authorizing the transaction should also be the responsible party for authenticating the transaction (rather than possible organizations that might have interests quite different from that of the consumer's issuing financial institution).

A side issue with some of the payment digital signature specifications from the period was that they provided no countermeasure for the growing harvesting/skimming problem ... aka the sam PAN in a digital signed transaction could be harvested and used in a non-authenticated transaction
https://www.garlic.com/~lynn/subintegrity.html#harvest

massive data theft at MasterCard processor

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: massive data theft at MasterCard processor
Date: Wed, 22 Jun 2005 08:39:02 -0600
To: cryptography@xxxxxxxx
Anne & Lynn Wheeler wrote:
so one of the AADS chip strawman suggestions for x9.59 from the 90s
https://www.garlic.com/~lynn/x959.html#aads

was the same protocol and transaction whether it was with the merchant terminals ... or with a consumer owned pda/cellphone device (any kind of wireless to the merchant device) ... where a paranoid consumer would always maintain physical control of their private display and keypad.

note that dual-use attack is another variation on "what you see is not necessarily what you get".

the dual-use attack ... is possibly a person-centric digitally signing token (in contrast to institutional-centric token where each institution might issue a unique token for every use) ... that can be registered for use in multiple places and applications.

one of the digial signing scenarios is pure authentication where the server sends out some random data which the end-user signs (effectively a variation on challenge/response as countermeasure against replay attacks).

the issue in the dual-use attack ... is can somebody substitute a perfectly valid financial transaction in lieu of random challenge data? this attack is similar but different to point-of-sale attack where the terminal displays a transaction different than what is provided for signing (what you sign is not necessarily what you think you are signing).

dual-use attack is against a possibly person-centric digital signing where the same token/key is used for both authentication events as well as "signature" type events .... where the signature is taken to imply read, understood, approve, authorize, and/or agree.

misc. past refs:
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
https://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards

massive data theft at MasterCard processor

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: massive data theft at MasterCard processor
Date: Fri, 24 Jun 2005 06:52:42 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx
James A. Donald wrote:
Rather the server should send out some encrypted random data which the end user decrypts. End user should then prove knowledge of that encrypted data.

re: possible dual-use vulnerability using digital signatures for authentication purposes.
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor

so the random data is sent encrypted with the person's public key ... they can decrypt it with their private key. so the random data could contain someting like a session key. they send back the random data encrypted with the random session key. this demonstrates possesion of the private (aka something you have authentication). this avoids having to perform digital signatures on perported random data for pure authentication operations (never digital sign random data ... only digital sign what, you, yourself have personally created).

For pure authentication operations ... this model eliminates the whole digtital certificate paradigm ... since the model assumes that the originator of the authentication request already has the recipients public key recorded someplace.
https://www.garlic.com/~lynn/subpubkey.html#certless

this has also been the suggestion for optimized SSL modification to use public keys registered with the domain name infrastructure. public key and SSL options are registered with the domain name infrastructure. An optimized DNS call returns the ip-address and any public key and SSL options as optional piggyback on the same transaction. the client generates the random session key ... and on the initial packet, transmits the random session key encoded with the server's registered public key ... along with the initial packet of data encrypted with the generated random session key. the server returns the response encrypted with the generated random session key. For real transaction oriented operations, you could even do this with UDP and a single send followed by single response (plus the DNS send/reponse).

the SSL domain name certificate infrastructure was targeted as countermeasure for perceived integrity issues with the domain name infrastructure. somebody would apply to CA for SSL domain name infrastructure, they would check with the domain name infrastructure if the applicant was the valid owner of the domain name ... and then issue the SSL domain name certificate. the problem of course, is that the domain name infrastructure then is still the trust root as to who gets issued SSL domain name certificate ... the very same domain name infrastructure that was perceived to have integrity problems, which generated the requirement for SSL domain name certificates.

So somewhat from the CA industry to help close various vulnerabilities in the domain name infrastructure, there has been suggestion that domain name owners register their public key. this helps with using the domain name infrastructure as the "trust root" for the CA industry related to domain name ownership and valid applicants for SSL domain name infrastructure. this also helps the CA industry, where they can change an expensive, time-consuming and error prone identification matching operation (checking the applicant's identification against the identification on file for the domain name owner with the domain name infrastructure) to a much simpler and reliably authentication operation (have the applicant digitally sign the SSL domain name application, retrieve the on-file public key and validate the digital signature).

this, then creates the catch-22 for the CA industry for SSL domain name certificates (aka if the CA industry can use certificate-less, onfile public keys for their purposes ... why can't the rest of the world).

massive data theft at MasterCard processor

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: massive data theft at MasterCard processor
Date: Fri, 24 Jun 2005 07:34:29 -0600
To: cryptography@xxxxxxxx
Anne & Lynn Wheeler wrote:
For pure authentication operations ... this model eliminates the whole digtital certificate paradigm ... since the model assumes that the originator of the authentication request already has the recipient's public key recorded someplace.
https://www.garlic.com/~lynn/subpubkey.html#certless

so the simplified SSL using the domain name on-file public key ... still has possible replay attack potential against the server (the attacker doesn't necessarily know what the replay is doing ... but getting the server do it multiple times might result in something bad).

so in another kind of authenticated connection scenario ... say Kerberos or RADIUS ... the client has registered their public key in lieu of some sort of password (for certificate-less operation)
https://www.garlic.com/~lynn/subpubkey.html#radius
https://www.garlic.com/~lynn/subpubkey.html#kerberos

they contact the server asserting some userid. the server generates a random key, encrypts a time-stamp plus asserted userid plus more random data, encrypts the random key with the public key on file for that userid and responds. the user decrypts the random key with their private key, and decrypts the response. at this point their is a choice of possibly having encrypted sessions (with possibly perceived overhead issues) ... or having the client permute the unencrypted data in some way, re-encrypt just the permuted data and return it with unencrypted data. the re-encrypted data demonstrates something you have authentication (i.e. the client has possession and use of the appropriate private key).

there are MITM vulnerabilities for the client ... since the server hasn't been authenticated.

to eliminate the MITM attacks against the client and replay attacks against the server ... they would have to authenticate each other .... w/o resorting to digital signatures (and opening themselves up to dual-use attack) ... each sending some random data encrypted with the other's public key .. which then can be decrypted with the appropriate private key.

massive data theft at MasterCard processor

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: massive data theft at MasterCard processor
Date: Fri, 24 Jun 2005 14:01:47 -0600
To: Charles M. Hannum <mycroft@xxxxxxxx>
CC: James A. Donald <jamesd@xxxxxxxx>,  cryptography@xxxxxxxx
Charles M. Hannum wrote:
As long as the "credit card" has no display, you're still trusting the terminal to give the purchaser correct information. If you're using a smart "credit card" that participates directly in the transaction, storing transaction data, signed by the processor's system, on the card would be useful for repudiation. You could even have a way of downloading the data directly into Quicken and using it to check invoices automatically.

absolutely ... see comment at end of early post in this thread about paranoid consumers ...
https://www.garlic.com/~lynn/aadsm19.htm#38

as part of the charge to x9a10 financial standards working group to preserve the integrity of the financial infrastructure for all retail payments (aka debit, credit, ach, stored-value, etc as well as internet, pos, face-to-face, moto, etc) ... there were some other provisions in x9.59 payment standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy

for use with private PC-based internet transactions and/or enhanced personal point-of-sale device (cellphone, pda, etc). there is a data field defined in the x9.59 that was specifically put in place for use as personal transaction number (or a virtual check number if you are so disposed).

it was specifically designed for supporting electronic reconciliation between transactions and various possible electronic statements.

in the mapping from x9.59 to iso 8583 payment transaction description
https://www.garlic.com/~lynn/8583flow.htm

it is referred to as a LUID (costomer/locally unique number) ... although there is not actual requirement for it to be unique and/or even anything other than NULL. the standard suggests that if the LUID field is present as part of an x9.59 transaction, that the institution should include it any statements provided the customer (analogous to the way that check numbers are provided on statements).

X9.59 also provides for an optional field for hash of order detail. basically what the user signs, can include the hash of the invoice/order. the merchant then is to validate that any (non-null) invoice/order hash included in the signed x9.59 message corresponds to hash of their invoice/order ... if the two hashes don't match ... don't submit the transaction for payment. If the merchant disputes the invoice/order later ... and the user happens to have included the hash of invoice/order in the payment transaction ... then the disputed invoice/order submitted by the merchant better have a hash that matches what is in the signed payment transaction. this avoids requiring that the invoice/order has to be part of the payment transaction ... but leaves around some amount of detail that can be used as supporting evidence in the event of any dispuate.

there is a EU FINREAD standard for a personal financial termainal that talks about countermeasures for things like keylogging and making sure the value of the transaction is correctly displayed
https://www.garlic.com/~lynn/subintegrity.html#finread

from the x9.59 perspective, there was a lot of work on allowing that such a terminal could co-sign the transaction ... providing the financial institution some risk indication about the person authenticating the transaction as well as risk indication about the environment in which the transaction occured (aka EU FINREAD specified requirements for the personal financial termainal ... but didn't actually require proof that such a terminal was actually used).

some of the characteristics of the EU FINREAD terminal are similar to the security module requirements for POS terminals. The issue is that both the users as well as the financial institutions may have no indication that a POS terminal with specific integrity level was in use for any specific transaction (making it difficult to fully do parameterised risk management ... i.e. calculate all the possible fraud and risk factors on a transaction by transaction basis).

the identified issue leading up to the privatly owned display and keypad at POS ... is that even if there was a tamper resitent security module in a tamper resistent post-of-sale terminal ... that also co-signed the transaction ... there is still POS vulerability with things like overlays (i.e. a compromised MITM display/keypad sitting between the user and the real POS secure terminal).

payment system fraud, etc

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: payment system fraud, etc.
Date: Sat, 09 Jul 2005 10:30:06 -0600
To: Perry E. Metzger <perry@xxxxxxxx>
CC: Jerrold Leichter <jerrold.leichter@xxxxxxxx>,
    cryptography@xxxxxxxx
Perry E. Metzger wrote:
That system has a number of flaws in it, including the fact that it is not an end to end cryptographically protected communication, and is thus subject to credential theft and the customer PIN is exposed to a reader provided by the merchant. I think with the right design, most such issues might go away.

a lot the big news articles about data breaches are related to being able to do account fraud against the payment system .... just from electronic records. this is basically static data that can leveraged to directly performing electronic account fraud and/or being able to create counterfeit cards and performing fraudulent transactions. similar to the database harvesting exploits are the skimming exploits where electronic recording of transactions are performed .... there have even been crime tv shows about ATM overlays and pin-hole cameras as part of skimming activities. again the electronic recording is sufficient for creating counterfeit cards and performing fraudulent transactions. lots of past posts related to harvesting and skimming
https://www.garlic.com/~lynn/subintegrity.html#harvest

the above includes some number of past posts about the target databases provide much bigger fraud return-on-investment than evesdropping for e-commerce transactions. slightly related is old security proportional to risk posting
https://www.garlic.com/~lynn/2001h.html#61

the other way of viewing this is that the knowledge of the account number and/or the static data magstripe card are taken as authentication which enables the performing of an unauthenticated transactions. This can be interpreted as both a form of replay-attack (replaying the authentication to enable the execution of an unauthenticated transactions) and a MITM-attack (i.e. the crooks slipping into the cracks between the simple authentication and the unauthenticated transactions).

as mentioned in past posts on x9.59,
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy

the x9a10 working group was tasked with preserving the integrity of the financial infrastructure for all retail payments. this resulted in two business rules
  1. strongly authenticated transactions .... example mapping to iso 8583 payment transactions used ecdsa with public keys registered at the issuing bank ... there were pki-based payment specifications in the same period as the original x9.59 standards work. even when they retrenched to relying-party-only certificates to mitigate severe privacy and liability issues with x.509 identity certificates
    https://www.garlic.com/~lynn/subpubkey.html#rpo
    the certificate overhead was still on the order of 4k-12k bytes. for typical iso 8583 message sizes of 60-80 bytes, this represented a factor of one hundred times payment bloat for redundant and superfluous PKI operation
  2. account numbers used in x9.59 transactions, if used in non-x9.59 transactions would not be authorized.
the first business rule made it difficult to counterfeit x9.59 transactions (and made them business process friendly, especially compared to some of the PKI-oriented specifications).

the second business rule eliminated harvesting/skimming of x9.59 account numbers as a threat/vulnerability. the issue here is that account numbers are used in dozens of business processes .... and even if the earth was buried miles deep in cryptography attempting to maintain privacy/confidentiality of the account numbers ... there would still be account number leakage. x9.59 recognizing that such leakage would be essentially impossible to stop ... attempted to eliminated such account number leakage as a threat and vulnerability.

so, as in earlier statements ... this would still leave merchant misrepresentation as a threat and vulnerability. the problem is that that is fairly quickly identified and shutdown. a big threat/vulnerability in the harvest/skimming scenario is that the crooks attempt to perform the fraud as far away as possible from the source of compromise (maximizing the benefit of the compromised source). Fraud being performed at the point of compromise tends to have a much shorter lifetime. recent post
https://www.garlic.com/~lynn/aadsm19.htm#38 massive data theft at MasterCard processor

that leaves the old-fashion waving guns and social engineering. waving guns tends to have much lower fraud return on investment (especially when transactions tend to be limited to hundreds of dollars and lost/stolen reports can shut off the account).

if simple harvesting/skimming has been eliminated .... like data breaches ... then similar harvesting thru social engineering isn't going to work much better. you are back to something similar to the merchant misrepresented transactions .... except this is a social engineering misrepresented transaction (rather than social engineering skimming/harvesting).

chips by themselves are not necessarily a panecea. there have been past chip-based systems that have simple static data authentication ... making their threat/vulnerabilities little different than magstripe threat/vulnerabilities. there have also been MITM attacks on chips where the chip does dynamic data authentication ... and then proceeds to do unauthenticated transactions. this can also be represented as separating authentication and authorization ... and the crooks slip into the cracks between the authentication and the authorization.

lots of past fraud, threats, and vulnerability posts
https://www.garlic.com/~lynn/subintegrity.html#fraud

the limits of crypto and authentication

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: the limits of crypto and authentication
Date: Sat, 09 Jul 2005 12:17:43 -0600
To: Nick Owen <nowen@xxxxxxxx>
CC: Steven M. Bellovin <smb@xxxxxxxx>,  cryptography@xxxxxxxx
Nick Owen wrote:
To validate the transaction, a receipt could be sent to the user encrypted by the server's public key. If the receipt is correct, the user enters their PIN to 'sign' the transaction.

I'm assuming an asymmetric authentication system here outside the browser. The attacker would have to steal the user's private key, their PIN and the server's private key, correct?

I know that if the PC is compromised anything is possible, but I think this raises the bar significantly - perhaps to an unprofitably level.

the x9a10 financial standard working group was charged with preserving the integrity of the financial infrastructure for all retail payments ... and came up with x9.59
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy

besides the two business rules mentioned before, there were guidelines about being able to fit within the existing financial transaction straight-through processing transaction model ... aka the consumer originates the transaction and it can be processed in a single round trip.

there were provisions that the consumer should originate the transaction ... and/or at least have certified terminal when presented with the option to sign; misc. past posts about the EU finread terminal standard
https://www.garlic.com/~lynn/subintegrity.html#finread

worst case is that the foreign terminals are still susceptable to various compromises ... like misrepresnting the transaction. Not that this is slightly lower threat model since the point of compromise and the point of fraud are the same place ... and therefor are subject to quick shutdown. recent post mentioning paranoid consumers needing pda/cellphone portable devices at point-of-sale as countermeasure to various transaction misrepresentation vulnerabilities
https://www.garlic.com/~lynn/aadsm19.htm#38 massive data theft at MasterCard processor

x9.59 does provide for interaction outside the straight-through processing of the financial transaction. for instance, x9.59 has provision for including the hash of the order details in the body of the signed x9.59 transaction. the consumer returns such a signed message to the merchant. at this point the merchant can verify that the hash of order details in the body of the x9.59 digitally signed transaction is the same as their computed hash of *order details*. This is countermeasure against consumer attack on the merchant. While the body of the order details isn't part of the actual financial transaction, in the case of any dispute ... the two parties can produce their purported versions of order details and see which one hashes to the same value contained in the x9.59 digitally signed transaction.

from 3-factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor the digital signing represents something you have authentication (i.e. the originator has access to and use of the private key).

for lost/stolen countermeasure ... the private key may be protected in a hardware token and/or software file can require a PIN to operate.

the next level of detail for the relying party (financial responsible institution performing authentication, authorization and transaction execution) could be labeled parameterised risk management .... i.e. much lower level details regarding the integrity of the private key protection (i.e. evaluation level of any hardware token), environment and location that the transaction happened, other details of components involved in the transaction, etc.

part of the conventional, single round trip, straight-through processing financial transaction paradigm is a log as countermeasure for replay attacks. In many conventional, internet *chatty* protocols, one side includes a unique random number that the other party includes in subsequent transactions (as countermeasure to replay attacks). In the conventional, single round trip, straight-through processing model ... the originator makes the transaction reasonably unique (like including date/time, etc) and the relying party checks the current transaction against a log of previous transaction (as countermeasure to replay attack).

turns out that logs/audit trails as useful in general ... and frequently required anyway when performing financial transactions.

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 10:03:03 -0600
To: Nick Owen <nowen@xxxxxxxx>
CC: Ian Grigg <iang@xxxxxxxx>,  cryptography@xxxxxxxx,
"Steven M. Bellovin" <smb@xxxxxxxx>
Nick Owen wrote:
I think that the cost of two-factor authentication will plummet in the face of the volumes offered by e-banking. Also, the more uses for the token, the more shared the costs will be. The question to me is will the FIs go with a anything beyond secure cookies, IP address validation and unique images. Will they be forced to by the powers that be or by disclosure requirements after the basic systems are thwarted?

two-factor authentication per se, isn't necessarily the panecea.

pin-debit ... has a magstripe card as something you have and a pin as something you know. as recently mentioned, compromised ATM &/or POS machines have been able to skim the magstripe and the pin .... enabling creation of counterfeit cards and fraudulent transaction.

in x9.59,
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy

a hardware token can digitally sign the actual financial transaction. this would be single factor, something you have authentication. skimming and/or harvesting the transaction and/or transaction log files
https://www.garlic.com/~lynn/subintegrity.html#harvest

doesn't enable either counterfeit cards and/or fraudulent transactions.

the issue of a PIN, in conjunction with the magstripe card for two-factor authentication, was a countermeasure against lost/stolen card. However, skimming as a threat, is able to capture both the PIN and the card magstripe information, enabling fraudulent transactions.

a single-factor authentication hardware token (something you have) that digitally signs the transaction is sufficient countermeasure against skimming and harvesting.

Enforced PIN-debit ... i.e. where the magstripe can't be used w/o the PIN ... turns out to be a countermeasure against some of the transaction log harvesting (the type of data breach stories recently in the press) ... since the PIN information isn't normally carried in the transaction log. The issue with the transaction log is that there are several other merchant business processes that require access to transaction information.

The issue with magstripe and PINs ... is the threat and vulnerability model effectively is a replay attack ... static data that can be relatively easily recorded and repeated in fraudulent transactions (and/or used to create counterfeit magstripe).

A "single factor" authentication hardware token that digitally signs that transactions, is countermeasure against attacks recording static data for replay-type attacks.

Adding a PIN or biometric authentication to a hardware token for "two factor authentication" .... doesn't improve the countermeasure to skimming and harvesting attacks. The PIN or biometric authentication in conjunction with a hardware token is primarily countermeasure for lost/stolen token ... not countermeasure for skimming/harvesting replayable information.

There has been a separate issue with the use of pin/passwords shared-secrets
https://www.garlic.com/~lynn/subintegrity.html#secrets

for something you know authentication, is people having large number of different accounts .... each, supposedly requiring unique something you know shared-secrets. The estimate is that possibly 30percent of the debit cards have PINs written on them. The issue is basic human factors and blindly adding something you know shared-secret as a second authentication factor doesn't necessarily significantly improve the situation. so you are possibly faced with having to fundamentally rework some of the authentication landscape to compensate for well documented human short comings.

So two possible pieces for reworking this portion of the authentication landscape (for human factor shortcomings with proliferation of large number of shared-secrets)
  1. certified tokens that accept PINs for operation. the PINs are NOT shared-secrets since they don't travel past the token. The token is in the person's possession and the PIN is just for activating certified token operation. this can contribute to the person being able to initialize all tokens to the same PIN

  2. transition from institution-centric tokens to person-centric tokens ... aka rather than every institution in the world issuing a token ... and each token possibly requiring a unique PIN, people can acquire some small number of personal tokens and register their personal tokens for valid something you have authentication at different institutions.
A big issue in the recent data breach stories with respect to security PAIN acronym

P ... privacy
A ... authentication
I ... integirty
N ... non-repudiation

is that many of the infrastructures tend to have relatively strong integrity requirements for their business records. this protects the infrastructure business operations. however, they tend to have much lower privacy requirements ... in part because the large number of business processes that require access to those records. furthermore, the privacy threats and vulnerabilities isn't directly against the infrastructures .... the privacy threats and vulnerabilities are against their customers. This, then becomes, you offering to pay for all automobile repairs and maintenance for the rest of the people in your town ... because it improves the overall safety of the roads.

There is a large privacy threat and vulnerability for the customers of these institutions .... because of the pervasive use of static data for authentication and the readily available technology to record and replay/counterfeit that static data for fraudulent transactions.

So the privacy play is hard

... aka, this is related to the security proportional to risk posting
https://www.garlic.com/~lynn/2001h.html#61

where business operations have a frequent requirement to access the static data as part of normal business operations ... and the value of that data is proportional to the profit off an individual transactions. the business operations aren't directly at risk to the privacy threat and vulnerability. the entities having the privacy threat and vulnerability can be at risk equal to their credit limit (or their bank account).

Why Blockbuster looks at your ID

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Why Blockbuster looks at your ID.
Date: Sun, 10 Jul 2005 10:22:27 -0600
To: Perry E. Metzger <perry@xxxxxxxx>
CC: Dirk-Willem van Gulik <dirkx@xxxxxxxx>,  hadmut@xxxxxxxx,  cryptography@xxxxxxxx
Perry E. Metzger wrote:
Why does the clerk at Blockbuster want to see your driver's license? Because his management has been told, by their bank, that if they do not attempt to verify the identity of credit card users they will risk their business relationship with the bank. Credit card fraud is far too prevalent, DVDs are easily resold, and the bank wants to make sure that they won't get defrauded. Blockbuster also wants to minimize fraudulent use of credit cards (which they end up eating in some instances) and the loss of their property (which will never be returned by someone renting a video with a stolen credit card).

the issue is lost/stolen credit cards ... your name is embossed on the plastic and recorded on the mastripe. this provides for the point-of-sale to check for lost/stolen card by attempting the identification process of matching the name on the card with the name on something else.

this moves the card out of the relm of authentication into the relm of identification. there was a number of threads (mostly prior to 9/11) about EU privacy directives for making retail electronic transactions as anonymous as cash. basically this involved removing your name from the plastic embossing and magstripe ... so that the card was purely an authentication something you have .... and didn't wander across the line into identification. lost/stolen card risks then could be contained by deactivating accounts when the owner reported the card lost/stolen

part of the issue has been the appearance of skimming/harvesting compromises
https://www.garlic.com/~lynn/subintegrity.html#harvest

where the crooks didn't actually have to physically steal the card, they could electronically record the necessary information (w/o the owner's knowledge) and then perform fraudulent transactions. The skimming/harvesting compromises can involve tens of thousands of cards ... not just a single card at a time. Also, the fraud period instead of being limited to possibly a few hrs (when the owner reports the missing card), now could extend to a few weeks (since the owner doesn't notice unitl they get around to examining the next statement). The skimming/harvesting threat and vulnerability can magnify the fraud risk by several orders of magnitude (compared to simple lost/stolen).

Why Blockbuster looks at your ID

Refed: **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Why Blockbuster looks at your ID.
Date: Sun, 10 Jul 2005 10:33:01 -0600
To: Perry E. Metzger <perry@xxxxxxxx>
CC: Peter Fairbrother <zenadsl6186@xxxxxxxx>,
    cryptography@xxxxxxxx
Perry E. Metzger wrote:
If you have a sufficiently good token, you may no longer need to have identification information presented to the merchant, even by the token, to reduce misuse. It is true that the issuer will still know what transactions took place. However, you have at least reduced the number of entities that require proof of your identity and the number that have logs of your activity.

this is the EU privacy directive threads that went on (mostly prior to 9/11) and why couldn't they apply in the US also ... aka that electronic retail transactions could be as anonymous as cash. names would be removed from the plastic embossing and magstripe ... and the merchant would no longer have to wander across the line from authentication into identification (attempting to match the name on the card with other credentials).

when we started x9.59 in the mid-90s,
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy

we frequently commented that it was privacy agnostic. it provided strong authentication that didn't have skimming and harvesting threats and vulnerabilities. there was a strong correlation with some account number ... and the degree that there was some trail from that account number to an individual was dependent on a lot of things outside of the financial transaction itself. however, the basic financial transaction didn't require wandering across the line from authentication into identification.

this was also the period where it started to show up the shortcomings of the x.509 identity certification paradigm that had somewhat tried to get some toe hold in the early 90s .... including grossly overeloading the certificates with personal information. basically that every digitally signed transaction in the world would carry a huge x.509 identity certificate grossly overloaded with personal information. Not only would all such transactions carry such humongous personal information (while in flight) .... but all the transaction logs would be heavily burdened with the same information. An individual might appear in tens of thousands of transactions logs all over the world ... and every one would include a humongous x.509 identity certificate grossly overloaded with personal information.


AADS Postings and Posting Index,
next, previous - home