Misc AADS & X9.59 Discussions

AADS Postings and Posting Index, next, previous - home

Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Non-repudiation (was RE: The PAIN mnemonic)
Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
Non-repudiation (was RE: The PAIN mnemonic)
TWIST - Commercial Payments
Phillips, Visa push contactless payments in consumer devices
(federal) PKI spending hits $1b
Setting X.509 Policy Data in IE, IIS, Outlook
fraud and phishing attacks soar
are debit cards safe?
A combined EMV and ID card
A combined EMV and ID card
payment api for v1.0 internet open trading protocol ... fyi
PKI International Consortium
PKI International Consortium
PKI International Consortium
PKI International Consortium
PKI International Consortium
PKI International Consortium
Identity (was PKI International Consortium)
secret hackers to aid war on internet fraud
PKI International Consortium
Privacy, personally identifiable information, identity theft
Single Identity. Was: PKI International Consortium
privacy, authentication, identification, authorization
Re:Identity Firewall. l PKI International Consortium
Definitions of "Security"?
eCompute ECC2-109 Project has PROBABLE solution
eCompute ECC2-109 Project has PROBABLE solution (now official)
Payment system and security conference
visa cards violated, BofA reissuing after hack attack
misc from IETF
The future of security
Online credit card fraud rocks Indonesia
Yahoo releases internet standard draft for using DNS as public key server
Moving forward with pre-shared keys
Study: ID theft usually an inside job
The future of security
The future of security
Yahoo releases internet standard draft for using DNS as public key server
Article on passwords in Wired News
Is finding security holes a good idea?
Is finding security holes a good idea?
x9.99 financial PIA standard now available from ANSI e-store
authentication and authorization (was: Question on the state of the security industry)
authentication and authorization ... addenda
Japanese bank offers 'biosecurity' account
Use cash machines as little as possible
authentication and authorization (was: Question on the state of the security industry)
authentication and authorization
FUJITSU DEVELOPS ENCRYPTION TECH THAT TAKES 20 MILLION YEARS TO BREAK
Using crypto against Phishing, Spoofing and Spamming
Using crypto against Phishing, Spoofing and Spamming
Using crypto against Phishing, Spoofing and Spamming
Question on the state of the security industry
dual-use digital signature vulnerability
Using crypto against Phishing, Spoofing and Spamming
dual-use digital signature vulnerability
Using crypto against Phishing, Spoofing and Spamming

Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)<

Refed: **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: "McMeikan, Andrew" <Andrew.McMeikan@xxxxxxx>
Cc: "'Anne & Lynn Wheeler'" <lynn@xxxxxxxx>,
    "'cryptography@xxxxxxxxxx'" <cryptography@xxxxxxxxxx>
Subject: RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Date: Mon, 05 Jan 2004 08:34:12 -0700
At 03:10 PM 1/5/2004 +1100, McMeikan, Andrew wrote:
The only danger to such a world of peace would be those who refuse goverment signed keys and use their own payment provider and trade amounst themselves, they would have to be hunted down separately.

The original issue involves three factor authentication
http://www.garlic.com/~lynn/subintegrity.html#3factor A public key can be representative of hardware token ... say a token where the private key is generated on the token and is designed to never leave the token. A digital signature that can be verified by the corresponding public key can be used to infer possession of the hardware token (something you have). Furthermore, a hardware token can be designed to only work in a specific way when the appropriate pin/password (something you know) or biometric (something you are) have been entered into the token. The entity receiving the digital signature doesn't need a copy of the pin/password or biometric (making it a shared-secret) but infers by the operation of the hardware token that there has been something you know &/or something you are authentication to have happened.

An institution can enroll the person in possession of the token using whatever processes they feel necessary (say anonymous for ISPs up to "know your customer" identity as required by various legislation for financial institutions).

The issue is that can the validating of the entity in possession of the token be a separate business process issue from validating the integrity of the hardware token. The idea is that the integrity of the hardware token can be treated as a totally separate business process from the process of validating the entity being enrolled (an entity that happens to possess the hardware token).

Treating them as totally separate business process doesn't preclude collapsing the enrolling of the entity and enrolling the hardware token into a single process. However, not treating them as separate business process will pretty much preclude ever being able to treat them as separate processes.

So the question is as part of the enrolling process, can the integrity of the hardware token be treated as a totally separate business issue from enrolling characteristics of the entity in possession of the hardware token (say like the advertisements for the service that allows being able to research the history of a used car). Most institutions already have all sorts of business processes involved with enrolling the characteristics of an entity. What would be the incremental requirement for being able to enroll (& trust) the integrity of a consumer presented hardware token?

So, i'm a little bit biased, I claimed that I ruthlessly discarded all feature and function from AADS chip strawman that wasn't needed for trusted authentication
http://www.garlic.com/~lynn/x959.html#aadsstraw

complexity can contribute to insecurity ... KISS and focus can contribute to security.

Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

Refed: **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: "McMeikan, Andrew" <Andrew.McMeikan@xxxxxxx>
Cc: "'cryptography@xxxxxxxxxx'" <cryptography@xxxxxxxxxx>
Subject: RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Date: Mon, 05 Jan 2004 11:19:06 -0700
aka ... in some sense the reply
http://www.garlic.com/~lynn/aadsm17.htm#0 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

is also attempting to keep separate the business processes of identification and authentication. Will it continue to be allowed to have authentication events (i can prove that i'm authorized to do something) w/o also always mandating that whenever there is an authentication operation will proof of identity always also be required?

today, I supposedly can open an ISP account, provide proof of payment and supply a password for that account (w/o also having to provide a gene pattern for identification). Would it ever be possible to simply substitute a digital signature and public key in lieu of a password when opening an account (where that digital signature may have been performed by a hardware token)?

will it continue to be possible in the future to have separation between authentication and identification business processes ... or will at some time, things change and all authentication events also always require identification?

Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: <Andrew.McMeikan@xxxxxxx>
Cc: "'cryptography@xxxxxxxxxx'" <cryptography@xxxxxxxxxx>
Subject: RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Date: Tue, 06 Jan 2004 07:45:58 -0700
At 07:06 PM 1/6/2004 +1100, McMeikan, Andrew wrote:
This is the real bit, how tied to identity can it be bound. How tightly do people want to be bound. In any abuse or failing of identity whatever that identity was authorized for is going to be the *Responsibility* of the true identity. I frequently give out my true name (there it is at the top :) perhaps there are times I specifically do not.

a lot of current identity theft is evesdropping &/or otherwise harvesting shared-secrets and then doing replay attacks. part of this is that the prevalence of shared-secrets paradigm creates significant human factors problems with being able to memorize all the possibly scores of shared-secrets that are used as something you know authentication. the obvious is various kinds of skimming of real transactions and the harvesting of merchant payment transactions file to extract the shared-secrets sufficient to perform fraudulent financial transactions. two aspects of this:
  1. the transactions are based on static shared-secrets that are subject ... effectively to replaying the shared-secret
  2. a security guideline about requiring unique shared-secret for every security domain; so (among other things) that an authorized entity in one security domain can't extract your shared-secret and perform fraudulent transactions in another security domain (as simple as one employee at one merchant getting your shared-secret and performing fraudulent transaction at another merchant).
slightly related is posting about security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61

somewhat related issue is because of the human factor memory issue, a common authentication shared-secret (something you know) is mothers maiden name. The upside is that most people will tend to remember it. The downside is
  1. it really isn't all that secret
  2. using the same shared-secret in multiple different security domains violates the security principle requiring a unique (and preferably unpredictable) shared-secret in every security domain.
So, my assertion is that a significant amount of fraudulent activity that is currently labeled identity theft is really poorly implemented shared-secret, something you know authentication. Furthermore, various aspects of existing shared-secret implementations lends itself to electronic collection and/or harvesting of large batches of shared-secrets that, then in turn can be used in fraudulent transactions (significant fraud return-on-investment).

So one solution is significantly changing all such existing authentication transactions and turning them into identification transactions .... where the cost of faking the identification is significantly higher than the value of the fraudulent transactions.

Another solution is significantly changing the existing shared-secret authentication transactions and turning them into non-shared-secret authentication transactions ... where the cost of faking the authentication is significantly higher than the value of the fraudulent transactions.

I've frequently described the use of asymmetric cryptography and digital signature technology to infer something you have authentication because enrollment establishes 1) private key is contained in a specific hardware token and 2) characteristics can be established about the hardware token where it has generated a random key pair in the token and the token never voluntarily gives up the private key.

Enrollment may also establish that such a hardware token also works in a specific way when a unique pin/password and/or biometric has been passed to the token. Later when transactions arrive that are believe to have been digitally signed by such a hardware token, it may also be valid to infer that something you know and/or something you are authentication has also occurred (w/o the pin/password and/or the biometric needing to be passed to the authenticating institution and becoming a shared-secret).

It will probably always be possible to subvert various kinds of identification and/or authentication technologies. Two issues are:
  1. can such subversion be made more costly than any resulting risk/fraud
  2. can solution be authentication oriented as opposed to identification oriented
The second is possibly a bias towards not wanting to proliferate identity oriented events into each and every transaction that occurs in the world (when authentication may be sufficient).

With regard to the first point, the claim has been that X9.59 changes the existing retail electronic transactions from shared-secret based to non-shared-secret based ... and therefor eliminates the existing vulnerability of harvesting merchant transaction files as a threat (discussed in the security proportional to risk reference).
http://www.garlic.com/~lynn/x959.html#x959

Furthermore, as implied in the security proportional to risk reference, it may never be possible to eliminate the transaction file harvesting, what x9.59 did was eliminate the threat of fraud that results when such harvesting takes place.

Non-repudiation (was RE: The PAIN mnemonic)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Jerrold Leichter <jerrold.leichter@xxxxxxxxxx>
Cc: Cryptography <cryptography@xxxxxxxxxx>
Subject: Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Date: Wed, 07 Jan 2004 10:28:34 -0700
At 10:14 AM 1/7/2004 -0500, Jerrold Leichter wrote:
Now that we've trashed non-repudiation ... just how is it different from authentication? In both cases, there is a clear technical meaning (though as with anything in mathematics, when you get right down to it, the details are complex and may be important): To produce an authenticator/non-repudiable signature, you must have access to the secret. There isn't, at this level, even any difference between the requirements for the two. Where we get into trouble is in attempting to bind the real world to the mathematics. In each case, the receiver wants to be able to say:

lets say they are somewhat different threat models (but may have some partial overlap).

it would be possible to give a dozen people the same passprhase and have some degree of confidence that only the permitted entities entitled to do something were authenticated. however, if one of them claimed that they didn't do some specific thing ... there would be difficulty in differentiating between the different entities as to which entity had been authenticated at any specific time. some of the best practices security guidelines for authentication (like not sharing passwords) have more to do with non-repudiation ... than straight authentication.

key-escrow can be considered mandatory for encryption keys under non-single-point-of-failure and availability best practices. At the same time there may be mandatory requirements for NOT having key-escrow for authentication keys under non-repudiation best practices ... even when the cryptographic technology is identical. The key-escrow policies are exactly opposite depending on whether the business use is encryption or authentication.

a straight-forward authentication issue might be whether a particular message originated from authorized entity. That would not necessarily include the sense that the entity agreed with the terms and conditions described in the body of the message (say a financial transaction). This is somewhat akin to various EULA agreements that have people clicking on various buttons .... which is not an issue of authentication but of agreement; aka repudiation can include things that are outside the scope of authentication (not whether the message originated from me ... but "do i fully agree with what is included in the body of the message"). neither identification nor authentication by itself can necessarily include the concept of agreement. repudiation can include a number of items outside the sense of identification and authentication (like aggreement).

Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)

Refed: **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: "McMeikan, Andrew" <Andrew.McMeikan@xxxxxxx>
Cc: "'cryptography@xxxxxxxxxx'" <cryptography@xxxxxxxxxx>
Subject: RE: Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
Date: Thu, 08 Jan 2004 10:42:35 -0700
At 12:21 PM 1/8/2004 +1100, McMeikan, Andrew wrote:
Key word here is allowed, yes authentication without identification is possible, yes in my opinion it is desirable to allow, do I think it will stay that way, YES, do I think it will stay legal?? Well trends seem to indicate that it is becoming like a card carrying communist in the McCarthy era, dangerous if caught.

So allowed by whom? Should it be allowed that such things have to be allowed, or is it part of an inherent right to privacy that if only claimed by a large enough number of society might become the norm instead of suspicious.

two scenarios, sort of to be considered

1) x.509 identity certificates from the early '90s with all sorts of privacy information went thru a transformation into relying-party-only certificates for use in financial transactions; basically only entity information was some sort of account number and a public key ... plus a whole bunch of other gobbly-gook which still made the resulting certificate 4k-12k bytes ... and were supposedly to be attached to retail electronic payments that in their ISO8583 format tended to be 60-100 bytes in size ... aka a pki certificate represented a two orders of magnitude payload bloat. Furthermore, since the relying-party-only certificate was being transmitted back to the relying-party that issued the certificate ... which already possessed all the information contained in the certificate ... the two orders of magnitude payload bloat couldn't even be justified on providing any useful information that they didn't already have.
http://www.garlic.com/~lynn/subpubkey.html#rpo

2) HIPPA, GLB, FTC. etc .... have a bunch of stuff about disclosure of privacy information ... aka the type of stuff that would be typically associated with identity. authentication only wouldn't necessary preclude or mandate that the authentication information be linked to some sort of identity ... it just is that you wouldn't want the authentication event itself to include identity related information .... which could have a tendency to run afoul of various privacy regulatory and legislative issues (like HIPPA, GLB, and FTC).
http://www.garlic.com/~lynn/subpubkey.html#privacy

I've started a merged privacy taxonomy and glossary
http://www.garlic.com/~lynn/index.html#glosnote
taking some stuff from the merged security taxonomy and glossary ... but adding stuff from HIPPA, GLB, and FTC; somewhat in part because I've been participating in a X9 privacy standard effort.

Non-repudiation (was RE: The PAIN mnemonic)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - ** 
Date: Fri, 09 Jan 2004 15:21:32 -0700
To: iang@xxxxxxxxxxx
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Cc: Jerrold Leichter <jerrold.leichter@xxxxxxxxxx>, Cryptography <cryptography@xxxxxxxxxx>
At 01:18 PM 1/9/2004 -0500, Ian Grigg wrote:
Which is to stress the original problem: the technical side can identify an agent (a.k.a. a key) and it can transmit an authentication via some key-based protocol, but "agreement" is a human concept, drawn from the legal world in this context.

So the best that can be done is to record signals of agreement, but these can easily be faked, so they are just additional, quasi-worthless, steps in the protocol at the technical level.

Recording signals of agreement is like recording a handwritten signature. It is not conclusive as it can be easily forged. But, the (legal) protocol includes some additional steps such as asking "did you make that signature?" In this sense, the protocol of agreement can only be completed in the realm of dispute, by confirming the steps that the human made with the memorable tokens done at that time.

my understanding is that most of the EULA issues aren't about whether it is possible to fake or not fake the pressing the buttons ... but whether it is reasonable that the person clicking the buttons could have reasonably believed that they were doing something else.

protocols can have a piece of hardware digitally signing a message as part of authentication ... w/o implying anything at all about agreement. using the EULA example, if a process step is used for anything other than agreement ... then the claim could be made that can be inferred as the other process (authentication?) and not agreement.

you also somewhat see that in POS terminal debit transactions .... the PIN is entered as part of authentication .... but there are additional YES/NO button pressings that is required ... that is part of inferring agreement ... and independent of authentication.

TWIST - Commercial Payments

From: Lynn Wheeler
Date: 01/12/2004 06:37 AM
To: 'internet-payments' <internet-payments@xxxxxxxxxx>
Subject: TWIST - Commercial Payments
ran across this when using search engines looking for some non-US glossary sources
http://web.archive.org/web/20040116021358/http://www.ateb.be/doc/doc-6-108-3.pdf

As described in the document, TWIST draws on efforts from CRG/Edifact, IFX, RosettaNet and SWIFT (consumer to bank messages).

from above:

Seven major international banks (ABN-AMRO bank, Bank of America, Citigroup, Deutsche Bank, HSBC, JPMorgan Chase, Standard Chartered Bank) have worked in a TWIST taskforce together with other industry experts that are members of TWIST to ensure universal applicability of the requirements. Their involvement has been instrumental for the speed and thoroughness of the analysis, for the neutrality of the design, the universal applicability of the solutions and the critical mass that ensures the necessary implementation effort in the near future. This collaboration effort has been further benefited from the knowledgeable input of various experts from consultancy firms, software providers and corporations. All involved in TWIST support the need for universal, open and non-proprietary standards. The TWIST task force led by Ernst & Young and Shell aims at driving at one single, open, and non-proprietary standard that can be implemented by any corporate and bank, irrespective of size, location, or market position.

Phillips, Visa push contactless payments in consumer devices

From: Lynn Wheeler
Date: 01/12/2004 10:37 AM
To: 'internet-payments' <internet-payments@xxxxxxxxxx>
Subject: Phillips, Visa push contactless payments in consumer devices
http://www.eetimes.com/sys/news/OEG20040112S0009
Philips, Visa push contactless payments in consumer devices

By Junko Yoshida
EE Times
January 12, 2004 (10:01 a.m. ET)  

LAS VEGAS Philips Semiconductors and Visa International joined forces at the Consumer Electronics Show (CES) last week to demonstrate contactless payment and connectivity applications based on a Philips-developed technology called near-field communication.

Their goal is to build an infrastructure for universal payment card readers in consumer electronics and mobile telecommunication devices. Philips will embed NFC chips in various consumer devices while Visa provides an authentication service. Under the plan, consumers should be able to download data or pay for digital services through the NFC interface using a contactless card or device with NFC-equipped consumer equipment.

... snip ..

(federal) PKI spending hits $1b

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Cryptography <cryptography@xxxxxxxxxx>
Subject: (federal) PKI spending hits $1b
Date: Fri, 16 Jan 2004 11:41:00 -0700
(federal) PKI spending hits $1b
http://web.archive.org/web/20040215095737/http://www.washingtontechnology.com/news/1_1/daily_news/22526-1.html

GAO Faults 'inconsistent' online security programs ($1b on PKIs)
http://www.informationweek.com/story/showArticle.jhtml?articleID=17301563

Setting X.509 Policy Data in IE, IIS, Outlook

Refed: **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
Date: 01/27/2004 02:09 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxxxxxx>
cc: ietf-pkix@xxxxxxxxx, "Stephen Kent" <kent@xxxxxxxxxx>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
Another issue is that many of the traditional business trust models have tended to be some sort of contract (exchange of value) between two parties; supposedly the CA trust propagation relationship typically is between the relying party and the CA ... while the contractual relationship is between the public key owner and the CA (except for situations like relying-party-only certificates .... where the same party is both selling/issuing the certificates and also relying on the certificates) .... aka the trust propagation relationship and the contractual trust relationship are unrelated.

another solution has been to try and have some sort of governmental legislative proclamation ... declaring/mandating a trust relationship ... even if one doesn't exist from a business and/or contractual standpoint.

the gsa federal government PKI .... seems to be a variation on the relying-party-only certificate .... the CAs appear to have a GSA contract where they effectively are agents of the federal government (i.e. the CAs are federal agents issuing/selling certificates on behalf of the federal government). These certificates are then for use by the federal government as the relying party (making them relying-party certificates).

now, the next issue is that the majority of the federal PKI programs appear to be online operation ... which in turn would supposedly allow the relying-party federal government ... to have online access to the original of the information where the relying-party-only certificate represents a stale, static copy of some such information stored in some databsse. Also, possibly because of privacy issues, the stale, static (certificate) copy is likely also a subset of the information that is actually stored in some database (collected at the time the registration authority function was performed involving the registration of the public key and information about the owner of the public key). One possible issue is that the operations being performed in conjunction with the federal PKI program certificates are of such low value, that it doesn't justify having online, timely access to the real information (even when it appears that all of the applications in the program are otherwise online) ... aka long-time assertion that relying-party, stale, static, subset certificate information tends to be redundant and superfluous given that there can be online access to the original, timely information.

on 1/27/2004 12:27 pm anders.rundgren wrote:
May I help you with some analysis?

PKI projects historically started with the CA, and this has influenced some PKI standards as well, the RFC3280 policy support is a prime example of that.

However, being a CA, is being an "information producer" which is considerably easier than being an "information consumer" as only the latter has to "interpret" and maybe "act" upon what the information producer says.

If the designers of the policy system instead had focused on the relying party (the "information consumer"), they had probably realized that a relying party consists of 1) the relying party software 2) the people depending on the relying party software.

Further analysis shows that the "people" category, except in the most trivial scenarios, consists of "trust administrators" and "end users". In the background there are also some legal folks lurking around.

If you then apply the design constraint that all these entities should have the best possible system adapted for the entities' actual tasks and competence, you would end-up with a very different policy scheme.

Commercial CAs know that, and therefore with few exceptions, continue to ignore a system that was not designed with the "customer in mind".

The major difference is that policy in commercial CAs is associated with the CA, eliminating the need for moving trust processing and trust administration tasks into the application and user domains respectively. This enables the creation of shrink-wrap RP software as well as shielding end-users from too close encounters with PKI.

This also allows trust admins to anytime, using "CA properties", view what "they actually currently trust", without having a single EE certificate!

Anders

fraud and phishing attacks soar

From: Lynn Wheeler
Date: 02/18/2004 07:15 AM
To: 'internet-payments' <internet-payments@xxxxxxxxxx>
Subject: fraud and phishing attacks soar
Fraud and phishing attacks soar
http://www.vnunet.com/News/1152838
Email fraud and phishing attacks rocketed by more than 50 per cent in January, with around six new attacks sent to millions of consumers each day.
... snip ...

are debit cards safe?

From: Lynn Wheeler
Date: 02/18/2004 07:17 AM
To: 'internet-payments' <internet-payments@xxxxxxxxxx>
Subject: are debit cards safe?
are debit cards safe?
http://www.globetechnology.com/servlet/story/RTGAM.20040204.gtkirwanfeb4/BNStory/Technology/
ATM fraud in the U.S. is believed to have totalled $2-billion (U.S.) in 2002, and in the U.K. to have risen 37 per cent to 29.1-million pounds, up from 21.2-million pounds. And how do criminals steal from ATMs?
... snip ...

A combined EMV and ID card

Refed: **, - **, - **, - ** 
From: Lynn Wheeler
Date: 03/14/2004 11:12 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxxxxxx>
cc: 'internet-payments' <internet-payments@xxxxxxxxxx>,
     Pekka Honkanen <lhonkane@xxxxxxxx>
Subject: Re: A combined EMV and ID card
that was one of the issues that financial institutions and others discovered ten years about the x.509 identity certificate concept ... the horrendous leakage of privacy information. it was one of the reasons that financial institutions tried relying-party-only certificates in the mid-90s that was restricted to only containing an account number (in part because of the horrible privacy information leakage).

at least one of the scenarios involved relying-party-only certificate appended to a digitally signed credit/debit payment transaction. This in itself created an enormous difficulty resulting in various kinds of extreme rube golberg designs. the issue was that a typical 8583 financial transactions was on the order of 60-80 bytes, ignoring for the moment the size of an appended digital signature .... the problem was that even a relying-party-only certificate could be 6k-12kbytes in size. Using elementary, standard security principles and following standard end-to-end security and integrity policies .... aka digitally signed message with appended relying-party-only certificate flowing from consumer straight-through to the consumer's issuing financial institution resulted in a 100 times bloat in the message size aka 60-80 byte message would have a tremendous, horrible bloat to one hundred times larger ( aka typically message of 60 bytes times 100 becomes six thousand bytes to twelve thousand bytes).

this is one of the places that originated my observation about a relying-party-only certificate being redundant and superfluous (in addition to truely horrible size bloat). The useful information in the 12kbyte relying-party-only certificate is the user's public key and the account number. Since the account number is also contained in the 8583 transaction, it is redundant and superfluous to have it in the certificate. Since it is a relying-party-only certificate, the user's public key is registered in the institutions account record for that user. When the 8583 transaction reaches the institution, they can retrieve the public key from the account record based on the account number in the 8583 transaction (to verify the digital signature). That makes the public key in the relying-party-only certificate redundant and superfluous. With the only two pieces of useful information in the relying-party-only certificate shown to be redundant and superfluous, then the certificate itself is shown to be redundant and superfluous.

Rather than coming up with a rube goldberg design corrupting elementary, basic end-to-end security and integrity principles in support of one hundreds times bloat in message size (attempt to preserve the appending of a redundant and superfluous certificate) .... just eliminate the redundant and superfluous certificate altogether.

misc. past postings on relying-party-only certificates:
http://www.garlic.com/~lynn/subpubkey.html#rpo
misc. past postings on the subject:
http://www.garlic.com/~lynn/subpubkey.html#privacy

as an aside ... somewhat in support of work on X9 PIA standard ... I've started a privacy glossary and taxonomy .... complimenting the other glossaries and taxonomies at:
http://www.garlic.com/~lynn/index.html#glosnote

annders rundgren on 3/14/2004 12:13 pm wrote
Thanx Pekka,
A slightly disturbing "side effect" of mixing accounts and IDs using the Finish and Swedish schemes, is that each time you perform a payment, the POS terminal can without any PIN-codes etc, also read the user's ID- certificates (public keys), effectively "leaking" identity information to parties that should not necessarily have such information.
Anders --
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

A combined EMV and ID card

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
Date: 03/15/2004 12:52 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxxxxxx>
cc: 'internet-payments' <internet-payments@xxxxxxxxxx>,
    Pekka Honkanen <lhonkane@xxxxxxxx>
Subject: Re: A combined EMV and ID card
sporadic problem is confusing authentication and identification. there are various gov. requirements that may require identification as part of account establishment but that shouldn't translate into requirement for identification for every transaction related to such account. transactions (like payments) have requirements where authentication should be sufficient w/o involving identification and all the privacy problems that creates.

note that many of the existing payment cards are subject to transaction skimming and subsequently using the information to create counterfeit cards.... even the EMV yes cards that have been cited in various press on the other side of the atlantic pond.

there can be a number of issues with using a single hardware token for both payment and non-payment purposes with detrimental information leagage between the two domains. primarily the problems happen when the design of the infrastructure involves static data (of the kind that is subject to skimming with the possibility of later using the skimmed information forfraudulent purposes). However, it is possible to design an infrastructure that doesn't involve the kind of static information that can be subject to skimming and fraudulent use.

One such solution is to design an infrastructure around secure authentication as a business process .... regardless of the type of business operation (payment, non-payment, etc). An additional objective might be to avoid shared-secrets (where elementary security principles require unique shared-secret for every distinct security domain). A shared-secret could be PINs, passowords, or even physical keys (aka you typically don't have a house key also being used for entry to an employer's business location) ... aka a single, shared-secret based device that was used in multiple different security domains is subject to possibility of information leakage that could be used by one domain to compromise a different domain.

misc. past posts discussing confusing authentication and identification
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#2 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#4 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aadsm14.htm#40 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
http://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings

anders rundgren on 3/15/2004 1:39 am wrote:

Lynn,
You are right but the financial institutions now try to leverage their position as trusted third parties for things outside of their payment territory. It is hard to see that e-governments can be realized without a generic ID without huge costs and user inconvenience. As I have said numerous times before in this list:

ID <> Payments

But I would also like to mention my addendum

ID >> Payments

That is, a functional ID can in an on-line world replace the need for most other resources as you by using an ID towards resource providers "can be whatever you need to be, or have what you need to have".

To combine ID and Payment cards though opens a can of worms. If the consumer uses the same PIN for all functions a rogue relying party app can technically perform advanced "phishing" in the background while you are paying. Most people don't like multiple PIN-codes. I'm one :-)

Anders

-- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

payment api for v1.0 internet open trading protocol ... fyi

From: Lynn Wheeler
Date: 03/26/2004 09:37 AM
To: 'internet-payments' <internet-payments@xxxxxxxxxx>
Subject: payment api for v1.0 internet open trading protocol ... fyi
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF.

Title : Payment API for v1.0 Internet Open Trading Protocol (IOTP)
Author(s) : W. Hans, et al.
Filename : draft-ietf-trade-iotp-v1.0-papi-06.txt
Pages : 103
Date : 2004-3-25

The Internet Open Trading Protocol provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules.

A URL for this Internet-Draft is:
http://web.archive.org/web/20040404155551/http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-06.txt

PKI International Consortium

From: Lynn Wheeler
Date: 04/02/2004 11:49 AM
To: Shaheen.Nasirudheen@xxxxxxxx
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
     "PKIX list" <ietf-pkix@xxxxxxxxx>, owner-ietf-pkix@xxxxxxxxxx
Subject: Re: PKI International Consortium
sort of the fundamental issue is that the certificate design point is for offline processing .... it contains sufficient information that it is possible for the relying party to perform some operation based on relying on the certificate w/o needing recourse to any additional information.

the problem is also sort of analogous to the issue of needing different shared-secrets for different security domains ... recent topic drift in sci.scrypt ...
http://www.garlic.com/~lynn/2004d.html#40 RFC-2898 Appendix B

lets say i have a passport certificate and i wish to do a financial transaction on a chase bank account. the passport certificate probably doesn't provide any information with regard to whether i even have a financial account with chase bank .... aka the passport certificate contains insufficient information for a relying party expecting a valid financial transaction.

so for an offline certificate paradigm to work .... it just about means a unique certificate for every operational domain ... containing sufficient information that a relying party will go ahead and do whatever operation based on the contents of the certificate.

now, if the relying party really wants a financial transaction executed with chase .... then there is not only the issue of the contents of a stale, static certificate designed as a solution for offline environments ... but there is the possibility that the relying party might be interested in online, timely, and possibly aggregated information (not conducive for incorporation in a stale, static certificate designed for solving problems associated with offline environments) ... in which case, the relying party might be inclined to perform a online operation with the authoritative agency for that particular kind of operation. In the case of a customer financial transaction, the relying party might be interested in performing a financial transaction with the customer's financial institution (as the authoritative agency for that kind of operation).

For this type of scenario, it is then possible to claim for valuable and/or important operations (where relying parties may be interested in timely information, as opposed to stale, static information possibly contained in a certificate), that direclty contacting the authoritative agency makes the use of stale, static certificates redundant and superfluous. If the authoritative agency has registered a public key and issued a stale, static certificate .... then if the relying party is directly contacting the authoritative agency ... the substitute stale, static certificate (issued for addressing the needs of offline operations) is redundant and superfluous.

shaheen nasirudheen on 4/2/2004 8:57 am wrote:
Hello everyone,

I appreciate your feedback and most of the replies were referring to identrus.com . My basic concern is from a customer's point of view. If I have a digital certificate issued by a single authority that is considered trusted internationally by all financial as well as other commercial institutions, then I do not require to have a certificate for Institution -1 and another for Institution -2. Do we have something in place that takes of this issue. I would be happy to carry and protect that one certificate which is trusted by everyone.

Thank you,

Shaheen Nasirudheen
JPMorgan ACCESS, Portal Security
978 805 1815

Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

PKI International Consortium

Refed: **, - **, - ** 
From: Lynn Wheeler
Date: 04/02/2004 04:46 PM
To: Arshad Noor <arshad.noor@xxxxxxxxxx>
cc: PKIX list <ietf-pkix@xxxxxxxxx>, Stephen Kent <kent@xxxxxxxxxx>,
    owner-ietf-pkix@xxxxxxxxxx, Shaheen.Nasirudheen@xxxxxxxx
Subject: Re: PKI International Consortium
it isn't necessarily just authentication that a relying party may have to worry about with regard to the operation that they might be trusting the certificate for .... but also things like authorization. the concept of a certificate is that the relying party can trust the certificate in an offline environment w/o necessarily any recourse to any additional information.

the issue of recourse to additional information may because of things like

1) privacy .... the early x.509 "identity" certificates were found to represent signficiant privacy compromise, especially when broadcasting all over the place. as a result, there was retrenchement to relying-party-only certificates .... where it was sufficient to authenticate the entity as being authorized to perform some set of operations against some account record.

2) value ... the transaction is of sufficient value and/or complexity that it is worthwhile to perform a online transaction (as opposed to an offline operation purely relying on the contents of a certificate).

Note, however, that majority of relying-party-only certificates were used in operations involving some value and therefor justified an online operation with access to timely and/or aggregated information (aka sufficient funds to actually cover a financial transaction).

3) authorization ... the issue may not have anything at all to do with your identity, but whether or not you can be authenticated (not identified) as being an authorized employee or an authorized individual to perform transactions against a specific bank account. Just because I can prove I'm John Smith ... isn't sufficient to establish that I'm an authorized employee of any specific corporation and therefor entitled to enter an employee only area.

It isn't context-sensitive identity infrastructure ... they require context-sensitive authorization (although sometimes there is significant confusion and institutions build identity infrastructures that are totally orthogonal to their need for authenticationa and authorization infrastructures).

In many of these situations, then stale, static certificates can be totally redundant and superfluous ... either because they are providing information that has no direct bearing on the operation being performed by the relying party and/or because the relying party will be doing an online operation with the authoritative agency providing real-time and/or aggregated information (not possible with a stale, static, offline certificate).

arshad noor on 4/2/2004 2:39 pm wrote:
I would concur with you, Steve, that a single certificate that serves all purposes, is neither practical nor desirable. (Although I must confess to occassionally dreaming of such a utopian environment, sometimes).

However, I believe, it is reasonable - assuming appropriate policy, process, implementation and most importantly, cooperation - to have industry-specific identities that may serve us all better. ("Identity Firewalls" - http://www.xxxxxxxxxx/newsletters/2003Jan17.html ).

Companies waste far too much time and money today, building duplicate identity infrastructures - and consequently tying their own hands with context-sensitive identities - because it appears to be the path of least resistance to them. But as the cost of identity theft & of managing those numerous identity infrastructures surpasses the perceived savings from using this path of least resistance, companies will be forced to rethink that strategy.

Arshad Noor
StrongAuth, Inc.

PKI International Consortium

Refed: **, - **, - ** 
From: Lynn Wheeler
Date: 04/02/2004 05:11 PM
To: Shaheen.Nasirudheen@xxxxxxxx
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
    Arshad Noor <arshad.noor@xxxxxxxxxx>,
    PKIX list <ietf-pkix@xxxxxxxxx>, Stephen Kent <kent@xxxxxxxxxx>
Subject: Re: PKI International Consortium
The arpanet was a traditional, homogeneous network ... that happen to be a packet-switch implementation rather than circuit-switch implementation. Note however, it was NOT an internet. It corresponded much closer to the standard OSI model of homogeneous infrastructure (but having a packet orientation rather than a circuit orientation).

I've claimed that one of the reasons that the internal network was larger than the arpaent for all of that period ... was that the internal network had effectively the equivalent of a gateway built into every node ... allowing support for heterogenous networking. The great switch-over from arpanet to internet occured on 1/1/83 ... with the introduction of internetworking .... a "layer" that doesn't even exist in the OSI model (sitting somewhere between layer3/networking and layer4/transport). At that time of the switchover the arpanet was around 250 nodes and the internal network was nearly 1000 nodes. The combination of internetworking, heterogeneous networking support, gateways, and the appearance of PCs and workstations as internet network nodes resulted in the internet eventually exceeding the number of nodes on the internal network sometime around mid-85.

misc. past posts related to arpanet, csnet, nsfnet, internet, internet switch-over and the internal network:
http://www.garlic.com/~lynn/internet.htm

a story not related in the above was some corporate type doing technology audit in the late 70s and being told about the size of the internal network. the person supposedly wrote a report stating that it was impossible ... because to build a network of that size using traditional homogeneous networking technology (common at the time) would have required more people total than had been working for the corporation over the previous ten years.

misc. past posts related to OSI, arpanet, iso, etc:
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
the above mentions another issue w/OSI. attempting to get HSP (high-speed protocol) work item in X3S3.3 (iso chartered us standards organization responsible for networking and transport layer standards). The problem was that ISO had a rule that there couldn't be standards work on protocols in this area that violated OSI. HSP was going to go directly from level4/transport to the MAC interface. This violated OSI in two respects 1) it bypassed the level3/level4 interface and 2) it interfaced to MAC layer. LANs/WANs/MAC are a violation of OSI with the MAC layer sitting somewhere in the middle of layer3/networking. Because of the OSI violation rule, X3S3.3 rejected the work item.

in late '69, i did get involved in a project as an undergraduate building a telecommunication controller using an Interdata/3. this resulted in later getting blamed for helping create the plug-compatible manufacturing (PCM) controller business:
http://www.garlic.com/~lynn/subtopic.html#360pcm

shaheen nasirudheen on 4/2/2004 3:37 pm wrote:
Hello everyone,

Quote from bbn.com : "In 1968, the Advanced Research Projects Agency (ARPA) sent out a Request for Quotation (RFQ) to build a network of four Interface Message Processors (IMPs). Many of the large computer and telecommunications organizations didn't even respond--they thought it was impossible. " -
http://web.archive.org/web/20020603123655/http://www.bbn.com/arpanet/index.html If the pioneers believed that "Internet" is impossible, then I dont think we would enjoy sending these emails today.

PKI International Consortium

Refed: **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
Date: 04/03/2004 08:21 AM
To: Arshad Noor <arshad.noor@xxxxxxxxxx>
cc: PKIX list <ietf-pkix@xxxxxxxxx>, owner-ietf-pkix@xxxxxxxxxx
Subject: Re: PKI International Consortium
An example with slight variation on this was some EU directive that electronic payments at point-of-sale should be as anonymous as cash, aka it should be possible to authenticate a transaction for authorization w/o requiring any identification what-so-ever.

The issue is that if you have some sort of authentication, aka something you have, something you know, something you are .... and possibly non-shared-secret based ... it is possible to have an authorization context that just does authentication and no identification is involved.

it that case, if there is an authorization context ... with some recorded authentication mechanism ... then the authentication is bound to the authorization context and there is no identification at all.

in such a taxonomy .... a certificate represents a stale, static, authorization context for offline environments ... where the public key is the authentication mechanism bound to the authorization context. The authentication mechanism is some form of something you have .... based on uniquely having a private key that generates a digital signature that can authenticated with the public key. This is basically the scenario for the relying-party-only certificates from the mid-90s (somewhat resulting from retrenching from the horrible privacy issues of full blown x.509 identity certificates). Note, however, it isn't the certificate that creates the something you have associated with the private key, the certificate provides the portable, stale, static authorization context for offline environments. It is equally possible to have an online environment where the public key is bound to an online authorization mechanism and no certificates are involved at all. The online payment point-of-sale transactions with relying-party-only certificates exemplified redundant and superfluous. The transaction was valuable enough that timely and aggregated online information was deemed justified (the benefit of having an online, timely transaction more than offset the incremental cost of having an online transaction) .... but a relying-party-only certificate was provided such that there could be an offline authorization context .... but that was then made redundant and superfluous by having the transaction executed online with an online authorization context.

The example I've used for identity is the problems with issuing SSL server domain certificates. The authoritative agency for domain names is the domain name infrastructure. The typical process for obtaining an SSL server domain certificate is to provide very strong identification information to the SSL certificate issuer. The issue is that the domain name infrastructure has some identification information registered for the owner of the domain name. The challenge for the SSL certificate issuer is to be able to perform some level of identification matching from what is provided by the certificate applicant with the identification that is on file for the domain name owner. The reason for the identification operation is that there is no industry-specific authentication. This (lack and resorting to identification) turns out to be expensive and somewhat error prone.

A suggestion (somewhat from the certificate industry) is that a public key is registered with the domain name infrastructure when the domain name is registered. Then when somebody applies for a certificate, they digitally sign the operation. The certificate issuer then just needs an online authentication of the digital signature with what is on file with the domain name infrastructure and a very expensive and error-prone identification process is turned into a much simpler and less expensive industry-specific authentication operation. There is an implied authorization that the owner of the domain name is allowed to obtain an SSL domain certificate for that domain name.

Of course, there is possibly a slight catch-22 for the SSL certificate industry ... that if the certificate industry can make use of online public keys from the domain name infrastructure .... that possibly the rest of the world could also ... leading to possibly eliminating the need for SSL domain name certificates with stale, static certificates binding public keys to domain names.

arshad noor on 4/2/2004 8:49 pm wrote:
I am in complete agreement with you, Lynn. An industry-specifc identity should be designed to perform only a single function - authenticate the holder of the credential. Authorization must ALWAYS be determined by the context that has successfully authenticated the entity - and those authorization rules must always be owned and controlled by the context owner.

PKI International Consortium

Refed: **, - **, - **, - **, - ** 
From: lynn.wheeeler@xxxxxxxx
Date: 04/04/2004 09:01 AM
To: amg@xxxxxxxx
cc: amg@xxxxxxxx, PKIX list <ietf-pkix@xxxxxxxxx>,
    owner-ietf-pkix@xxxxxxxxxx
Subject: Re: PKI International Consortium
The use of relying-party-only certificates were done in large part because of privacy issues ... which could be

• personal privacy issues with identity information
• personal privacy issues with personal attributes
• institutional sensitivity/privacy issues with institutional attributes

However, for a relying party that used an index/account number from a relying-party-only certificate to index an entity entry in a repository or access an online service, it can be shown that the stale, static replying-party-only certificate is redundant and superfluous. The issue is that the relying party is retrieving attributes and/or authorization from the online service and/or an entity entry from their own respository ... and, in effect, a public key bound to an entity is then just another personal attribute. A public key personal attribute is safely stored in an entity's entry in a repository just like any other personal attribute, no matter how many PKI infrastructures may wish to infuse public keys with mystical properties (alhtough public key can be a non-shared-secret where so many other attributes take on shared-secret properties).

One scenario is FAST project that was being done by FSTC
http://www.fstc.org/
this basically attempted to leverage the 8583 real-time infrastructures to provide real-time yes/no answers about things other than authorizing financial transaction.

For instance, rather than having an attribute certificate with date-of-birth (which currently represents a identity theft vulnerability) to establish whether a person is younger/older than 18 .... an entity would sign a age level question, much in the same way they might sign a x9.59 financial transaction. This is then sent off to the financial institution, which decodes it and replies yes/no to the relying party. The FI maintains a repository entry for the entity ... including things like timely, sensitive and/or aggregated information. The FI can answer questions about younger/older than 18 (w/o having to reveal date-of-birth) or answer yes/no to a financial transaction w/o having to reveal credit limit or current balance.

The current issue is that things like identity theft vulnerabilities aren't limited to just identity, but can include other personal attributes as well; in fact could include any attribute that might potentially be used as part of a shared-secret paradigm. Also sensitivity of attributes may not be just be limited to personal attributes, but may also include institutional sensitivity regarding institutional attributes.

amg wrote:
Hi,

> If a relying party needs to know that I possess certain
> attributes, and if I can present an "Attribute Certificate" that
> convinces them that I do indeed possess those attributes, then what
> purpose is served by also having me present an "Identity Certificate"?

You are completely right, Eric. There are many situations that require the knowledge of certain attributes but do not require knowledge of identity. For instance, accesing the Playboy should require knowledge of the user being over 18, but no identity information should be revealed.

PKI International Consortium

From: Lynn Wheeler
Date: 04/04/2004 08:28 PM
To: "todd glassey" <todd.glassey@xxxxxxxx>
cc: "Arshad Noor" <arshad.noor@xxxxxxxxxx>, "PKIX list" <ietf-pkix@xxxxxxxxx>, owner-ietf-pkix@xxxxxxxxxx
Subject: Re: PKI International Consortium
the EU directive just said something about being as anonymous as cash .... in general the privacy mandates signficantly reduce the run of the mill phishing .... it is somewhat like cryptography .... some cryptography is secure for all but the most determined government operations.

it is possible to make account number electronic financial transactions like x9.59
http://www.garlic.com/~lynn/x959.html#x959
.... authenticated but not identified.

In that sense they become pretty agnostic with respect to identification. Governments are able to mandate "know your customer" rules for the accounts ... which given the appropriate government action can extract all sorts of details. However, it doesn't preclude other governments allowing purely anonymous accounts.

todd glassey wrote:
Lynn - good commentary - but I also want to add that cash transactions are not anonymous in that they leave finger prints and they survived this "reduction in their anonymity" after the adoption of fingerprinting by law enforcement... i.e. Someone handles the money and there is all kind of tangible evidence left, the issue is the cost of collecting and maintaining it.

Todd

Identity (was PKI International Consortium)

Refed: **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
Date: 04/04/2004 08:57 PM
To: Eric Norman <ejnorman@xxxxxxxx>
cc: PKIX list <ietf-pkix@xxxxxxxxx>, owner-ietf-pkix@xxxxxxxxxx
Subject: Re: Identity (was PKI International Consortium)
I've lately been busy working on X9.99 financial industry financial standard for privacy, learning more than i want to do about EU-DPD, GLB and HiPPA, etc. Somewhat to complement the merged security taxonomy & glossary work:
http://www.garlic.com/~lynn/index.html#glosnote

I've started a merged privacy taxonomy & glossary ... pulling from EU data privacy directive, GLB, HiPPA, OMB, FTC and a couple others.

My earlier statement was that there was significant retrenchment from the X.509 Identity certificates of the early '90s because of the serious privacy issues that the information represented. The issue wasn't so much what features in X.509 Identity certificates were related to identity ... but what features in X.509 identity certificates that raised serious privacy issues. EU-DPD, HiPPA, and GLB have issues about PHI (protected health information) and PII (personally identifiable information) and sensitive perosnally identifiable information.

From their standpoint, it isn't so much identity information per se ... it is any kind of personal information that adversely affect a person's quality of living (like fraud, phishing, identity theft, etc).

In the past i've defined a taxonomy for authentication information and certificates. In effect, there is some entity information that is registered someplace ... likely at a certificate issuer ... but possibly someplace else. The certificate issuer packages up a R/O copy of that information and creates a static certificate containing that information and distributes it (or at least returns the r/o copy of the information, i.e. the certificate to the entity requesting the certificate). The certificate by its very nature is static ... the digital signature of the certificate issuer goes to a great deal of trouble to establish it as static (and if it ever does change ... the certificate becomes invalid).

The certificate is, in a way, a high-integrity, static, r/o cached copy of some information stored some place else. This allows it to be used in an offline process when the relying-party doesn't otherwise have recourse to the original information.

In that sense, it is directly analogous to CPU r/o cached entries, or filesystem r/o cached records, or database r/o cached entriess.

Once the cached copy (certificate) is distributed, it by definition is stale ... representing the state of some record at some time in the past. The information contained in the cached certificate/copy may or may not be stale, but by definition the certificate itself is stale.

So therefor, I assert that it is perfectly reasonable to refer to certificates as static and stale (regardless of whether or not the information contained within the certificate has yet become stale).

One point in using the characteristics static and stale to describe the certificate paradigm .... is to highlight that certificates are in effect, r/o cached entries of some other information. It makes a distinction between the information that might be contained in a certificate from the certificate paradigm itself. There has been a lot of work on the basic nature of cached information ... which i believe is applicable to the certificate paradigm. That work is totally orthogonal to the nature of the information itself (that might be contained in a certificate).

ejnorman wrote:
Well, my opinion is that you won't have much luck dealing with "Identity issues" until you have a good definition of "identity".

Here's my shot at it. If you start from the premise that identity is just a set of attributes, then your identity is those attributes that are constant and last forever.

So, my "Identity certificate" asserts an association between me and the University of Wisconsin. Is that part of my identity? It depends on how you interpret that assertion. If you interpret it as "was at one time affiliated with that university", then that lasts forever and it is (Winston Smith to the contrary). If you interpret it as "is currently affiliated...", then it isn't.

The only observation I can make right now is that with the former interpretation, Lynn Wheeler doesn't get to use the adjectives "stale" and "static". Whether that's any more useful than counting angels dancing on pinheads remains to be seen, I suppose.

secret hackers to aid war on internet fraud

From: Lynn Wheeler
Date: 04/05/2004 08:35 AM
To: internet-payments@xxxxxxxxxx
Subject: secret hackers to aid war on internet fraud
note somewhat related to below:
http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk

http://www.timesonline.co.uk/article/0,,5-1063208,00.html
April 05, 2004
By Joe Morgan

FEARS that small online retailers are the weakest link in the fight against internet fraud have prompted MasterCard, the global payment scheme group, to set up secret teams of hackers to test security systems in the sector.
...snip...

PKI International Consortium

Refed: **, - **, - **, - **, - ** 
From: Lynn Wheeler
Date: 04/06/2004 09:53 AM
To: Arshad Noor <arshad.noor@xxxxxxxxxx>
cc: PKIX list <ietf-pkix@xxxxxxxxx>, Stephen Kent <kent@xxxxxxxxxx>,
    owner-ietf-pkix@xxxxxxxxxx
Subject: Re: PKI International Consortium
we were called in by one of the industry groups to do some work on the cal. e-sign legistlation ... and then later on the federal bill. their interest was focused on some of the implications between e-sign and privacy. one of the things that they had studied was the driving factors behind privacy legislation ... which they claimed to be 1) identity theft and 2) denial of (institutional) service. Note that since then, there are issues with exposure of email addresses ... for instance look at the postings in the PKIX archive:
http://www.imc.org/ietf-pkix/mail-archive/maillist.html

the issue with institutions in the mid-90s retrenching from the early x.509 identity certificates to relying-party-only certificates (basically a public key and an account number ... or other database index ... where the actual information might be located) .... wasn't directly an identity theft issue .... it was the significant privacy issues. Some of the privacy issues are related to identity theft ... but it isn't solely an identity theft issue.

the various privacy legislative and regulatory aspects are related to exposing personal identifiable information ... how and where that information might be exposed ... regardless of whether or not that information might be contained in a certificate or any other form. some of the exposure issues may be related to identity theft.

GLB has a bunch of stuff about sharing of information within an institutions and/or affiliated third parties. One could imagine a document (certificate or otherwise) ... where it would be perfectly ok to transmit and/or exchange between the individual and the primary institution ... but there would be a requirement that no other entity be allowed to see it. If some types of that information happened to be contained in a certificate ... then how that certificate was used, how it was transmitted, and who was allowed to see it might be subject to various privacy legislation and/or privacy regulations.

i just saw a reference this morning about somebody raising the issue that the proposed google email service may be in violation of various privacy legislation and/or regulations.

In hypothetical scenario an entity digitally signs a perfectly acceptable transaction. In a certificate-based authentication paradigm, the certificate could contain personably identifiable information that has absolutely nothing at all to do with the subject transaction. There could be one or more relying-parties that had interest in authenticating the digital signature. Under various legislative and/or regulatory constraints it might be possible that some relying-parties would not be permitted access to the certificate because of privacy constraints. Such privacy constraints might also impose restrictions on how the certificate was transmitted and/or handled.

arshad noor wrote:
I do not believe identity theft will ever be eradicated regardless of the number of certs. However, if we assume that identity certs are useful, then there is some optimal number that balances the risk against the inconvenience of carrying too many credentials. In the absence of objective research recommending the precise number, or range, the identity firewalls concept advances one figure.

Privacy, personally identifiable information, identity theft

From: Lynn Wheeler
Date: 4/08/2004 02:51 PM
To: PKIX list <ietf-pkix@xxxxxxxx>
Subject: Privacy, personally identifiable information, identity theft
minor references to eu data privacy directive related to those email issues:
http://www.dmeurope.com/default.asp?ArticleID=1417
http://www.dmnews.com/cgi-bin/artprevbot.cgi?article_id=27045

lynn.wheeler wrote:
we were called in by one of the industry groups to do some work on the cal. e-sign legistlation ... and then later on the federal bill. their interest was focused on some of the implications between e-sign and privacy. one of the things that they had studied was the driving factors behind privacy legislation ... which they claimed to be 1) identity theft and 2) denial of (institutional) service. Note that since then, there are issues with exposure of email addresses ... for instance look at the postings in the PKIX archive:
http://www.imc.org/ietf-pkix/mail-archive/maillist.html

Single Identity. Was: PKI International Consortium

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
Date:04/09/2004 08:03 PM
To: Shaheen.Nasirudheen@xxxxxxxx
cc: "Al Arsenault" <aarsenau@xxxxxxxx>, amg@xxxxxxxx,
    "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
    "Arshad Noor" <arshad.noor@xxxxxxxx>,
    "Terwilliger, Ann" <aterwil@xxxxxxxx>,
    "Eric Norman" <ejnorman@xxxxxxxx>,
    "PKIX list" <ietf-pkix@xxxxxxxx>, "Stephen Kent" <kent@xxxxxxxx>
Subject: Re: Single Identity. Was: PKI International Consortium
note that the financial examples aren't really identification ... they really are authentication ... and that actually helps make it work. it is somewhat a fabrication to call it identification.

if my financial authentication device is lost/stolen/breaks/fails/etc, i can call up and AUTHENICATE myself as the owner of the account and get a new one. The various questions are all effectively some form of shared-secret ... that they hope the person on the street can remember. They ask things like transactions on previous statements ... but they also ask address, social security number, and mothers-maiden-name. For mothers-maiden-name ... they've never actually ID you ... they've effectively asked for a shared-secret that they hope you can remember/answer. Because of some issue about mothers-maiden-name might not be the best of secrets ... I know people that make up values to fill in that field .... you just have to make sure you remember it, when the mothers-maiden-name tag shows up ... you remember what secret you actually filled in. The use of SSN is something of a schizophrenic problem ... it is dual-use both as a (mandatory) identification (by gov. requirements) and as a shared-secret (something you can answer for authentication). The problem with the mandatory identification aspect of SSN is that it becomes propagated to a large number of places, compromizing its use as a shared-secret authentication mechanism.

the authentication taxonomy is

• something you have
• something you know
• something you are

shared-secrets are part of something you know; hardware tokens are example of something you have. Digital signatures for authentication purposes tend to be of the something you have nature ... i.e. in theory you and only you have a copy of your private key. Note in this context ... whether or not certificates are part of the paradigm is orthogonal to the authentication taxonomy.

Financial cards have also been of the something you have paradigm. In the past, there has been great deal of effort in making them hard to counterfeit these cards .... majority of it based on assuming that the criminal generates the counterfeit cards completely from scratch. The current problem is one of skimming where all the information to make a duplicate card is copied (as opposed to having to start from scratch creating a counterfeit card).

something you have authentication paradigm breaks down when the object is no longer unique. this can happen with private keys if wherever one is stored becomes compromized. It has also happened in the case of the EMV counterfeit yes cards .... i.e. effectively the same technology for skimming to make duplicate (counterfeit) magstripe cards is also used to make duplicate (counterfeit) EMV cards.

the issue regarding the contents or nature of a certificate is totally orthogonal to the use of public/private key system as a something you have authentication mechanism. The advantages that the digital signature mechanism has over existing shared-secret paradigms ... 1) resilent to insider attacks that copy the master secret database (there is no shared-secret that they can get that allows them to impersonate you), 2) phishing attacks are slightly more complicated since you don't actually "remember" your private key (i.e. something you have rather than something you know )

The downside of private keys in a file on your PC ... is that it is relatively suseptable to phishing and virus attacks ... if they can get you to click on something and give up your logon password ... they can get you to click on something and give up the (private key) file encryption key (transmitting the file at the same time).

Placing the private key in a hardware token, where effectively nobody can get it (or duplicate the private key) .... then requires change in tactics. They have to convince you to (physically) mail off the hardware token along with any PIN ... or get you to use the hardware token in transactions on their behalf.

Again ... nothing in the uses of private key and/or hardware tokens for authentication is directly related to certificates. The certificates paradigm is part of a structure for validating the results of the authentication .... but is not part of the generation of the authentication or the authentication taxonomy.

shaheen nasirudheen wrote:
Hello everyone.

Though new to this group, within a short span I understand there are people who favor single identity and who does not. I also understand that there is an effort towards standardizing or centralizing PKI among the Financial Institutions. One such effort is Identrus. Thanks to some of the members of this group who helped me with good information. However, moving forward, can I look forward for a single identity that I can use to identify myself to any public system that require identification and authentication? If there is an ongoing effort in this regard, please let me know so that I can participate.

Regards,

Shaheen Nasirudheen

privacy, authentication, identification, authorization

Refed: **, - **, - **, - **, - ** 
From: Lynn Wheeler
Date: 04/10/2004 05:34 PM
To: "PKIX list" <ietf-pkix@xxxxxxxx>
Subject: privacy, authentication, identification, authorization
basically somebody provides some authentication information, in public/private key scenario ... a digital signature is generated by a private key as part of a something you have authentication paradigm.

there could be some certification process where a hardware token is involved (certifies the operation of specific hardware token analogous to FIPS or common criteria, not as in a public key certificate issuing institition), the hardware token is certified as generating (on-chip) a key pair where the private key never leaves the chip. the hardware token could also be certified as generating specific kinds of digital signature when correct PIN or biometric is presented. with such a certificate infrastructure .... the relying party might then have grounds to believe that in addition to something you have, there may bave been something you know and/or something you are authentication. This wouldn't be a shared-secret based operation .... but the relying-party could infer something you know and/or something you are if it trusted the certification process for the hardware token operation.

the relying-party then obtains a public-key and validates the digital signature. the infrastructure for the public-key could be a database (conforming to most existing business processes for authentication material) or a certificate (in the PKI model).

the infrastructure typically has bound the public-key to some identification, index, and/or authorization information. In the case of identification or index, that information is frequently then used to lookup some authorization information (i.e. specific identity is allowed to do specific stuff). A trivial example is a generic employee certificate ... all it contains is some generic employer information and the public key, if the digital signature authenticates ... then it is known that the person is some employee and is entitled to do whatever generic employees are entitled to do.

the issue here is that there aren't a lot of business processes that perform identification (or authentication) just for the sake of it (having absolutely no other purpose) .... the business process is performing the operation as part of some additional activity. For instance, there aren't a lot of identification stores in malls, where you walk in authenticate/identify ... and then walk out (with no other operation occuring).

The early x.509 identity certificates tended to contain a lot of arbitrary information that ran afoul of various pricacy issues. The result was retrenching to relying-party-only certificates that contain an indication or domain-specific index ... which was then used to index a database entry that then provided the actual information needed for executing a business process.

Putting in generic identity information or possibly institutional specific identity and/or authorization information (like clearance levels) in a public certificate (targeted for uncontrolled distribution) tends to violate various privacy and/or institutional rules/policies.

just because some item of information is encapsulated in a public certificate doesn't magically mitigate all rules and policies regarding the handling of that information

Re:Identity Firewall. l PKI International Consortium

Refed: **, - **, - ** 
From: Lynn Wheeler
Date: 04/11/2004 08:02 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Arshad Noor" <arshad.noor@xxxxxxxxx>,
    "PKIX list" <ietf-pkix@xxxxxxxxx>,
    "Stephen Kent" <kent@xxxxxxxx>
Subject: Re:Identity Firewall. l PKI International Consortium
i was at a presentation of a vendor SAML product about a year ago that was being deployed in a number of institutions. the CTO was presenting all the message flows. I made some comment that the message flows looked nearly the same as a Kerberos presentation i had sat thru circa 1990. The response was that there was just only so many ways that distributed security control could be implemented.

anders rundgre wrote:
What Steve did not mention, is that the authentication and authorization schemes that are firmly in place since three decades or so for bank-to-bank and supplier-to-manufacturer networks, together with recent developmemts like SAML and 3D Secure, will likely forever change how PKI is applied, which also will affect schemes like the Identity Firewall.

Probably PKI deployment will follow two main directions, relying-party-only and general purpose TTPs. Which one will be dominating depends IMHO not on technical issues but on business models and costs. There are to my knowledge practically no limitations to what you can do with an identity credential using indirect auth* schemes.

Indirect auth* schemes BTW offer huge cost, control, and scalability advantages over the schemes currently being deployed by many public sector PKI programs.

Definitions of "Security"?

Date: Wed, 14 Apr 2004 09:34:58 -0600
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: hadmut@xxxxxxxx
Subject: Re: Definitions of "Security"?
Cc: cryptography@xxxxxxxxxxxx
At 08:01 AM 4/14/2004, hadmut wrote: Hi,

I'm looking for interesting and unusal defitions of the term "Security" (or "secure")

there was a discussion on PAIN taxonomy for security earlier in the year ... misc. references
http://www.garlic.com/~lynn/aadsm16.htm#11 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
http://www.garlic.com/~lynn/aadsm16.htm#14 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic)

eCompute ECC2-109 Project has PROBABLE solution

From: Anne & Lynn Wheeler <lynn@xxxxxxxxxx>
Date: Thu, 08 Apr 2004 23:24:40 -0600
Subject: eCompute ECC2-109 Project has PROBABLE solution
To: cryptography@xxxxxxxxxx
http://web.archive.org/web/20030207160039/http://www.ecompute.org/ecc2/
There has been a PROBABLE solution generated as of 1425 hrs GMT, April 8, 2004.

Until Certicom has confirmed this, it will be treated as a PROBABLE solution and the DP collection will continue.

The two people who have submitted the DP values have been emailed.

Until Certicom formally accepts this, please do not stop your clients. Remember, this is only a PROBABLE solution and we do not done yet!

The ECC2-109 Team

eCompute ECC2-109 Project has PROBABLE solution (now official)

From: Anne & Lynn Wheeler <lynn@xxxxxxxxx>
Date: Fri, 16 Apr 2004 10:15:20 -0600
Subject: Re: eCompute ECC2-109 Project has PROBABLE solution (now official)
To: cryptography@xxxxxxxxxx
At 11:24 PM 4/8/2004, Anne & Lynn Wheeler wrote:
http://web.archive.org/web/20030207160039/http://www.ecompute.org/ecc2/

it is now official

eCompute ECC2-109 Project

We have received unofficial OFFICIAL word that the solution is valid!

As a result, the DP server has been closed and we’re working on finalizing the final stats. No further DP values will be accepted and the DP server will remain closed.

A little later today we’ll be posting complete information regarding the solution, some project stats, and other final information. Until then

We wish to thank everyone who has contributed to this project. With your help, it was a success. Without your help, it never could have happened!

The solution was achieved through a collision of points provided by:

glenon from Ars Technica Team Vodka Martini

Maximum_Confusion from TechIMO

The following was written by Chris Monico to describe the solution achieved.

... snip ..

Payment system and security conference

Refed: **, - **, - ** 
From: Lynn Wheeler
Date: 04/18/2004 11:07 AM
To: internet-payments@xxxxxxxx
Subject: Payment system and security conference
reminder from this month's enhyper newsletter, 2004 payment system and security conference
http://www.enhyper.com/paysec/

also mention financial cryptography blog ... by some of the same people
http://www.financialcryptography.com/
they also have short blurb on:
http://www.bitpass.com/

enhyper also discovered norm hardy and some of his papers: ... the digital silk road
http://www.cap-lore.com/Economics/DSR/
http://www.agorics.com/Library/dsr.html

norm's past include LLNL, 360s, vm/370, secure operating systems and secure transactions:
http://cap-lore.com/

and secure operating systems at tymshare with gnosis and keykos:
http://www.agorics.com/Library/keykosindex.html
http://web.archive.org/web/20020204180320/http://www.cis.upenn.edu/~KeyKOS/
.... and there is EROS -- extremely reliable operation system (outgrowth of keykos)
http://www.cis.upenn.edu/~eros/
... note above mentions looking at getting an EAL7+ evaluation for eros.

when MD bought tymshare they were looking at spinning off a number of things. i was brought in to do a technical audit of gnosis as part of its spin-off as keykos. they were also spinning off Doug Engelbart who was working at Tymshare at the time ... tymshare was running doug's "augment" system on pdp10 ...
http://www.superkids.com/aweb/pages/features/mouse/mouse.html
http://sloan.stanford.edu/MouseSite/dce-bio.htm
http://www.invisiblerevolution.net/engelbart/glossary/augment_nls.html
http://www.sciencedaily.com/encyclopedia/nls

and total topic drift, i've got lots of references to vm/370:
http://www.garlic.com/~lynn/subtopic.html#545tech
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

visa cards violated, BofA reissuing after hack attack

Refed: **, - **, - ** 
From: Lynn Wheeler
Date: 04/19/2004 11:49 AM
To: internet-payments@xxxxxxxxx
Subject: visa cards violated, BofA reissuing after hack attack
http://business.bostonherald.com/technologyNews/view.bg?articleid=439
Visa cards violated: BofA is reissuing after hack attack
By Jay Fitzgerald
Friday, April 16, 2004

Holders of Fleet Visa business credit cards may be the latest victims of hackers who possibly got hold of sensitive card numbers via a merchant's computer system, officials acknowledged yesterday.

Fleet Credit Card Services, now part of Bank of America [BAC: chart, news] Corp. after this month's takeover of FleetBoston Financial Corp. [FBF: chart, news] , is sending new cards to an unspecified number of customers because of a security breach at an unnamed merchant.

.... snip ....

old posting on security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61

misc from IETF

From: Lynn Wheeler
Date: 04/30/2004 10:59 AM
To: internet-payments@xxxxxxxx
Subject: misc from IETF
recent moved from draft to RFC & BCP (cross-posted in sci.crypt ng):

RFC 3766 Determining Strengths For Public Keys Used For Exchanging Symmetric Keys

for announcement & ref see:
http://www.garlic.com/~lynn/2004e.html#18

also, the following note from the ietf trade working group on electronic commerce markup language (ECML):

Just to update you on what is happening, since the Last Call on them is over and there were no negative comments, I have requested on behalf of the working group, that

draft-ietf-trade-voucher-lang-06.txt and
draft-ietf-trade-voucher-vtsapi-06.txt

be published as Informational RFCs and I have submitted a new version of the ECMLv2 draft:

draft-ietf-trade-ecml2-spec-09.txt

Donald

The future of security

Refed: **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sat, 08 May 2004 15:36:16 -0600
Subject: Re: The future of security
To: Ian Grigg <iang@xxxxxxxx>
Cc: cryptography@xxxxxxxx
On Thu, 2004-05-06 at 17:52, Ian Grigg wrote:
c. much less emphasis on deductive no-risk systems (PKIs like x.509 with SSL) due to the poor security and market results of the CA model.

at the nist pki r&d workship (mentioned elsewhere in some other post in this mailing list) there was discussion of

1) using private key signing for things like signature (like in human signature) agreement/authorization as opposed to straight authentication. one of the issues is that if you ever use a private key to digitally some random challenge/response data in a authentication paradigm ... you might be at risk ever using the same private key for signature purposes ... since it might be possible that some of the random data you may have signed might not have been truely random after all

2) naked public keys ... aka w/o certificates at all

3) and in some of the breaks the certificate use in payment transactions. sort of two issues in payment transactions were/are a) privacy and b) size bloat. in the mid-90s, the traditional x.509 identity certificate from the early 90s was drastically cut back to relying-party-only, "account number" certificate because of privacy issues with identity information. The work on certificate-based financial transaction started with taking a 60-80 byte payment transaction, instead of ISO8583, using ASN.1 encoding to blow it up to 200-300 bytes; added a 128-byte RSA signature (then adding in the ASN.1 encoding) and a relying-party-only certificate that typically ran 4k-12k bytes; having starting from a 60byte normal transaction, the certificate-based stuff would blow it up by factor of one hundred times to 6k to 12k bytes. The certificate was totally redundant and superfluous since the financial institution was the relying party and already had all the information. In the X9.59 work it was observed that it was possible to encode an ECDSA signature in an ISO8583 transaction in 42 bytes ... so absolute minimum for authenticated payment transaction would go from 60 bytes to a little over 100 bytes ... w/o throwing in a bunch of extraneous, duplicated and/or superfluous data that provided absolutely no added value (the payment transaction still contained the same data, digital signature authentication was added ... and all the payload carried in a certificate was totally redundant and superfluous since the relying-party had a superset). It isn't exactly that payment security requirements have to be proportional to the cost of certificate security ... it was that certificate security increased the payload costs by a factor of one hundred times and provided NO added value.

some of my further observations about mixing authentication signing and signature signing ... as well as nature of naked public keys ... recently posted to thread in sci.crypt:
http://www.garlic.com/~lynn/2004e.html#20 Soft signatures

and "the future of security" ... somewhat orthogonal to cryptography ... there was recently a letter from NSF to some former multician that was posted to the alt.os.multics n.g. that started a thread on (not necessarily crypto) system security (and multics never having been broken). a couple posts in the thread
http://www.garlic.com/~lynn/2004e.html#27 NSF itnerest in Multics security
http://www.garlic.com/~lynn/2004e.html#36 NSF itnerest in Multics security

Online credit card fraud rocks Indonesia

From: Lynn Wheeler
Date: 05/07/2004 10:42 PM
To: internet-payments@xxxxxxxx
Subject: Online credit card fraud rocks Indonesia
http://straitstimes.asia1.com.sg/asia/story/0,4386,249296,00%20.html
It is so rampant that popular e-commerce sites are slapping curbs or even outright bans on purchase bids from the country
By Robert Go
JAKARTA - Mr Fektur claims he earns 20 million rupiah (about S$3,900) a month - a sum that firmly puts him in Indonesia's middle class.

... snip ...

Yahoo releases internet standard draft for using DNS as public key server

From: Lynn Wheeler
Date: 05/19/2004 09:26 PM
To: internet-payments@xxxxxxxx
Subject: Yahoo releases internet standard draft for using DNS as public key server
yahoo draft internet standard for using DNS as a public key server
http://web.archive.org/web/20040607200622/http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt
misc past news refs:
http://docs.yahoo.com/docs/pr/release1143.html
http://blogs.ittoolbox.com/linux/technologist/archives/000241.asp
http://web.archive.org/web/20040215184953/http://www.computerweekly.com/Article127082.htm
http://zdnet.com.com/2100-1104_2-5164279.html
http://www.ecommercetimes.com/perl/story/32995.html

a few past threads on using DNS as a public key server
http://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aepay4.htm#comcert2 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert4 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption
http://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki12 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001c.html#9 Server authentication
http://www.garlic.com/~lynn/2001d.html#36 solicit advice on purchase of digital certificate
http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
http://www.garlic.com/~lynn/2001e.html#26 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#40 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#2 Root certificates
http://www.garlic.com/~lynn/2001g.html#19 Root certificates
http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
http://www.garlic.com/~lynn/2001n.html#57 Certificate Authentication Issues in IE and Verisign
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
http://www.garlic.com/~lynn/2002p.html#18 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#51 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#53 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new)

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Moving forward with pre-shared keys

From: Lynn Wheeler
Date: 05/20/2004 10:07 AM
To: "Joseph Salowey" <jsalowey@xxxxxxxx>
cc: "'Eric Rescorla'" <ekr@xxxxxxxx>, hzhou@xxxxxxxx, ietf-tls@xxxxxxxx,
    "'David A. McGrew'" <mcgrew@xxxxxxxx>,
    "'Nancy Cam-Winget'" <ncamwing@xxxxxxxx>
Subject: RE: Moving forward with pre-shared keys
similar ... but different ... is pre-stored keys .... the yahoo draft that showed up yesterday to use DNS as a public-key server.

minor reference:
http://www.garlic.com/~lynn/aadsm17.htm#36

Study: ID theft usually an inside job

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Lynn Wheeler
Date: 05/22/2004 09:16 AM
To: internet-payments@xxxxxxxx
Subject: Study: ID theft usually an inside job
Study: ID theft usually an inside job
http://www.msnbc.msn.com/id/5015565

Up to 70 percent of cases start with employee heist
By Bob Sullivan
Technology correspondent
MSNBC
Updated: 7:03 p.m. ET May 21, 2004
A soon-to-be-released study reveals what some identity theft experts have hinted at for years -- the crime is largely the work of insiders. In a study of more then 1,000 identity theft arrests in the United States, Michigan State professor Judith Collins has discovered that perhaps as much as 70 percent of all identity theft starts with theft of personal data from a company by an employee.

... snip ...

this isn't inconsistent with earlier studies claiming that general fraud tended to be 90 percent insiders.

posting related to internet payments ... and security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

part of the issue is the excessive amount of identity &/or static shared-secret information laying about in authentication infrastructures .... making the infrastructure vulnerable to identity theft, or other kinds of impersonation and/or replay attacks.

The future of security

Refed: **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 26 May 2004 09:51:01 -0600
To: "Steven M. Bellovin" <smb@xxxxxxxx>
Subject: Re: The future of security
Cc: Ian Grigg <iang@xxxxxxxx>,
    Graeme Burnett <rgb@xxxxxxxx>, cryptography@xxxxxxxx
At 09:36 AM 5/11/2004, Steven M. Bellovin wrote:
In message <409ACFC7.6050407@xxxxxxxx>, Ian Grigg writes:
>
>Security architects
>will continue to do most of their work with
>little or no crypto.

And rightly so, since most security problems have nothing to do with the absence of crypto.

>
>j. a cryptographic solution for spam and
>viruses won't be found.

This ties into the same thing: spam is *unwanted* email, but it's not *unauthorized*. Crypto can help with the latter, but only if you can define who is in the authorized set of senders. That's not feasible for most people.

one of the issues has been that many crypto security solutions have been oriented towards hiding information. that may work with outsiders ... but traditionally, 90percent of fraud has been insiders ... and recent news last friday about study to be published was that interviewing something like 1000 people involved in identity theft cases ... it was determined that at least 70percent had some sort of employee involvement.

in that sense ... the internet and introduction of the possibility of outsider related fraud ... has distracted/obfuscating focus from the real, long standing issues.

my repeated observation that current generation of desktop systems were originally introduced to operate in a standalone environment where applications could be introduced that freely took over the whole machine. attempting to continue to satisfy the standalone ... total take-over requirements at the same time using the same platform for generalized interconnect to an increasingly hostile environment creates some diametrically opposing objectives.

The future of security

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 28 May 2004 10:44:17 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
Cc: astiglic@xxxxxxxx, iang@xxxxxxxx,
    smb@xxxxxxxx, cryptography@xxxxxxxx, rgb@xxxxxxxx
Subject: Re: The future of security
At 09:27 AM 5/28/2004, Peter Gutmann wrote:
No they won't. All the ones I've seen are some variant on the "build a big wall around the Internet and only let the good guys in", which will never work because the Internet doesn't contain any definable inside and outside, only 800 million Manchurian candidates waiting to activate. For example MessageLabs recently reported that *two thirds* of all the spam it blocks is from infected PCs, with much of it coming from ADSL/cable modem IP pools. Given that these "spammers" are legitimate users, no amount of crypto will solve the problem. I did a talk on this recently where I claimed that various protocols designed to enforce this (Designated Mailers Protocol, Reverse Mail Exchanger, Sender Permitted From, etc etc) will buy at most 6-12 months, and the only dissent was from an anti-virus researcher who said it'd buy weeks and not months. The alternative proof-of-resource-consumption is little better, since it's not the spammers' resources that are being consumed.

the caveat to that is many of the infected machines were originally infected by spam with spoofed origin ... somehow convincing users to click on something. authentication would help somewhat with that ... and, in fact, some of the spam being sent out by the infected machines, in turn uses spoofed origin. authentication might also help address the identity-theft oriented spam ... claiming to be your bank and needing personal information.

it doesn't help with ... click on this to get the latest, greatest game ... where there isn't any attention at all paid to the origin ... just looking for instant gratification.

the 60s/70s time-sharing systems nominally had some assurance applied to the introduction of executables into the environment. this is my comment about the desktop systems having diametrically opposing requirements ... the original design point of totally unconnected, stand alone environment where an introduced executable could take over the whole machine ... and at the same time fully wired to an increasingly hostile environment needing signficant safeguards and processes associated with assurance of introduced executables. the intermediate step was that some of these stand-alone machines acquired interconnect capability for a local, safe, isolated departmental/office network. This had hardly any restricted execution and access capability ... again not worrying about protection against a hostile and unsafe operation.

the shared environment analogy is highway traffic and rules about operating an unsafe vehicle could result in both having your license revoked and the vehicle confiscated (it doesn't require the driver to be a highly trained car mechanic ... it just holds the driver responsible).

connecting systems that were designed for fundamentally safe and isolated environment to wide-open anarchy hostile operation exposes all sorts of problems. somewhat analogous to not actually needing a helmet for riding a motorcycle ... or seat belts and airbags to drive a car.

Yahoo releases internet standard draft for using DNS as public key server

Refed: **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 01 Jun 2004 12:06:00 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
Cc: cryptography@xxxxxxxx, nelson@xxxxxxxx
Subject: Re: Yahoo releases internet standard draft for using DNS as public key server
At 10:14 PM 5/30/2004, Peter Gutmann wrote:
The S/MIME list debated this some time ago, and decided (pretty much unanimously) against it, for two reasosn. Firstly, because it adds huge ugly blobs of base64 crap to each message (and before the ECC fans leap in here, that still adds small ugly blobs of base64 crap to each message). Secondly, because if you get a message from someone you know you'll be able to get a pretty good idea of its authenticity from the content (for example an SSH developer would be unlikely to be advocating SSL in a list posting), and if you get a message from someone you don't know then it's pretty much irrelevant whether it's signed or not. So the consensus was not to sign messages.

this may or may not be my KISS authentication thread.

mid-90s, some number of financial institutions retrenched from x.509 identity certificates to simple relying-party-only certificates ... because of enormous privacy issues regarding blanketing the world with privacy information contained in identity certificates.

however, they were still looking at taking a 60-80 bytes payment message, attaching a 128byte digital signature, and then attaching a 4k byte to 12k byte relying-party-only certificate ... and sending it back to the financial institution that issued the certificate. this is not counting any ASN.1 encoding that might have been done which then possiby includes a bunch more bytes. note that standard payment message message has been around some 30 years carefully crafted as simple 7bit ascii w/o any addition encoding requirements. the purpose of the certificate was to carry the account number ... which was also included in the signed payment message ... and the public key ... which was stored in the account record back at the financial institution that was receiving the transmission and had originally issued the relying-party-only certificate.

so the financial institution receives this new payment object, retrieves the account number from the (signed) payment message and uses the public key in the account record to verify the signature ... w/o ever resorting to the certificate. So we have a payload bloat of one hundred times ... in order to carry a certificate that is redundant and superfluous and never used.

so x9.59 was fairly carefully crafted to add a 42byte ECC signature to a standard 60-80byte payment message. any special encoding to carry 42byte ecc 8bit in 7bit transmission at worst doubled the signature payload size.
http://www.garlic.com/~lynn/x959.html#x959

Article on passwords in Wired News

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 06 Jun 2004 13:54:01 -0600
To: Ernst Lippe <ernstl@xxxxxxxx>
Subject: Re: Article on passwords in Wired News
Cc: martin f krafft <madduck@xxxxxxxx>, cryptography@xxxxxxxx
At 02:19 AM 6/5/2004, Ernst Lippe wrote:
What is that card? There are some schemes that use debit cards with an embedded smartcard. If you are referring to one of these schemes I don't think that they are more secure than TAN's. If it is a card that you carry along with you, the risk that it will be stolen is higher than the risk that some TAN's will be stolen, because in most cases you are able to store your TAN's in a safe place in your home. The only apparent advantage of using a card is the PIN, i.e. something you know, but all internet banking application that I have seen require some form of password which has at least the same security as a PIN. If it really is a debit card, then the security is probably even worse. In several debit card schemes the PIN for cash transactions is the same as the PIN for web transactions ( if the users have the possibility to change either PIN, it is a safe bet that they will be both the same), and it it not at all difficult to determine the PIN in this case.

there is two factor authentication:

• something you have
• something you know

in this scenario we could conclude there are are a least 3-4 types of something you know authentication.

• re-usable shared-secret, things like run-of-the-mill account numbers .. where knowing the account number is sufficient to perform a fraudulent transaction. these are extremely attractive to criminals ... because merchants tend to aggregate them in transaction files ... so a single theft of the transaction file could represent an extremely huge return-on-investment (benefit/risk trade-off). some past discussion of this with regard to security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61

• shared-secret, one-time account numbers. this is a fairly adequate countermeasure for the major fraud scenario ... harvesting merchant account files. there can still thefts/copying of individual account sheets, just like there can be thefts of individual cards. note however that the benefit/risk of individual thefts is orders of magnitude less than the merchant transaction file harvesting. as per the above url discussion of security vis-a-vis risk ... harvesting a merchant account file of re-usable account numbers may represent a $50m exposure ... and hundreds of thousands of dollars expense to a bank to block the affected accounts and re-issue new cards. one time numbers may represent little or no countermeasure to the individual vulnerability .... but it represents a countermeasure for the aggregate vulnerability that is several orders of magnitude larger and more expensive

• something you have cards ... that are supposedly hard to counterfeit ... but changing technology over the years have made them more and more vulnerable, PINs with most of these existing cards have been somewhat something you know shared-secret ... i.e. some flavor of it is transmitted to the financial institution. skimming technology captures the magstripe value as well as the entered PIN; counterfeit cards are then manufactured ... along with notation regarding the correct pin. this skimming also relies on re-usable values ... and skimming operations can be setup and automated to capture tens of thousands

• newer generation of something you have cards with embedded chips and non-shared-secret PINs ... i.e. the correct PIN has to be sent to the chip ... before the chip performs the correct operation. Some of these have acquired the yes card label in some parts of euro-press. transaction information is skimmed ... sufficient to create a counterfeit chip-card. these counterfeit chip-cards answer YES to everything ... i.e. whether the pin entered was correct, whether the transaction value is less than limit, etc. again the skimming process has been automated, allowing the capture of information for potentially thousands of counterfeit cards (the skimming can be identical to that used with magstripe cards).

Is finding security holes a good idea?

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 16 Jun 2004 09:57:08 -0600
To: "Arnold G. Reinhold" <reinhold@xxxxxxxx>
Subject: Re: Is finding security holes a good idea?
Cc: "Steven M. Bellovin" <smb@xxxxxxxx>,
    Ben Laurie <ben@xxxxxxxx>,
    Eric Rescorla <ekr@xxxxxxxx>, cryptography@xxxxxxxx
At 10:14 PM 6/15/2004, Arnold G. Reinhold wrote:
"The Mythical Man-Month" is a great book, but it's almost 30 years old. Brooks considered OS/360 to be hopelessly bloated. My favorite quote (from Chapter 5, The Second System Effect, p. 56):

"For example, OS/360 devotes 26 bytes of the permanently resident date-turnover routine to the proper handling of December 31 on leap years (when it is Day 366). That might have been left to the operator."

Modern operating system are 2 to 3 orders of magnitude larger than OS/360.. They are far more reliable than OS/360 was in its early days and do not presume the availability of an on-site team of operators and system programmers. For the most part they are still maintained one bug at a time The bug fixing process has not reached Brook's predicted crisis.

a small joke where we would rib the mvs people that the 40k byte os/360 simulator in cms did almost as good a job as the 8mbyte plus ) os/360 simulator in MVS (i.e. kernel reserved 8mbytes of the virtual address space, there was also a whole bunch of non-resident stuff). recent thread in comp.arch:
http://www.garlic.com/~lynn/2004f.html#55 Infiniband - practicalities for small clusters

references to environment in the disk engineering lab with "testcells" which resulted in 15min MTBF for MVS with single test cell operating ... and therefor required that single testcell (at a time) development & test occured in stand-alone environment. I rewrote the I/O subsystem so that six to 12 testcells could be operated concurrently in an online environment:
http://www.garlic.com/~lynn/subtopic.html#disk

there are several feedback effects to controlling bug process .... when bugs get to bad ... the users, customers, installations stop doing the things that hurt (the joke about guy going to the doctor and saying it hurts when i do this ... and the doctor says stop doing it). the other effect is that when the backlog of bugs get too long ... everybody gets pulled off everything else and the only thing that goes on is bug fixes.

finally, there has been fairly stringent change control and regression testing evolved at all stages in the infrastructure ... if the new changes can't do all the work that the unchanged system could ... then the changes aren't rolled in. For large, complex infrastructures, this has a tendency limiting change. One might conclude that was one of the reasons that the whole future system failed in the early 70s which was going to be a much more radical change than 360 had been before it. In a seminar at MIT in the early 70s, Amdahl sort of alluded to this as being one of the arguments that he used to get funding for his new company.

the supposed justification for FS (future system) project was countermeasure to the PCM controller business ... something that I've beenaccused as helping originate from a project that I worked on as an undergraduate ... supposedly producing the first PCM controller (i.e. reverse engineered 360 channel interface, built channel board and programmed a minicomputer to emualte a 360 controller)
http://www.garlic.com/~lynn/subtopic.html#360pcm

specific reference to fs overview
http://www.garlic.com/~lynn/2000f.html#16 [OT] FS - IBM Future System
lots more references to future systems
http://www.garlic.com/~lynn/submain.html#futuresys

if you are really feeling interested ... when I did the resource manager ... I did a series of 2000 tests that took three months elapsed time beofre release the product ... misc. past refs to regression testing & benchmarking procedure:
http://www.garlic.com/~lynn/submain.html#bench

the base product had a process that released a monthly accumulated fix (PLC) tape. They wanted me to provide a monthly resource manager PLC tape on the same schedule .... however, I said that it would be nearly impossible for me to do it more than once every three months since at a minimum I would have to do at least 100 different regressions tests taking minimum of 48 hrs elapsed time for even an incremental PLC distribution. resent posting about the whole PLC business
http://www.garlic.com/~lynn/2004g.html#40 IBM 7094 Emulator - An historic moment?

lots of past posts about resource manager, scheduling, page replacement algorithms, caching, etc:
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

Is finding security holes a good idea?

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 16 Jun 2004 10:24:33 -0600
To: "Arnold G. Reinhold" <reinhold@xxxxxxxx>
Subject: Re: Is finding security holes a good idea?
Cc: "Steven M. Bellovin" <smb@xxxxxxxx>,
     Ben Laurie <ben@xxxxxxxx>,
     Eric Rescorla <ekr@xxxxxxxx>, cryptography@xxxxxxxx
oh, and almost forgot ... a rambling story that gets around to talking about future system project ... and all the super security that they put in place to protect all the future system documentation ... they really wanted to have an environment where the future system documentation was only available in restricted online, softcopy environment and it was impossible to get hardcopy (this was somewhat after a incident were paper document of unannounced 370 virtual memory was "copied" and leaked to the press ... which led to putting embossing numbers on all copy machines which would show up on all copies). somebody made the off-hand statement that even I couldn't access the documents .... so i replied i could do it in less than five minutes (... actually 60 seconds ... but i first had to remove all connections to the machine because what i was going to do was really fundamental).
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]

x9.99 financial PIA standard now available from ANSI e-store

From: Lynn Wheeler
Date: 06/18/2004 08:51 AM
To: internet-payments@xxxxxxxx
Subject: x9.99 financial PIA standard now available from ANSI e-store
somewhat in conjunction with working on X9.99, i started a merged financial privacy taxonomy and glossary. for more notes & pointers on merged taxonomy & glossary work see:
http://www.garlic.com/~lynn/index.html#glosnote

x9.99 at the ansi e-store ANSI X9.99

authentication and authorization (was: Question on the state of the security industry)

Refed: **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 01 Jul 2004 20:40:39 -0600
To: John Denker <jsd@xxxxxxxx>
Subject: Re: authentication and authorization (was: Question on the state of the security industry)
Cc: cryptography@xxxxxxxx, Ian Grigg <iang@xxxxxxxx>
At 12:26 PM 7/1/2004, John Denker wrote:
The object of phishing is to perpetrate so-called "identity theft", so I must begin by objecting to that concept on two different grounds.

there are two sides of this .... some amount of crime statistics call it ID-theft .... which plausibly could be either identity or identification ... but in general involves situation where criminal is impersonating you to one degree or another to perform some fraudulent action.

there has been some attempt to distinguish impersonation events between fraudulently extracting money from existing accounts and fraudulently creating new accounts in your name.

practically, objecting to the label id-theft may be like objecting to the label suicide bomber.

in general, the problem is using any kind of static data for authentication. it applies to name, birthdate, mother's maiden name, pins, passwords, account numbers .... any kind of static data. it worked for a long time ... but it was based on assumption that it had characteristics of 1) shared-secret and 2) used uniquely, different static data in different security domains.

the growth of electronic environments has drastically affected this in lots of ways (invalidating the core assumptions that was behind the use of such static data for authentication, it wasn't that static data didn't work ... but it worked well only as long as the underlying assumptions were valid):

1) drastic increase in number of different electronic environments requiring unique shared-secrets ..... basic human factors making it impossible to process unique shared-secret for every possible (scores of unique) environment

2) drastic increase in number of different electronic environments ... drastically increasing the number of places that shared-secrets are being used ... which increasing the places that shared-secrets can be harvested (for criminal purposes)

3) drastic increase in electronic environments that contain information about individuals ... drastically increasing the number of places that personal information can be harvested (of the type that is likely to be used in shared-secret, static authentication information) for criminal purposes.

minor reference to the account based scenario .... security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

and then there is the whole thing about frequent confusion of identification and authentication:
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11-> PKCS12
http://www.garlic.com/~lynn/aadsm14.htm#40 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
http://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
http://www.garlic.com/~lynn/aadsm17.htm#16 PKI International Consortium
http://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings

authentication and authorization ... addenda

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 02 Jul 2004 07:57:02 -0600
To: cryptography@xxxxxxxx
Subject: Re: authentication and authorization ... addenda
ref:
http://www.garlic.com/~lynn/aadsm17.htm#46

one of the industry groups brought my wife and me in to help work on the cal. and then the federal e-sign legislation. there is this intersection between privacy, e-sign, and fraud. in any case, one of the things that they had done was a study of the driving factors for legislative and regulatory privacy activity ... the two primary driving factors were

• id-theft
• (institutional) denial of service (to individuals)

the claim could be made that the id-theft issue is almost totally related to the use of various kinds of static data for authentication and that given the current pervasive electronic online world .... that it is effectively impossible to continue operating with static data paradigm w/o having to accept large amount of exploits and fraud.

the privacy legislative and regulatory mandates can try and establish rules for "protecting" information ... but keeping static data authentication information "private" is a loosing battle. in part, because traditionally 90% of the exploits have involved insiders .... although recent study now only claims that at least 77% of the incidents involve insiders. All the internet histeria about outsiders ... in part just obfuscates identifying the real sources of the problem.

one assertion is that the whole environment collapses because large scale, wide-spread static data based authentication paradigm has too many vulnerabilities ... somewhat as per the previous reference to security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

if nothing else ... there isn't sufficient finances to fund the security necessary to protect all the authentication static data. also, this isn't taking into account the wide-spread education necessary for countermeasure to the social engineering and phishing exploits.

some sort of hardware token with non-static data (as something you have authentication) starts to address the situation. the issue isn't that the hardware token can't be stolen .... but it is difficult to steal electronically a million at a time (large scale harvesting with little investment and risk is one of the things that makes phshing so attractive ... the potential fraud ROI is enormous).

If the hardware token implements a non-static data authentication paradigm and never exposes its internal secrets (say like a private key of public/private key pair) ... then no amount of phishing can convince somebody to divulge something that they don't know. social engineering might still be able to convince people to mail their authentication token to some far off country (that requires quite a bit more gullable populace .... comparable to convincing everybody that they have to mail off their driver's license to some far off location).

changing the paradigm from static data authentication to non-static data authentication would do more for reducing id-theft vulnerabilities than all the privacy and security regulations. one of the side issues .... is sometimes if all you have is a data security classification & protection hammer ... then the solution to all problems is protecting the data. The security proportional to risk scenario is it is impossible to protect the pervasive use of authentication static data ... the paradigm has to be changed.

legislative and regulatory privacy mandates would still be necessary for the other privacy driving factor .... (institutional) denial of service (to individuals).

there will still be various kinds of impersonation fraud .... if you can't perform fraudulent financial transactions by stealing account numbers .... criminals might still open accounts in victims names. However, an assertion is if the points of attack are reduced by several orders of magnitude ... aka from all transactions (because of stolen account numbers) to stolen hardware tokens and opening accounts ... then it is possible to better concentrate the security budget on the drastically reduced attack points and threat models.

i mentioned before that i've been one of the x9.99 (privacy impact assessment) standard co-authors for the last year or so .... and it is now out for public comment (can be bought from the ansi e-store) ... and there is work item proposal to move it forward to ISO. For part of the background work, i started a merged privacy taxonomy and glossary .... similar to the merged taxonomy & glossary work that i've done in other areas:
http://www.garlic.com/~lynn/index.html#glosnote

FTC has some resources in this area:
http://www.ftc.gov/bcp/conline/edcams/gettingcredit/resources.html

I gave a talk earlier this week at treasury conference in DC on privacy and id-theft ... and there were some number of questions about resources for individuals that are victims of id-theft

Japanese bank offers 'biosecurity' account

From: Lynn Wheeler
Date: 07/02/2004 12:58 PM
To: internet-payments@xxxxxxxx
Subject: Japanese bank offers 'biosecurity' account
http://web.archive.org/web/20040910000733/http://www.kansascity.com/mld/kansascity/business/technology/9066667.htm?1c
TOKYO (AP) - A Japanese bank on Friday launched a biosecurity account, the holders of which can only conduct transactions once they have proved their identity -- by showing the pattern of veins on their palms.
... snip ...

slightly related to id-theft & authentication thread in another mailing list:
http://www.garlic.com/~lynn/aadsm17.htm#46 authentication and authorization (was: Question on the state of the security industry)
http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

Use cash machines as little as possible

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 04 Jul 2004 14:25:23 -0600
To: cryptography@xxxxxxxx
Subject: Use cash machines as little as possible
http://www.thisislondon.com/news/business/articles/timid80044?source=
http://www.thisismoney.com/20040704/nm80044.html
ONE of Britain's biggest banks is asking customers to use cash machines as little as possible to help combat soaring card fraud.

... snip ..

authentication and authorization (was: Question on the state of the security industry)

Refed: **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 07 Jul 2004 10:07:29 -0600
To: "Anton Stiglic" <astiglic@xxxxxxxx>
Subject: RE: authentication and authorization (was: Question on the state of the security industry)
Cc: "'John Denker'" <jsd@xxxxxxxx>,
    <cryptography@xxxxxxxx>, "'Ian Grigg'" <iang@xxxxxxxx>
At 07:23 AM 7/5/2004, Anton Stiglic wrote:
Identity has many meanings. In a typical dictionary you will find several definitions for the word identity. When we are talking about information systems, we usually talk about a digital identity, which has other meanings as well. If you are in the field of psychology, philosophy, or computer science, identity won't mean the same thing. One definition that relates to computer science that I like is the following: "the individual characteristics by which a thing or person is recognized or known".

another way of looking at it in an authentication/authorization infrastructure is that some set of privileges are asserted ... this is typically done by having some sort of identification associated with those privileges (like an account number or userid). There can be some confusion whether what is being asserted is a tag, identity or identification. if the tag being asserted, is something like a person's name, the institution is likely just using it for a tag to look up the set of privileges associated with that name (they may not actually care who you are ... they want to know what privileges are associated with the name/tag).

then there is some sort of authentication as to the binding to those set of privileges .... aka 3-factor authentication taxonomy

• something you know
• something you have
• something you are

note, in some scenarios .... it is possible that knowing the account number provides both the privilege assertion as well as the something you know authentication (aka knowing the account number is sufficient to make withdrawals).

in any case there are frequently used institutional processes that can be characterized by assertion of privileges and authentication. The taxonomy of those processes can be considered independent of the terms used to label the processes (is a guard really interested in who you are or just finding out what privileges and permissions you have).

so we have an environment with institutions and CSOs and an attitude that the institution and the institution integrity must be protected from outsiders (and criminal insiders)

however, with the prevalent use of static data and something you know authentication paradigms ... there is huge amounts of static data laying around, ripe for the harvesting ... where the criminal impersonates an individual. so one view is that the vulnerability is the extensive use by institutions of static data and something you know authentication, where the individual may have little or no ability to protect the majority of the information. The crime appears to be against the individual and the source of the information may be totally unrelated to where the crime actually occurs. Assuming that the source of the vulnerability are the institutional infrastructures, some laws have been passed to try and hold the institutions responsible for the protection of individual information. in some scenarios, institutions are charged with protecting individual information from the institution itself (which sort of inverts a security officers job of protecting institution from others).

However, in some scenarios
http://www.garlic.com/~lynn/2001h.html#61

the common use of static data is so pervasive that an individual's information is found at thousands of institutions. The value of the information to the criminal is that the same information can be used to perpetrate fraud across all institutions and so the criminal value is enormous. However the value to each individual institution may be minimal. As a result there can be situations where an individual institution hasn't the infrastructure or the funding to provide the countermeasures necessary to keep the criminals away from the information (they simply don't have the resources to provide security proportional to the risk).

The value of the static data authentication information to a criminal is far greater than the value of the information to the institution ... or the cost to the criminal to acquire the information is possibly orders of magnitude less than the value of the information (for criminal purposes).

Given such a situation .... the infrastructures simply don't have the resources to provide the countermeasures adequate to meet the attacks they are going to experience (there is such a huge mismatch between the value of the information to the individual institutions and the value of the information to the criminal).

Which results in my assertion that there has to be a drastic move away from the existing static data authentication paradigm .... because there is such a mismatch between the value to secure the information verses the value of attacks to obtain the information.

It isn't that theory can't provide mechanisms to protect the information .... it that the information is spread far and wide and is in constant use by thousands of business processes, and that protection problem is analogous to the problem of having people memorize a hundred different 8+character passwords that change every month (which is also a shortcoming of the static data authenticaton paradigm).

misc:
http://www.garlic.com/~lynn/subintegrity.html#fraud
http://www.garlic.com/~lynn/subpubkey.html#privacy

authentication and authorization

Refed: **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 07 Jul 2004 10:25:02 -0600
To: "Anton Stiglic" <astiglic@xxxxxxxx>
Subject: RE: authentication and authorization
Cc: "'John Denker'" <jsd@xxxxxxxx>,
     <cryptography@xxxxxxxx>, "'Ian Grigg'" <iang@xxxxxxxx>
At 09:20 AM 7/6/2004, Anton Stiglic wrote:
Well, there is nt established technical definition for "digital identity", but most definitions seem to focus to what I defined it as.

there is actually a whole series of issues.

the identity x.509 certificates from early 90s were targeted at stuff that appeared to be totally unrelated to existing business processes and environment.

given the scenario that existing business relationships and permissions have been established .... there is requirement to asserting access to those permissions (some means of asserting some identification associated with the permissions and some means of authentication or substantiating the rights to the permissions).

identity x.509 certificates have been totally unrelated to such a business environment ... although attempts have been made to contort them into that use. the original premise was that the identity x.509 certificates could be used by parties that previously had no direct knowledge of each other and could make use of the x.509 certificates w/o needing any recourse to any additional information. one problem was a random name from some place in the world had no context or meaning to some other random entity some place in the world.

putting a person's instantly changing available balance in the certificate might do. however this had (at least) two problems 1) it could be considered privileged information that deemed not advisable in public certificates with copies all over the planet and 2) with possibly thousands of each such certificate cached all around the world .... there was some issue with instantaneously and dynamically updating all copies.

so in the mid-90s there was some retrenchment to relying-party-only certificates ... which basically only contained an account number and the public key. the transaction always went to where the permissions and other important information was available. However it was trivially possible to show that in such situations, the certificates are redundant and superfluous.

The majority of the business infrastructures in the world don't need free floating and complete personal information contained in a certificate about random and totally unknown entities. The need a non-static-data authentication paradigm to replace the static data authentication paradigm, i.e. simply replace pin/password with public key and digital signatures.

misc:
http://www.garlic.com/~lynn/subintegrity.html#fraud
http://www.garlic.com/~lynn/subpubkey.html#privacy

FUJITSU DEVELOPS ENCRYPTION TECH THAT TAKES 20 MILLION YEARS TO BREAK

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 08 Jul 2004 08:33:42 -0600
To: <cryptography@xxxxxxxx>
Subject: FUJITSU DEVELOPS ENCRYPTION TECH THAT TAKES 20 MILLION YEARS TO BREAK
http://www.antaranews.net/en/index.php?id=s6384
Tokyo, July 8 (ANTARA/AFP) - Japanese IT giant Fujitsu Ltd. said Wednesday it has developed credit card encryption technology which is impossible to break with existing means

... snip ...

Using crypto against Phishing, Spoofing and Spamming

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 08 Jul 2004 09:44:52 -0600
To: hal@xxxxxxxx ("Hal Finney")
Subject: Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: cryptography@xxxxxxxx
At 10:40 AM 7/7/2004, Hal Finney wrote:
SET failed due to the complexity of distributing the software and setting up the credentials. I think another reason was the go-fast atmosphere of the late 90s, where no one wanted to slow down the growth of ecommerce. The path of least resistance was simply to bring across the old way of authorizing transactions by card number.

both SET & SSL encrypted data in transit.

an issue is that SET is significantly more complex and provided no additional countermeasure (vis-a-vis SSL) against major remaining exploits .... like harvesting the merchant transaction file while at rest.

there was some issue that SSL was the incumbent ... so SET had to demonstrate significant better ROI to displace it ... rather than significantly higher "I" with little or no additional "R".

some SSL:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

the security proportional to risk reference (using merchant transaction file as example)
http://www.garlic.com/~lynn/2001h.html#61

couple minor past refs related to SET business operations
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards

another SET issue was that it took a typical ISO 8583 transaction of 60-80 bytes and added a RSA 128-byte digital signature and issuing certificate of 4k-12k bytes .... effectively increasing the payload size by a factor of two orders of magnitude. it stripped all the SET overhead off at the internet boundary and transmitted a traditional 8583 message (in part because it was difficult to justify a 100-fold increase in payload size for no obvious benefit) with a flag indicating whether the signature had verified.

There was some presentation at an ISO meeting by one of the association business people about the number of 8583 messages with the signature-verified flag turned on and they absolutely knew that there was no SET technology involved (some justification was association was proposing rules that transactions with the flag on would have lower merchant fees).

missing is that typical authorization includes a lot of dynamic and aggregation factors (like credit limit) that are totally missing in a simple stale, static certificate-based (offline) authentication model. In fact, most infrastructures that involve transactions of any value have migrated and/or are migrating to online infrastructures that involve timely and/or aggregated information .... something that is missing from a purely offline, certificate-based, stale, static data infrastructure.

misc. implications

1) given an online transaction environment, it is then trivial to show that certificates are redundant and superfluous ... because it is possible to access the timely updated copy of the information rather than having to rely on the stale, static copy of the certificate information (designed to satisfy an offline environment requirement)

2) certificate market then becomes relegated to both offline and no/low value (as infrastructures of value migrate to online paradigms)

3) there is little/no justification for paying money for certificates if only no/low value infrastructures are involved.

4) w/o significant funding for certificate-based infrastructure, there is little money to underwrite high-integrity certificate-based operations

5) with no high-integrity certificate-based operations, it is difficult to justify using certificates for high-value operations

6) go to #2

as has past frequently noted, the requirement given the x9a10 retail payments working group for the x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payment environments. one of the considerations was being able to accommodate end-to-end integrity ... aka the financial responsible entity for authorizing the transaction also performs the authentication. another issue for x9a10 was to address other kinds of risks .... like the merchant transaction file where the information traditionally has to occur in the clear to support normal business operations (offer something more than the encryption of data in-flight).
http://www.garlic.com/~lynn/x959.html#x959

lots of posts about certificate infrastructures
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
and relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

misc. stuff on x9.59, identity, authentication, and privacy
http://www.garlic.com/~lynn/subpubkey.html#x959

Using crypto against Phishing, Spoofing and Spamming

Refed: **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 09 Jul 2004 04:14:01 -0600
To: hal@xxxxxxxx ("Hal Finney")
Subject: Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: cryptography@xxxxxxxx
At 10:40 AM 7/7/2004, Hal Finney wrote:
SET failed due to the complexity of distributing the software and setting up the credentials. I think another reason was the go-fast atmosphere of the late 90s, where no one wanted to slow down the growth of ecommerce. The path of least resistance was simply to bring across the old way of authorizing transactions by card number.

the other issue was rsa public key op overhead (besides extreme payload bloat, extreme additional complexity, and no significant countermeasures for prime exploits compared to e-commerce incumbent SSL) ... ref: previous post: http://www.garlic.com/~lynn/aadsm17.htm#53

when the initial set specification was published, i did a business profile and a performance profile (including public key operations profile). somebody i knew was playing with bsafe library and tweaked it to run four times faster. I got him to run the SET public key op profile on a number of processors.

i mentioned the numbers at some SET get together and the response from the SET people was that it was 100 times too slow (if they had ever run any bsafe they should have realized that it was four times too fast). anyway ... sometime later when they had actual SET implementations running ... the earlier profile numbers were within a couple percent of measured on actual implementations.

i also observed that given nominal extended peak avgs. of 1000/transactions per sec .... that if SET ever actually became mainstream operational (rather than just toy pilots) ... processing would need something like 100,000 to 250,000 extra processors to handle the RSA op processing load. the counter argument was that SET would take so long to became mainstream ... that by then CPUs might be ten to 100 times faster and it might only require 10,000 to 25,000 (or 1,000 to 2,500?) extra processors.

Using crypto against Phishing, Spoofing and Spamming

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 15 Jul 2004 09:06:42 -0600
To: Rich Salz <rsalz@xxxxxxxx>
Subject: Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: Hal Finney <hal@xxxxxxxxx>,
    <cryptography@xxxxxxxx>
At 06:42 AM 7/15/2004, Rich Salz wrote:
it wasn't a CCard transacdtion, my liability under SET was unlimited (at least until Congress caught up to the technology). Looking at the risk management aspect, SET was a big loser for the customer.

my earlier responses
http://www.garlic.com/~lynn/aadsm17.htm#53
http://www.garlic.com/~lynn/aadsm17.htm#54

i also included some discussion on it at a talk i gave on naked keys at global grid forum conference last month, focusing on business issues of authentication; ... minor ref (with pointer to the GGF pages & presentation):
http://www.garlic.com/~lynn/2004g.html#53

with some comparison to x9.59
http://www.garlic.com/~lynn/x959.html#x959

.... one of the business issues with public key infrastructures is the dual-use vulnerability of using digital signatures for both authentication and signatures.

many of the authentication infrastructures have the server sending the user some random data to be signed as part of authentication (issues like replay attacks, etc); which the user never looks at.

ignoring all the non-repudiation issues .... real signatures are suppose to imply things like agreement, approval, and/or authorization (of the contents of what is being signed).

the dual-use vulnerability is ever having signed random data ... w/o reading it .... and using the same technology to sign documents where reading is implied (as well as agreement, approval, authorization).

the scenario is somewhat out of MASH where Radar is periodically having the col. sign documents w/o having read them.

Question on the state of the security industry

Refed: **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 15 Jul 2004 17:18:21 -0600
To: Ian Grigg <iang@xxxxxxxx>
Subject: Re: Question on the state of the security industry
Cc: cryptography@xxxxxxxx
A couple recent news stories

1)
Intuit warns of credit card risk
http://news.com.com/Intuit+warns+of+credit+card+risk/2100-1029_3-5269821.html

2)
Cyberattacks are soaring, countermeasures are sucking up tons of cash, and hardware and software vendors for the most part are sitting it out, *Bob Evans* says. But big customers are starting to say enough is enough, so the business-technology world is about to get whirled.
http://www.informationweek.com/story/showArticle.jhtml;jsessionid=WK0LPHXYB4YSUQSNDBGCKHY?articleID=22104612
...................

i've been saying for some time that after market security is broken by design ... it is somewhat like after market seat belts of the 60s. for security to work, it has to be designed & built in from the start .... some relatively recent comments about after market security:
http://www.garlic.com/~lynn/2002h.html#39 Oh, here's an interesting paper
http://www.garlic.com/~lynn/2002p.html#27 Secure you PC or get kicked off the net?
http://www.garlic.com/~lynn/2003n.html#14 Poor people's OS?

dual-use digital signature vulnerability

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 16 Jul 2004 08:31:27 -0600
To: cryptography@xxxxxxxx
Subject: dual-use digital signature vulnerability
ok, this is a long posting about what i might be able to reasonable assume if a digital signature verifies (posting to c.p.k newsgroup):
http://www.garlic.com/~lynn/2004h.html#14

basically the relying-party has certified the environment that houses the private key and the environment that the digital signature was done in ... then the verification of the digital signature might be assumed to imply one-factor or possibly two-factor authentication (i.e. if the relying-party has certified that a private key is housed in a secure hardware token and can never leave that hardware token, then the verification of the digital signature might imply one-factor, something you have authentication).

that establishes the basis for using digital signature for authentication purposes ... being able to assume that verification of the digital signature possibly implies something you have authentication (or something similar).

just the verification of the digital signature, however doesn't do anything to establish any implication about a legal signature where the "signer" is assumed to have read and agrees to the contents of the thing being signed (intention to sign the content of the document as
agreement, approval, and/or authorization).

lets assume for argument sake that some sort of environment can be certified that provides a relying party some reasonable assurance that the signer has, in fact, read and is indicating agreement, approval, and/or authorization ... then there might possible be the issue of the dual-use vulnerability.

the dual-use comes up when the person is signing random challenges as purely a means of authentication w/o any requirement to read the contents. Given such an environment, an attack might be sending some valid text in lieu of random data for signature. Then the signer may have a repudiation defense that he hadn't signed the document (as in the legal sense of signing), but it must have been a dual-use attack on his signature (he had signed it believing it to be random data as part of an authentication protocol).

Using crypto against Phishing, Spoofing and Spamming

Refed: **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sat, 17 Jul 2004 09:25:41 -0600
To: Florian Weimer <fw@xxxxxxxx>
Subject: Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: hal@xxxxxxxx, cryptography@xxxxxxxx
At 10:46 AM 7/10/2004, Florian Weimer wrote:
But is it so harmful? How much money is lost in a typical phishing attack against a large US bank, or PayPal? (I mean direct losses due to partially rolled back transactions, not indirect losses because of bad press or customer feeling insecure.)

misc. recent selections

Online Phishing Scams Exploding
http://itmanagement.earthweb.com/secu/article.php/3382341
Business faces growing loss from identity theft
http://www.vnunet.com/news/1156655
Firms hit hard by identity theft
http://www.boston.com/business/technology/articles/2004/07/14/firms_hit_hard_by_identity_theft/
ID theft costing UK billions in taxes
http://news.zdnet.co.uk/0,39020330,39160532,00.htm
ATM skimmers go hi-tech down under
http://www.finextra.com/fullstory.asp?id=12184
Phishing will cost financial firms $400m in 2004
http://www.finextra.com/fullstory.asp?id=12173
Worried firms consider email boycott
http://www.vnunet.com/news/1156684



social engineering has frequently been talking somebody into giving up some information that then can be used for impersonation in later fraudulent transactions. A something you have token of some sort is a lot harder to give-up than shared-secrets for use in something you know authentication. A private key that never leaves the hardware token can't be given up because even the owner doesn't know it. also, conjecture is that it is a lot harder to convince general public to mail off some physical object compared to getting them to divulge some information.

hardware tokens don't eliminate social engineering attacks where the victim is talked into performing some transaction on behalf of the attacker ... but they would tend to address the whole vulnerability landscape related to something you know shared-secret authentication paradigms.

one of the cost issues with technology for server reputation is that it typically applies to servers that the consumer is visiting for the first time (or visits extremely rarely). the consumer pretty much ignores repetitive information for sites that they visit frequently. it has been that something like ninety percent (or better) of internet transactions are done by the frequently visited sites. so the cost issue is that the reputation technologies basically tend to apply to the millions of low-volume and/or low-revenue sites (in aggregate accounting for 10 percent or less of all transactions) ... which aren't looking to spend a lot of money on such technologies.

it is somewhat like the better business bureau use .... people will tend to contact the better business bureau before they deal with some vendor for the first time .... but they aren't likely to contact the better business bureau each time they deal with a vendor that they have extensive repeat business with. it at least some scenarios ....

an alternative to the business logo .... is a better business bureau or gov. licensing logo on a website .... that provides click-thru to the official site .... where the consumer can review complaints and/or history about the business in question. i believe that this is somewhat the ebay model ... where past transaction history reputation of individuals can be checked.

dual-use digital signature vulnerability

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 Jul 2004 08:54:56 -0600
To: Amir Herzberg <herzbea@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>, cryptography@xxxxxxxx
At 01:33 AM 7/18/2004, Amir Herzberg wrote:
I don't see here any problem or attack. Indeed, there is difference between signature in the crypto sense and legally-binding signatures. The later are defined in one of two ways. One is by the `digital signature` laws in different countries/states; that approach if often problematic, since it is quite tricky to define in a general law a binding between a person or organization and a digital signature. The other way however is fine, imho: define the digital signature in a (`regular`) contract between the parties. The contract defines what the parties agree to be considered as equivalent to their (physical) signature, with well defined interpretation and restrictions.

...

the digital signature laws, for the most part, defined how a certification authority went about binding the owner of a public key (or at least the entity presenting a public key and a digital signature that could be verified by that public key) and some other information ... and presenting that in a certificate. However, I don't remember seeing any of the e-sign laws a) defining a non-repudiation environment that is mandated for signature digital signing environments (indicating that the key owner has read, understood, and approves, agrees, and/or authorizes the contents of the message and b) as part of the integrity of the message, there is proof that such a non-repudiation environment was used.

1)

the relying party being able to certify the integrity level of something like a hardware token .... for use in something you have authentication .... aka the relying party verifies a digital signature and that verification may used to imply something you have authentication (at this point there is absolutely nothing involving a certificate). However, in order for the relying party to be able to assume or imply what the verification of the digital signature actually means .... and therefor how much it can trust the verification ... it needs to know how the private key is maintained and operated. If the act of verifying a digital signature actually means or implies that it is something you have authentication ... then it needs to have some certification along the lines that the private key is used and maintained in a hardware token with specific characteristics. It has nothing at all to do with any certificate traditionally mentioned in various kinds of e-sign laws.

2)

during the early '90s, the identity certificates tended to be overloaded with all sorts of identity and privacy information. this was fairly quickly realized to represent serious privacy and liability issues. this was retrenched to things like relying-party-only certificates that basically only had a public key and some sort of account identifier (which could be used by the relying party to pull up the real information .... w/o having it publicly broadcast all over the world). However, there were also things like non-repudiation bits defined in certificates ... that have since been severely depreciated. During the mid-90s there were some infrastructures being proposed that if you had some data which had an appended digital signature and an appended certificate containing a non-repudiation bit .... then the burden of proof (in disputes) could be shifted from the relying party to the signing party.

This was vulnerable to possibly two exploits

a) the digital signer had believed that they had signed random data as part of an authentication protocol ... as opposed to having signed some document contents indicating agreement, approval, and/or authorization (as in real live signature .... aka the dual-use scenario) and/or

b) since the appended certificate isn't part of the signed transaction .... the relying-party might be able to find a digital certificate (belonging to that key-owner for the same public key) that had the non-repudiation bit set and substitute a non-repudiation certificate for the certificate that the key-owner had actually appended (aka the certificate is not part of the integrity of the message covered under the digital signature).

3)

at the NIST PKI workshop a couple months ago .... there were a number of infrastructure presentations where various entities in the infrastructure were

a) signing random data as part of authentication protocol (where the entity performing the digital signature was given no opportunity to view the contents being signed) they were using hardware token implementation .... and they were assuming that the verification of the digital signature implied some sort of something you have authentication. however there was nothing in the infrastructure that provided certification and/or proof that the private key was kept and maintained in a hardware token .... so there was no proof as to the level of integrity and/or level of trust that the relying party could place in the verification of that digital signature used in the authentication protocols)

However, there was no distinguishing and/or provable characteristics that were provided which a relying-party could use to distinguish between (random) contents that were signed as part of an authentication protocol and (authorization) contents ... where the relying-party could assume to indicate that the signer was agreeing, approving, and/or authorization what was indicated by the contents of the document.

Since there was no proof provided to the relying-party as to the environment and conditions under which the signing actually occurred .... then a dual-use attack is for non-random contents (aka some sort of authorization document) to be injected into an authentication protocol .... under the assumption that the entity performing the digital signature will never look at the contents. Then such digitally signed contents can be used in an approval, agreement, and/or authorization scenario to imply that the entity performing the digital signature was actually approving the contents of the document.

4)

this now verges into various of the non-repudiation definitions and threads that have occurred in the past. in effect, for any kind of infrastructure where the digital signature is being used to imply that the token-owning entity (responsible for the digital) signature agrees, approves, and/or authorizes what is in the content of the message being signed (as opposed to some random data being signed as part of authentication protocol and is never viewed) ... there has to be some additional signing environment (demonstrating that the signer has actually read, understood, and agrees with the contents) ... and the proof of the use of such a signing environment infrastructure has to be carried as part of the integrity of the message .... in order for the relying party to rely on it being a real signature signing event ... as opposed to have really originated from an authentication protocol where the person believed that random data was being signed (and never actually viewed the contents being signed). Note that not only does such an non-repudiation signing environment need to have been used .... but the proof of its use has to be carried as part of the integrity of the message (in order for the relying party to distinguish between random data being digital signed and case where the person having signed after viewing the contents, understanding the contents and approving, agreeing, and/or authorization what was indicated by the contents). So it isn't just that a non-repudiation environment has to be used for signing operations (as in human signature) ...but the proof of such non-repudiation environments have to be carried as part of the integrity of the message .... to differentiate from a dual-use attack where the signing is believed to be random data and the person never views the contents.

5)

other kinds of infrastructure implementations may be to have two completely different hardware tokens with two completely different public/private key pairs.

the hardware token used for authentication protocols doesn't concern itself with the contents of the data ... in fact it always appends a disclaimer to all random data (that it signs) stating that the digital signature cannot be used to imply any agreement, approval, authorization and/or any obligation on the part of the token-owning entity.

the hardware token used for authorization, agreement, and/or approval signing events will never perform a digital signature operation unless it first senses that the token owner has read, understood and approved of the contents.

all protocols indicate as part of the hardware token interaction, which type of digital signature will be performed ... and the owner of the hardware tokens is then instructed appropriately when hardware token swapping needs to occur.

=========
random past posts about non-repudiation:

http://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
http://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign
http://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses "Authority-stamp-signatures"
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
http://www.garlic.com/~lynn/aadsm14.htm#48 basic question: semantics of "map", "tie", etc in PKI
http://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
http://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm16.htm#11 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
http://www.garlic.com/~lynn/aadsm16.htm#14 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#17 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#18 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm16.htm#23 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet Banking
http://www.garlic.com/~lynn/2002g.html#69 Digital signature
http://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema belong to Public Key schema family?
http://www.garlic.com/~lynn/2002j.html#24 Definition of Non-Repudiation ?
http://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
http://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
http://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003.html#29 Message (authentication/integrity); was: Re: CRC-32 collision
http://www.garlic.com/~lynn/2003f.html#37 unix
http://www.garlic.com/~lynn/2003h.html#29 application of unique signature
http://www.garlic.com/~lynn/2003h.html#38 entity authentication with non-repudiation
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
http://www.garlic.com/~lynn/2003k.html#6 Security models
http://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the same key for authentication and encryption
http://www.garlic.com/~lynn/2003o.html#22 securID weakness
http://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
http://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
http://www.garlic.com/~lynn/2003p.html#11 Order of Encryption and Authentication
http://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
http://www.garlic.com/~lynn/2004e.html#20 Soft signatures

Using crypto against Phishing, Spoofing and Spamming

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - ** 
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 Jul 2004 09:51:46 -0600
To: EKR <ekr@rtfm.com>
Subject: Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: Ian Grigg <iang@xxxxxxxx>, Florian Weimer <fw@xxxxxxxx>,
    cryptography@xxxxxxxx
At 05:55 PM 7/17/2004, Eric Rescorla wrote:
Now, my threat model mostly includes (1), does not really include (3), and I'm careful not to do things that leave me susceptible to (2), so SSL does in fact protect against the attacks in my threat model. I know a number of other people with similar threat models. Accordingly, I think the claim that "secure browsing is not secure" rather overstates the case.

there sort of two parts of SSL .... I believe the original justification was based on perceived integrity issues with the domain name infrastructure and various kinds of hijacking attacks. the client got back a certificate, verified the integrity of the certificate (from a table of certificate authority public keys), verified that it appeared to originate from the certificate owner and then compared the certificate domain name string with the domain name used in the URL. once that was done, there was key-exchange to protect the contents of the transmission.

the catch-22 was that the domain name infrastructure is also the authoritative agency as to the owner of the domain name. the SSL domain name certification authorities have this horrendously, error prone and expensive problem of getting sufficient identification information from the certificate applicant and attempting to match it with the identification information carried by the domain name infrastructure as to the owner of the domain name.

so the first issue is that the integrity of the domain name infrastructure could be attacked with a domain name hijack ... then the attacker applies for a certificate .... and the identification provided the certification authority and the identification on file with the domain name infrastructure compare ... and the attacker gets a valid certificate.

so the certification authorities came up with a proposal to have domain name registers .... also supply a public key at the time of registration. then future communication with the domain name owner is digital signed ... which the domain name infrastructure can verify with the public key on file. this is a countermeasure against domain name hijacking (improving the integrity of the domain name infrastructure and rising the trust that certification authorities can place in the authoritative agency). the other issue is that the certification authorities can use the public key on file with the domain name infrastructure to turn an expensive, and error-prone identification process into a much simpler and KISS authentication process .... aka domain name certificate applicants digitally sign their requests ... which are then verified with the public key on file at the domain name infrastructure.

the two issues then are that with increased domain name infrastructure trust ... 1) it should reduce the demand for domain name SSL certificates (motivated by integrity concerns about the domain name infrastructure) and 2) it could eliminate the need for domain name SSL certificates .... since all clients could possibly also use the public keys on file with the domain name infrastructure (in lieu of needing to get public keys from certificates).

So now to the key-exchange issue protecting credit-card numbers from evesdropping and harvesting. The issue is that the crooks tend to go after the best fraud ROI (return on investment). The claim is that it is so much more profitable to harvest the merchant transaction file .... that until that barn door is closed .... the crooks have little incentive to go after credit card numbers by evesdropping packets in flight. There have been some assertions that there has been no known cases of picking up account numbers from packet evesdropping .... even where SSL or any other encryption is being used to protect data in-flight. Part of the issue is that evesdropping packets takes a lot more work ... and provides much less return than going after the merchant transaction file. Other scenarios have also been end-point attacks ... where password files are harvested and/or viruses are installed at end-points to harvest information .... as opposed to doing anything with data in-flight.

So, it could be claimed that there is some question about what is cause and what is effect i.e. are the end-point attacks because everything is encrypted .... or are the end-point attacks occurring because they are so much more profitable and easier. Given that there are significant amounts of non-encrypted traffic ... then the claim could be made that the crooks are getting so much more from end-point attacks ... and until that is addressed ... that attacks on data in flight is somewhat academic (since there is so little evidence about fraud happening from data in flight attacks). The other argument has traditional been that 90 percent of fraud has been insiders, typically also associated with various kinds of end-point attacks (rather than any kind of outsider attack on data in flight). There was some recent study that at least 77 percent of the identity theft has involved insiders. This would also indicate that the end-points are the primary points of attack .... and that data-in-flight attacks are of primarily of academic interests ... not particularly contributing to fraud, even when no encryption or protection is involved.

One might even assert that the attention paid to data-in-flight attacks is actually counterproductive ... distracting attention from the much more serious and significant end-point attack threats .... which has always been the major problem.

AADS Postings and Posting Index, next, previous - home