Misc AADS & X9.59 Discussions

AADS Postings and Posting Index, next, previous - home



CFP: PKI research workshop
CFP: PKI research workshop
CFP: PKI research workshop
Small/Secure Payment Business Models
CFP: PKI research workshop
CFP: PKI research workshop
CFP: PKI research workshop
Small/Secure Payment Business Models
PAIIN security glossary & taxonomy
CFP: PKI research workshop
Hackers Targeting Home Computers
Hackers Targeting Home Computers
Hackers Targeting Home Computers
credit card & gift card fraud (from today's comp.risks)
CFP: PKI research workshop
ansi-epay & epay subscritpion
Limitations of limitations on RE/tampering (was: Re: biometrics)
biometrics
Looking back ten years: Another Cypherpunks failure (fwd)
Crypto Winter (Re: Looking back ten years: Another Cypherpunks failure)
biometrics
biometrics
biometrics (addenda)
Fingerprints (was: Re: biometrics)
biometrics
biometrics
biometrics
biometrics (addenda)
Welome to the Internet, here's your private key
Welome to the Internet, here's your private key
AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE
Blair accidently sells the roads (was Re: BBC article: "Vehicles 'tracked'")
Q: Where should do I put a max amount in a X.509v3 certificat e?
Q: Where should do I put a max amount in a X.509v3 certificat e?


CFP: PKI research workshop

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/01/2002 10:22 AM
To: Russell Nelson <nelson@xxxxxxxx>
cc: cryptography@xxxxxxxx
Subject: Re: CFP: PKI research workshop
you might find interesting
http://www.garlic.com/~lynn/aadsm8.htm#rhose17

specific discussion of hiding credit card numbers:
http://www.garlic.com/~lynn/2001h.html#61 ... security proporitional to risk
http://www.garlic.com/~lynn/2001h.html#58 ... Net banking, is it save??

misc stuff about security proportional to risk (i.e. related to threats):
http://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror10 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
http://www.garlic.com/~lynn/aepay6.htm#harvest harvesting of credit card numbers
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001e.html#77 Apology to Cloakware (open letter)
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001f.html#35 Security Concerns in the Financial Services Industry
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001h.html#45 Article: Future Trends in Information Security
http://www.garlic.com/~lynn/2001h.html#64 Net banking, is it safe???
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/2001l.html#56 hammer

misc. vulnerability analysis (related to threat model):
http://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc
http://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay7.htm#3dsecure4 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/2001c.html#38 How Commercial-Off-The-Shelf Systems make society vulnerable
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
http://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow

also see security taxonomy & glossary at:
http://www.garlic.com/~lynn/index.html#glossary

i.e.
http://www.garlic.com/~lynn/secure.htm

in the "Concepts" (in taxonomy) or "Fastpath" section (in glossary) click on
risk
risk management
threat

nelson@xxxxxxxx on 12/31/2001 8:32 pm wrote:
to which I would add:

3. Cryptography, and therefore PKI, is meaningless unless you first define a threat model. In all the messages with this Subject, I've only see one person even mention threat model. Think about the varying threat models, and the type of cryptography one would propose to address them. Even the most common instance of encryption, encrypted web forms for hiding credit card numbers, suffers from addressing a limited threat model. There's a hell of a lot of known plaintext there.


CFP: PKI research workshop

Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/01/2002 10:59 AM
To: Russell Nelson <nelson@xxxxxxxx>
cc: cryptography@xxxxxxxx
Subject: Re: CFP: PKI research workshop
somewhat as an aside ... the requirement(s) given the X9A10 financial standards working group for the development of the X9.59 standard was

to preserve the integrity of the financial infrastructure for all electronic reatail payments without the use of encryption

ALL didn't just mean internet or just mean credit .... it met ALL ... all environments ... all types of transactions, etc.

"Without the use of encryption" didn't mean that information hiding wasn't precluded (say for privacy reasons) but weren't required to preserve the integrity of the financial infrastructure (aka that complete clear-text could be made available and it wasn't possible to do a fraudulent transaction based on everybody in the world potentially having the cleartext of that payment transaction).

Implied in the requirement was that it had to also be extremely lightweight in order to be applicable to some of the existing electronic payments environments. Again ALL met ALL ... including a large number of existing electronic environments. Frequently "from scratch" protocol definitions are faster to do if you don't have to take into account any existing infrastructure (and/or only addressing an extremely small subset of the total end-to-end problem).

To meet the requirements we eventually settled on a very lightweight, end-to-end authentication definition (strong authentication of every transaction had to flow completely through from the consumer all the way through to the consumer's financial infrastructure).

x9.59 references:
http://www.garlic.com/~lynn/x959.html#x959

nelson@xxxxxxxx on 12/31/2001 8:32 pm wrote:
to which I would add:

3. Cryptography, and therefore PKI, is meaningless unless you first define a threat model. In all the messages with this Subject, I've only see one person even mention threat model. Think about the varying threat models, and the type of cryptography one would propose to address them. Even the most common instance of encryption, encrypted web forms for hiding credit card numbers, suffers from addressing a limited threat model. There's a hell of a lot of known plaintext there.


CFP: PKI research workshop

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/01/2002 11:50 AM
To: Russell Nelson <nelson@xxxxxxxx>
cc: cryptography@xxxxxxxx
Subject: Re: CFP: PKI research workshop
sometimes the "principles" of security are referred to as PAIN or sometims PAIIN

see
http://www.garlic.com/~lynn/secure.htm

and click on PAIN & PAIIN in the acronym section of the glossary.

Doing a threat model ... would include not only end-to-end issues .... but what aspects of PAIIN are being addressed. privacy, authentication, identification, integrity, non-repudiation (PAIIN) (see also authentication, identification, integrity, non-repudiation, privacy, security)

an aspect of security can be integrity and and aspect of integrity can be dependability .... leading to things like:
http://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html

which is then related back to my posting on sunday (with regard to integrity)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki10 CFP: PKI research workshop

nelson@xxxxxxxx on 12/31/2001 8:32 pm wrote:
to which I would add:

3. Cryptography, and therefore PKI, is meaningless unless you first define a threat model. In all the messages with this Subject, I've only see one person even mention threat model. Think about the varying threat models, and the type of cryptography one would propose to address them. Even the most common instance of encryption, encrypted web forms for hiding credit card numbers, suffers from addressing a limited threat model. There's a hell of a lot of known plaintext there.


Small/Secure Payment Business Models

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/01/2002 02:25 PM
To: Steve Schear <schear@xxxxxxxx>
cc: ietf-trade@xxxxxxxx, Ronald Duncan <Ronald.Duncan@xxxxxxxx>
Subject: Re: Small/Secure Payment Business Models


actually, i've heard some number of organizations about not wanting to be a FDIC insured institution, part of the banking federal reserve system, and/or a holding company that "owns" such an instutition because of the regulatory, audit, and fidiciary requirements placed on them

analysis of some types of systemic risks in discussion of risk management and information security (including the section towards the end on ARMS & Citicorp getting out of the home mortgage business as well as the FIRREA Act of 1989):
http://www.garlic.com/~lynn/aepay3.htm#riskm
http://www.garlic.com/~lynn/aepay3.htm#riskaads

also the gao report listed:
http://www.garlic.com/~lynn/aadsm5.htm#epaym "e-payments" email discussion list is now "Internet-payments"

also "secure" payment discussion in sci.crypt "CFP: PKI research workshop" thread:
http://www.garlic.com/~lynn/aadsm10.htm#cfppki14

on 12/31/2001 9:55pm wrote:
Politically: having enough juice to buy off Congress and get regulations favoring/protecting your turf. Regulations always favor the regulated

CFP: PKI research workshop

From: Lynn Wheeler
Date: 01/01/2002 07:01 PM
To: cryptography@xxxxxxxx
Subject: Re: CFP: PKI research workshop
managed to fumble finger a number of URLs:

you might find interesting
http://www.garlic.com/~lynn/aadsm8.htm#rhose17
^^^^             ^^^^^^^
..........................

specific discussion of hiding credit card numbers:
http://www.garlic.com/~lynn/2001h.html#61 ... security proporitional to risk
http://www.garlic.com/~lynn/2001h.html#58 ... Net banking, is it save??
^^
......................

see
http://www.garlic.com/~lynn/secure.htm
                            ^^^^^^^^^^


CFP: PKI research workshop

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 01/02/2002 09:18 AM
To: Derek Atkins <warlord@xxxxxxxx>
cc: cryptography@xxxxxxxx, Russell Nelson <nelson@xxxxxxxx>,
warlord@xxxxxxxx
Subject: Re: CFP: PKI research workshop
well PAIN is out of some standards organization (as is 3-factor authentication) .... i agree that privacy and confidentiality is sometimes thot of as different .... but others argue that it reduces to the effectively the same requirements ... even tho different people have different connotations with the two terms.

i had fumble fingered 3-4 URLs yesterday .... and the posting to correct them seems to have gotten suspended for some time in the ether .... note however the url for the security taxonomy and glossary had been typed correctly in a posting made earlier in the day ... i.e. http://www.garlic.com/~lynn/secure.htm

warlord@xxxxxxxx on 1/2/2002 7:37 am wrote:
Lynn,

I think you should specify "confidentiality" as another issue to be addressed. Perhaps you include confidentiality in your "privacy" or "security" subsections, but I've found that many people think (and mean) different things when they use these two terms. For example, is privacy necessarily privacy of communicated data from eavesdroppers, or is it the privacy of personal information (perhaps the privacy of the authentication information) so an eavesdropper does not know who is communicating?

Unfortunately your garlic.com URL (security.htm) does not work and returns an HTTP 404 error.

-derek


CFP: PKI research workshop

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/02/2002 09:56 AM
To: cryptography@xxxxxxxx, Russell Nelson <nelson@xxxxxxxx>,
warlord@xxxxxxxx, Derek Atkins <warlord@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
aka ... lots of people seem to equate privacy with personal privacy (as well as legislative specification) ... while confidentiality has more of a non-personal connotation

there seems to be 3-4 postings from yesterday that are still lost in the ether ... they are recorded at

http://www.garlic.com/~lynn/aadsm9.htm
&
http://www.garlic.com/~lynn/aadsm10.htm

from
http://www.garlic.com/~lynn/secure.htm
confidentiality
(1) The assurance that information is not disclosed to inappropriate entities or processes. (2) The property that information is not made available or disclosed to unauthorized entities. (3) The prevention of the unauthorized disclosure of information. (4) The concept of holding sensitive data in confidence, limited to an appropriate set of individuals or organizations. [AJP] Assurance that information is not disclosed to inappropriate entities or processes. [FCv1] The concept of holding sensitive data in confidence, limited to an appropriate set of individuals or organizations. [NCSC/TG004] The prevention of the unauthorized disclosure of information. [ITSEC][NIAP] The principle that keeps information from being disclosed to anyone not authorized to access it. Synonymous with secrecy. [AFSEC] The property that information is not made available or disclosed to unauthorized entities. [JTC1/SC27/N734] The property that information is not made available or disclosed to unauthorized individuals, entities, or processes. [TNI] The property that sensitive information is not disclosed to unauthorized individuals, entities or processes. [FIPS140] (see also assurance, data confidentiality, data confidentiality service, privacy, privacy programs, security)

privacy
(1) The ability of an individual or organization to control the collection, storage, sharing, and dissemination of personal and organizational information. (2) The right to insist on adequate security of, and to define authorized users of, information or systems. Note: The concept of privacy cannot be very precise, and its use should be avoided in specifications except as a means to require security, because privacy relates to 'rights' that depend on legislation. [AJP] (1) the ability of an individual or organization to control the collection, storage, sharing, and dissemination of personal and organizational information. (2) The right to insist on adequate security of, and to define authorized users of, information or systems. Note: The concept of privacy cannot be very precise and its use should be avoided in specifications except as a means to require security, because privacy relates to 'rights' that depend on legislation. [TNI] (I) The right of an entity (normally a person), acting in its own behalf, to determine the degree to which it will interact with its environment, including the degree to which the entity is willing to share information about itself with others. (O) 'The right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed.' (D) ISDs SHOULD NOT use this term as a synonym for 'data confidentiality' or 'data confidentiality service', which are different concepts. Privacy is a reason for security rather than a kind of security. For example, a system that stores personal data needs to protect the data to prevent harm, embarrassment, inconvenience, or unfairness to any person about whom data is maintained, and to protect the person's privacy. For that reason, the system may need to provide data confidentiality service. [RFC2828] (see also confidentiality, private communication technology, private key, security, quality of protection) (includes Privacy Enhanced Mail, data privacy, pretty good privacy, privacy programs, privacy, authentication, identification, integrity, non-repudiation, privacy, authentication, identification, non-repudiation, virtual private network)


lynn.wheeler@xxxxxxxx on 1/2/2002 9:18 am wrote:
well PAIN is out of some standards organization (as is 3-factor authentication) .... i agree that privacy and confidentiality is sometimes thot of as different .... but others argue that it reduces to the effectively the same requirements ... even tho different people have different connotations with the two terms.

i had fumble fingered 3-4 URLs yesterday .... and the posting to correct them seems to have gotten suspended for some time in the ether .... note however the url for the security taxonomy and glossary had been typed correctly in a posting made earlier in the day ... i.e.
http://www.garlic.com/~lynn/secure.htm


Small/Secure Payment Business Models

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/03/2002 09:00 AM
To: ietf-trade@xxxxxxxx
Subject: Re: Small/Secure Payment Business Models
somewhat related from basel (aka BIS ... bank for international settlements):

Sound Practices for the Management and Supervision of Operational Risk
http://www.bis.org/publ/bcbs86.htm

Electronic finance: a new perspective and challenges
http://web.archive.org/web/20070610045325/http://www.bis.org/publ/bispap07.htm

from above
A workshop on electronic finance was convened by the BIS on 2-3 July 2001. The internet and related technology has begun to have a profound effect on how financial services are delivered. Discussion about e- finance is widespread within the financial community, covering both its potential to improve efficiency but also possible challenges it poses to financial and monetary stability. Rapid innovation and the paucity of reliable data are creating considerable uncertainty about the nature and size of these challenges. The workshop brought together a diverse group of experts (listed on pages iii-vi) from a range of economies, backgrounds and sectors; including practitioners, academics and central bankers. It focused on current and potential changes in trading systems and exchanges, payment systems and financial institutions.

This volume starts with an overview based on the presentations given during the workshop, some of which are also included in the volume, and the ensuing discussions. The individual papers cover, inter alia, trading in wholesale financial markets, emerging competition in the payment system and the progress of virtual banks. Implications for financial supervision and monetary policy are also specifically addressed in separate papers. As there are a plethora of technical terms associated with the subject, a glossary is included at the end of this volume.


PAIIN security glossary & taxonomy

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/03/2002 03:44 PM
To: "Arnold G. Reinhold" <reinhold@xxxxxxxx>
cc: cryptography@xxxxxxxx, Russell Nelson <nelson@xxxxxxxx>,
    Derek Atkins <warlord@xxxxxxxx>, warlord@xxxxxxxx
Subject: Re: PAIIN security glossary & taxonomy
PAIIN (& PAIN) were from some "security" standards organization and http://www.garlic.com/~lynn/secure.htm

is a security taxonomy & glossary

http://www.garlic.com/~lynn/x9f.htm

is somewhat more of a cryptography oriented glossary & taxonomy since it is taken from the financial standards X9F committee ... which has a heavy crypto focus. As an aside, X9.59 was done in the X9A10 working group under the X9A committee ... which is a business process standards focus (while X9F has security & cryptography focus) .... aka X9.59 is a "secure" business process protocol as opposed to the more traditional X9F cryptography protocol.

The source for X9F taxonomy & glossary
Terms merged from X9F document glossaries: WD15782, X509, X9.8, X9.24, X9.31, X9.42, X9.45, X9.49, X9.52, X9.62, X9.65, X9.69. Terms from ABA/ASC X9 TR1-1999 replace terms from X9F TG-16 glossary (identified by lower case x9 instead of upper-case X9). Original source documents include: X3.92, X3.106, x9.1, x9.5, x9.6, x9.8, x9.9, x9.17, x9.19, x9.23, x9.24, x9.26, x9.28, x9.30, x9.31, x9.41, x9.42, x9.44, x9.45, x9.49, x9.52, x9.55, x9.57, x9.62, x9.69 x9.74, x9.76, x9.78, x9.80, x9.82, and TG-17. (990710)

While the source for "security" taxonomy & glossary:
Terms merged from: AFSEC, AJP, CC1, CC2, FCv1, FIPS140, IATF, IEEE610, ITSEC, Intel, JTC1/SC27/N734, KeyAll, MSC, NCSC/TG004, NIAP, RFC1983, RFC2504, RFC2828, TCSEC, TDI, TNI, and misc. Updated 20010729 with glossary from IATF V3.

reinhold@xxxxxxxx on 1/3/2002 9:26 am wrote:
The PAIIN model (privacy, authentication, identification, integrity, non-repudiation) is inadequate to represent the uses of cryptography. Besides the distinction between privacy and confidentiality, I'd like to point out some additional uses of cryptography which either don't fit at all or are poorly represented in this model:

Anonymity - the ability to communicate without messages being attributed to the sender (e.g. remailers).

Confidential verification -- the ability to verify information without disclosing it (e.g. zero knowledge proofs).

Fragmentation -- dividing control over information among several parties.

Invisibility -- the ability to communicate or store information without being detected. This includes stegonography, low probability of observation communication techniques such as low power spread spectrum, and measures against traffic analysis such as link encryption.

Proof of trespass -- The ability to demonstrate that anyone having access to data knew they were doing so without authorization, (e.g. for trade secret and criminal evidence law).

Remote randomization -- the ability for separated parties to create fair and trusted random quantities.

Resource taxing -- techniques to prove a minimum expenditure of computing resources e.g. hash-cash.

Time delay -- making information available but not immediately.

Transmission assurance -- anti-jam and anti censorship technology.

Use control -- the whole digital rights management scene.

I'm not suggesting this is a complete list or the best breakdown, but I hope is shows that the cryptographic imagination goes beyond PAIIN.

Arnold Reinhold


CFP: PKI research workshop

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/04/2002 10:47 AM
To: Russell Nelson <nelson@xxxxxxxx>
cc: cryptography@xxxxxxxx
Subject: Re: CFP: PKI research workshop
one of the largest financial networks ... slightly different kind
http://www.garlic.com/~lynn/2001n.html#22

again financial ... discussion of additional kinds of risks/threats

Sound Practices for the Management and Supervision of Operational Risk
http://www.bis.org/publ/bcbs86.htm

Intro ...
The purpose of this paper, prepared by the Risk Management Group of the Basel Committee on Banking Supervision (the Committee), is to further the Committee's dialogue with the industry on the development of Sound Practices for the Management and Supervision of Operational Risk. Comments on the issues outlined in this paper would be welcome, and should be submitted to relevant national supervisory authorities and central banks and may also be sent to the Secretariat of the Basel Committee on Banking Supervision at the Bank for International Settlements, CH-4002 Basel, Switzerland by 31 March 2002. Comments may be submitted via e-mail: BCBS.capital@xxxxxxxx or by fax: + 41 61 280 9100. Comments on this paper will not be posted on the BIS website.

on 12/31/2001 8:32 pm wrote:
to which I would add:

3. Cryptography, and therefore PKI, is meaningless unless you first define a threat model. In all the messages with this Subject, I've only see one person even mention threat model. Think about the varying threat models, and the type of cryptography one would propose to address them. Even the most common instance of encryption, encrypted web forms for hiding credit card numbers, suffers from addressing a limited threat model. There's a hell of a lot of known plaintext there.


Hackers Targeting Home Computers

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/07/2002 08:10 AM
To: Hack Hawk <hh@xxxxxxxx>
cc: cryptography@xxxxxxxx,
Digital Bearer Settlement List <dbs@xxxxxxxx>,
    dcsb@xxxxxxxx, Hadmut Danisch <hadmut@xxxxxxxx>
Subject: Re: Hackers Targeting Home Computers
lots of ISPs provide no-server, dial-up service .... they could start with blocking HTTP & other server-type requests going to such ip-address/modem subpools (i.e. customers that are getting dynamic ip address on dial-up lines and have specific service agreements that preclude "server-type" operation on those dial-up service).

some related discussion in various news groups:
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
http://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
http://www.garlic.com/~lynn/2002.html#20 Younger recruits versus experienced veterans ( was Re: The demise of compa
http://www.garlic.com/~lynn/2002.html#24 Buffer overflow
http://www.garlic.com/~lynn/2002.html#25 ICMP Time Exceeded
http://www.garlic.com/~lynn/2002.html#26 Buffer overflow

hh@xxxxxxxx on 1/4/2002 2:08 pm wrote:
It surprises me that providers like Earthlink & GTE (I have one DSL on each) aren't taking measures to filter out virus traffic from infected systems. It seems a simple enough task to me.

It seems to me that the biggest cause of the problems are ignorance and lack of concern as the article suggests. So rather than complain and rant,

I've setup a non-technical alert list for my friends and family to keep them informed and safe.

I try to keep the list fun and easy to read. Its taken a great deal of time and explaining, but slowly more and more of them are beginning to see the bigger picture.

My favorite scenario to lay out for my friends is simple and effective. Lets say that a hacker gains control of your computer and uses it to attack another site/system. Lets say that site is a Fortune 500 company or a military or government site. Even if you don't get into trouble, the FBI could still show up on your door step and take your computer away for analysis. No more email or web for you. Oh, and they'll

probably need to sift through your phone records to see if the hacker dialed out from your computer. Kiss your privacy goodbye.


Hackers Targeting Home Computers

From: Lynn Wheeler
Date: 01/09/2002 04:32 PM
To: Hack Hawk <hh@xxxxxxxx>
cc: cryptography@xxxxxxxx, dcsb@xxxxxxxx,
Eugene Leitl <Eugene.Leitl@xxxxxxxx>,
     Hadmut Danisch <hadmut@xxxxxxxx>, Kent Borg <kentborg@xxxxxxxx>
Subject: Re: Hackers Targeting Home Computers
the idea was attempt to reduce the anarchy within the current infrastructure. an easy justification is possibly 90+percent of ISP customers in the world have contracts that preclude "server" operation. it would be perfectly valid for ISP to filter sever connection packets to those customers. the other is for a long time there is proposal for filtering in-coming packets with spoofed addresses. Once those two are in place .... I would claim that that it is much smaller problem to start going after some of the remaining adverse anarchy. There isn't any single silver bullet .... there is just a lot of different things.

For instance many of the DoS are either 1) spoofed from addresses, and 2) novice customers that have had their machine infected (possibly by hit to some HTTP server that they aren't even using for general internet operation).

Getting a little more extreme .... if one of their customers starts something like an attack against "adjacent" ip-addresses ... then the ISP has both the source customer and the target customers and is doing the filtering. The ISP puts a surcharge on the source attack account .... ISP already have surcharges for things like same client account connect multiple times simultaneously. That would help identify customers with machines at risk (either deliberate or because their machine is doing stuff they don't even know about). Then the ISP has choice of both offering a "hardening" service at additional charge and surcharge for misbehaving machines. Customers might even start buying/selecting software that is rated at being immune from such things.

hh@xxxxxxxx on 1/7/2002 12:15 pm wrote:
Although I originally used the word filter to describe a possible ISP action to address certain problems, the following statement from KB was more what I meant to suggest. And also Lynn Wheeler's statement about Dynamic IP addresses not being allowed to host HTTP services because it's not in the consumer/client agreement anyway.

Hackers Targeting Home Computers

From: Lynn Wheeler
Date: 01/10/2002 10:23 AM
To: Kent Borg <kentborg@xxxxxxxx>
cc: cryptography@xxxxxxxx, dcsb@xxxxxxxx,
Eugene Leitl <Eugene.Leitl@xxxxxxxx>,
    Hadmut Danisch <hadmut@xxxxxxxx>, Hack Hawk <hh@xxxxxxxx>
Subject: Re: Hackers Targeting Home Computers
the problem is that possibly 90% of the users don't really know what you are talking about ... and that is one reason why some of their automatically installed servers running on their platforms get compromised (and they haven't the faintest idea what is talked about).

ISPs don't have arbritrary "no server" requirements .... they have level of service ... aka 1) dial-up/cable/dsl/etc with "no server", 2) dial-up/cable/dsl/etc, "no server", & web hosting separate from their home connection, 3) full(?) service (most frequently permanent connection with permanent ip-address assigned).

Majority of people have "1" or "2" service .... they have no idea what a server is ... even if it is installed and running automatically on their machine ... and is possibly one of the reasons why they are at risk.

The "web hosting" option also typically provides significantly better service than what they could on their own machine (if they knew how).

Since "no server" is already part of the service contract they opted for, filtering out such activity shouldn't be an issue.

kentborg@xxxxxxxx.ort on 1/10/2002 6:49 am wrote:
But that is an annoying limitation to begin with--and not just for people trying to be the next Yahoo.

One of the things that makes the internet is cool that an arbitrary packet can be sent from one arbitrary IP address to another arbitrary IP address. ISPs with "no servers" requirements mostly reduce the internet to "you may browse the web". There is a difference between the internet and the world wide web!, we need to keep reminding ourselves of that and explaining it to those who don't know.

I run my own "server" and most of what happens there is an e-mail server and an sshd that I log into. By running my own e-mail server I can have e-mail selectively forward to my Palm VII, I can have my numeric pager poked to let me know my Palm has e-mail. If I couldn't run my own server I would have to poll someone else's, and I couldn't control my own addresses (my wife does personal e-mail through that box too).

As manufacturers start to assume that RJ-45 jacks that connect to the internet are common, there are all kinds of cool things that become possible, but many would technically be servers. Hell, we currently have remote Oregon Scientific thermometers at home. I think it would be neat to have them connected to the internet. That way I could look at them from work--but also from the living room via my Palm VII.

If one thinks of the internet as a universal digital connection between "stuff" the ability to run "servers" is crucial.

-kb, the Kent who is in favor of policing bad behavior, but who opposes bans on flexibility in an attempt to prevent bad behavior.


credit card & gift card fraud (from today's comp.risks)

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/10/2002 01:13 PM
To: ansi-epay@xxxxxxxx, cryptography@xxxxxxxx,
dcsb@xxxxxxxx
Subject: credit card & gift card fraud (from today's comp.risks).
other postings and recent info from comp.risks:

http://www.garlic.com/~lynn/aadsm9.htm#carnivore3 Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/2002.html#19 Buffer overflow
http://www.garlic.com/~lynn/2002.html#20 Younger recruits versus experienced veterans ( was Re: The demise of compa
http://www.garlic.com/~lynn/2002.html#35 Buffer overflow
http://www.garlic.com/~lynn/2002.html#37 Buffer overflow
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow

========================================================

Date: Mon, 07 Jan 2002 20:07:25 -0500 From: David Farber <dave@xxxxxxxx> Subject: Credit-card cloners' $1B scam

Homemade machines costing about $50 are being used to read credit-card mag-stripes, without having to steal the cards. The information is then e-mailed abroad, where cloned cards are fabricated. This has become a billion-dollar-a-year enterprise.

[PGN-ed from Monty Solomon's e-mail to Dave's IP, subtitled Terrorists, mobsters in on hacking racket, by William Sherman, NY Daily News
http://www.nydailynews.com/today/News_and_Views/City_Beat/a-137421.asp]

[The gadget was first demonstrated in maybe 1960s at Caltech as part of a demo on how poor the mag-striped credit cards were. In spite of that, they won. Dave]

------------------------------

Date: Sat, 29 Dec 2001 09:59:00 -0600 From: Tim Christman <tjc@xxxxxxxx> Subject: Mag-stripes on retail gift cards

Here's a link to an article on MSNBC that I found interesting --
http://www.msnbc.com/news/598102.asp?0dm=C216T&cp1=1

Many retailers are replacing paper gift certificates with small plastic cards containing magnetic stripes, similar to credit cards. Ideally, the purchase of a gift card would result in a database being updated to reflect the balance associated with the card's unique account number.

Some retailers are using sequential account numbers and have no provisions to protect against a thief using a mag-stripe reader/writer to re-program a stolen card or small denomination card so that it matches the account number of a larger valued card purchased by someone else. Many retailers even provide a convenient 1-800 number so that the thief, knowing many valid account numbers, can "shop" for a card of significantly greater value.

The RISK: A form of fraud, difficult to trace, involving a minimal investment in equipment by the thief. Also note that the thief only requires the ability to query the back-end database (through the toll-free number), not the ability to manipulate the records. Perhaps more ominously, the risk is angry family members who find a zero balance on their gift cards!

Solutions: One retailer, mentioned in the article, uses optical bar-coding which can't be re-encoded without defacing the card. Another follows a technique used by many credit card companies -- extra check digits are included in the mag-stripe that are not visible on the face of the card. It seems astounding that this isn't being done by all.

------------------------------


CFP: PKI research workshop

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 01/13/2002 11:04 AM
To: kudzu@xxxxxxxx
cc: Carl Ellison <cme@xxxxxxxx>, cryptography@xxxxxxxx,
Phillip Hallam-Baker <hallam@xxxxxxxx>,
    SPKI Mailing List <spki@xxxxxxxx>
Subject: Re: CFP: PKI research workshop
to be fair ... most commercial CA's have to verify with the domain name infrastructure as to the owner of the domain name ... before issuing a SSL domain name server cert. Note however, one of the justifications for having SSL domain name server cert is because of concerns with regard to domain name infrastructure integrity issues and things like domain name hikjacking. Note however, that if the domain name infrastructure has had a domain name hijack before the SSL server cert is applied for ... when the CA goes to the domain name infrastructure to verify the domain name ownership ... it will verify and a SSL server cert can be issued to the wrong entity (aka the issuing of a SSL server cert is subject to some of the same integrity exposures as concerns that gave rise to having SSL server certs in the first place).

Furthermore, some of the proposals to address domain name infrastructure integrity issues so that CAs can trust their verification as to domain name ownership ... also eliminates justifications for needing SSL server certs

random refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

kudzu@xxxxxxxx on 1/12/2002 12:31 pm wrote:
To be fair, most commercial CA's require evidence of "right to use" a FQDN in an SSL server cert. But your point is apt.

ansi-epay & epay subscritpion

From: Lynn Wheeler
Date: 01/23/2002 10:49 AM
To: dcsb@xxxxxxxx
Subject: ansi-epay & epay subscritpion ....
----- Forwarded by Lynn Wheeler on 01/23/2002 10:47 AM -----

from t.c.jones@xxxxxxxx on 1/22/2002 10:41 pm wrote:
ansi-epay subscriber:

When I started the ANSI X9.59 project over 6 years ago, this list was kindly started by commerce.net. They have since moved on to other concerns. I am still interested in moving the entire web to the new paradigm represented by the evolving X9.59 effort.

Now that there is a draft standard to work from, we need to create the supporting infrastructure, including web site interfaces, dtd definitions, xsl style sheets, etc. I have posted some suggested documents and would like to move forward toward consensus on their final format.

To continue this effort, I have established a distribution list:

mailto:epay-request@xxxxxxxx

So, if you want to continue to participate in the best opportunity to create a true web-based payment solution, send a message with "subscribe" in the subject line to join the above list. To terminate, just send "unsubscribe" to the same list.

..tom jones


Limitations of limitations on RE/tampering (was: Re: biometrics)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/27/2002 02:49 PM
To: Seth David Schoen <schoen@xxxxxxxx>
cc: cryptography@xxxxxxxx
Subject: Re: Limitations of limitations on RE/tampering (was: Re: biometrics)
almost all security is cost/benefit trade-off.

hardware token chips are somewhat analogous to bank vaults .... if the bank vault contains enuf value and somebody is motivated enuf ... they will attempt to find some way to extract the value. This can be either by attacking the vault directly ... or by attacking the infrastructure associated with the vault. I don't believe anybody contends that bank vaults are absolutely impregnable.

the following are discussion of upgrading a magstrip payment card (debit, credit, gift, etc) with a chip and requiring (x9.59) digital signed transactions.

http://www.garlic.com/~lynn/aadsm2.htm#straw
http://www.garlic.com/~lynn/aadsm2.htm#strawm1
http://www.garlic.com/~lynn/aadsm2.htm#strawm2
http://www.garlic.com/~lynn/aadsm2.htm#strawm3
http://www.garlic.com/~lynn/aadsm2.htm#strawm4
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo2
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo3
http://www.garlic.com/~lynn/aepay3.htm#passwords
http://www.garlic.com/~lynn/aepay3.htm#x959risk1
http://www.garlic.com/~lynn/aepay3.htm#x959risk2
http://www.garlic.com/~lynn/aepay3.htm#x959risk3
http://www.garlic.com/~lynn/aepay3.htm#x959risk4

The issue is that the chip is used to do financial transactions ... which have some "credit limit" characteristics, various types of fraud pattern analysis, capable of reporting card lost/stolen within reasonable period of time, etc.

The position is that even w/o PIN &/or biometric controlled chip .... it is still better than today's world where counterfeiting magstripe operation is relatively easy. At least the actual chip card has to be stolen ... as opposed to being able to harvest several hundred thousand credit card account numbers from some webserver and execute large number of fraudulent transactions w/o much additional effort.

With a chip having some form of PIN &/or biometric control, then even stealing the card isn't sufficient, the chip actually has to be subverted/compromised. The issue then is 1) the cost of stealing the card, 2) cost of performing the compromise operation 3) can the compromise be performed before the card has been reported lost/stolen, 4) can a compromised chip be actually used before the card has been reported lost/stolen.

Reversing the question, can a chip be added to an existing magstripe card .... and does the increased effort required to compromise such a chip (compared to compromise/counterfeit magstripe) reduce fraud sufficiently to justify the cost of the chip (and any associated chip acceptor device infrastructure).

misc. card fraud discussion

http://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror14 [FYI] Did Encryption Empower These Terrorists? (addenda to chargebacks)
http://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
http://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate? (addenda)
http://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose4 Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose5 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm10.htm#risks credit card & gift card fraud (from today's comp.risks)
http://www.garlic.com/~lynn/aadsmore.htm#debitfraud Debit card fraud in Canada
http://www.garlic.com/~lynn/aepay6.htm#fraud Online Card Fraud Thirty Times That Offline
http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
http://www.garlic.com/~lynn/aepay6.htm#ccfraud3 "out of control credit card fraud"
http://www.garlic.com/~lynn/aepay8.htm#ccfraud Almost Half UK E-Shopper's Fear Card Fraud (CC fraud increased by 50% in 2k)
http://www.garlic.com/~lynn/aepay8.htm#ccfraud2 Statistics for General and Online Card Fraud
http://www.garlic.com/~lynn/aepay8.htm#x959paper Credit Card Fraud and E-Commerce: A Case Study
http://www.garlic.com/~lynn/aepay9.htm#risks credit card & gift card fraud (from today's comp.risks)
http://www.garlic.com/~lynn/aepay9.htm#skim High-tech Thieves Snatch Data >From ATMs (including PINs)
http://www.garlic.com/~lynn/aepay10.htm#3 High-tech Thieves Snatch Data >From ATMs (including PINs)
http://www.garlic.com/~lynn/aepay10.htm#6 credit card & gift card fraud (from today's comp.risks)
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001h.html#67 Would this type of credit card help online shopper to feel more secure?
http://www.garlic.com/~lynn/2001h.html#68 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#75 Net banking, is it safe???
http://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market

random refs:
http://www.garlic.com/~lynn/2001h.html#61 Security Proportional To Risk
http://www.garlic.com/~lynn/subtopic.html#fraud Risk, Fraud, Exploits
http://www.garlic.com/~lynn/x959.html#x959 X9.59 financial industry standard digital signed transactions

biometrics

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/27/2002 03:07 PM
To: jamesd@xxxxxxxx
cc: cryptography@xxxxxxxx,
"P.J. Ponder" <ponder@xxxxxxxx.tlh.fl.us>
Subject: Re: biometrics
lets say you are replacing pin'ed magstripe card with a chip card needing biometric ... say fingerprint (in place of a PIN) along with chip (in place of magstripe).

there are two issues 1) effort to compromise the biometric is still significantly more difficult that a normal 4-digit pin and 2) there seems to be a large population that writes their 4-digit pin number on their card (as well as numerous tricks of capturing the PIN).

biometric can work almost anywhere if the increment cost of the biometric infrastructure is off-set by a corresponding decrease in fraud/compromise. It doesn't have to be perfect.

Even if similar infrastructures used to capture large number of PINs & magstripe values were used in a chip/biometric infrastructure ... the use of the biometric would still be dependent of stealing the card ... compared to the current pin/magstripe ... where both the pin & magstripe can be captured with some of the techniques.

The issue then is that biometric represents a particularly difficult shared-secret that doesn't have to be memorized compared to PIN values which you find people writing on their cards. The biometric has the advantage of not being written on the card .... so simply stealing the card is not sufficient. Both the biometric value has to be acquired and the specific card stolen.

Reversing the viewpoint ... rather than can I make a perfect authentication system using various biometric implementations? ... Can the addition of biometrics reduce the current fraud rate in a cost effective manner (not does it have to totally eliminate all forms of fraud)?

jamesd@xxxxxxxx on 1/27/2002 10:35 am wrote:
Biometric id can only work when you control the hardware and the adversary does not, and you can also control what hardware the adversary can bring to fool your hardware. This is feasible in an security door, or security checkpoint

Looking back ten years: Another Cypherpunks failure (fwd)

From: Lynn Wheeler
Date: 01/27/2002 03:21 PM
To: Jei <jei@xxxxxxxx>
cc: Crypto List <cryptography@xxxxxxxx>,
    ukcrypto@xxxxxxxx.uk
Subject: Re: Looking back ten years: Another Cypherpunks failure (fwd)
there is another issue here in the corporate world. The issue is availability of corporate assets. One particular study that showed it up had to do with budiness that had no backup of critical disk and that disk had a failure .... 50 percent of such occurances resulted in the company declaring bankruptcy within 30 days.

The whole migration of critical business assets out of the enterprise glasshouse environment to various corporate desktops has highlighted the fact that more or more critical corporate assets are represented by that data (simple example can be customer invoices & billing data).

Enterprises that are doing backup of critical data that is shipped off-site as part of disaster/recovery scenarios are starting to find that such backups require encryption (if not the original data stored on disk). The quandrary then is the possible loss of the capability of decrypting the data when necessary (aka replicated keying material stored in multiple safe locations).

random ref:
http://www.securefs.com/ Secure File System

The Secure File System (SFS) is a joint project between the University of Minnesota and StorageTek which aims to provide an easy to use cryptographic file system. It allows you to store your files securely on remote sites using normal networking protocols (FTP, HTTP, NFS, etc.). You can store your files anywhere without worry of unauthorized access. SFS allows distributed control of protected information through the use of a group server which is responsible for all file access controls.

SFS currently uses smartcards, through MUSCLE software, for authentication and signature purposes. We are currently using Linux with a patched version of UFO, a user-space program that allows us to treat FTP, HTTP, etc. sites as local filesystems. This patched version allows us to catch any file requests and send them to another program to determine if they need to be de/ encrypted. A diagram of the overall operation is available as a PDF file or GIF. Note: Entire project source code will be available including cryptographic routines. Our revised paper which was submitted to the USENIX Security Symposium is also available in ps and pdf formats.

jei on 1/27/2002 6:27 am wrote:
GET #2 is disk encryption. Yes, it sounds so simple, but it is a Great Tabboo, and this time there are no excuses. None. You don't need any network effects. Regulators in the US have little they can do about it. There are about half a dozen great Open Source OSes to work on. And yet there is nothing.

Crypto Winter (Re: Looking back ten years: Another Cypherpunks failure)

Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/27/2002 03:53 PM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: cryptography@xxxxxxxx,
Digital Bearer Settlement List <dbs@xxxxxxxx>, dcsb@xxxxxxxx
Subject: Re: Crypto Winter (Re: Looking back ten years: Another Cypherpunks failure)
the straight-forward mapping of credit card payment to the internet used "MOTO" business process (mail order/telephone order, aka existing non-face-to-face operation) to handle poorly authenticated transactions.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

the financial industries standard work on that was basically to provide authenticated transaction using digital signatures to all electronic payment transactions .... with the requirement given the standards group to preserve the integrity of the financial infrastructure ... aka the x9.59 work applies to credit transactions, debit transactions, ach transactions, gift card transactions, etc. and applicable to all environments (internet, non-internet, point-of-sale, etc)

An x9.59 issue is that it removes the requirement for name associated with the transaction. This meets an EU requirement that at the point-of-sale, an electronic transactions should be as anonymous as cash.

The claim then is the x9.59 work is privacy neutral .... aka identification is removed from the transaction. To the extent there is any identification involved .... it is in mapping individuals to accounts. Gift cards don't have mapping of individuals to accounts ... and x9.59 would neither increase nor decrease the annonymity of gift cards. Gift cards are typically processed with the some point-of-sale terminal as existing debit/credit cards and at least initially typically flow thru the same network. That means that the current webserver based use of credit cards .... flows into the same network that debit and gift cards flows into. The issue isn't the mechanics of enabling debit and gift cards for internet webserver use .... the issue is providing authentication in an "open & insecure" network (the internet) compared to closed/secure network that the point-of-sale terminals directly connect into. X9.59 is defined to provide such authentication in a secure manner across all payment transactions.

With respect to credit &/or debit accounts, again X9.59 neither increases nor decreases the annonymity of those accounts; to the degree that particular institutions allow annonymity associated with such accounts ... x9.59 then is privacy neutral in the protocol.

so the issue here is that the bits and pieces of privacy-enhanced payment transactions already exists and has for some time. a new one doesn't really need to be invented; the basic issue is really the technology needed to transission some of these existing privacy-enhanced payment transactions from closed network to an open network environment.

misc. refs:
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subtopic.html#privacy

raw@xxxxxxxx on 1/27/2002 12:08 pm forwarded:
On Saturday, January 26, 2002, at 09:55 PM, Dr. Evil wrote:

We know that some kind of privacy-enhanced payment system has been one of the long-time c'punk goals, probably for at least ten years. We know that we are probably further away from having that be a reality than we were ten years ago. This is excusable; the obstacles are enormous. You need a lot of people to use it before it's useful, and there are all kinds of regulatory problems. And there are a whole list of other problems, too.


biometrics

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/28/2002 10:52 AM
To: jaltman@xxxxxxxx
cc: cryptography@xxxxxxxx, jamesd@xxxxxxxx,
     "P.J. Ponder" <ponder@xxxxxxxx.tlh.fl.us>
Subject: Re: biometrics
X9.84 biometric standard & some other work means that you could actually record all ten fingers in the card and any one would be acceptable. I believe just plain dirty fingers are much more of a problem than a cut. Simple cut can be "read-around" ... massive cut affecting the whole finger is problem. .... unless you are talking about blood contamination if band-aid is involved which would have to be removed.

What happens when a person forgets their pin (password) (one of the most common customer call center calls ... and represents a significant percentage of total customer call center costs when pin/password support is involved)? One of the reasons that suprising percentage of cards have PINs written on them (and postits with passwords are found near PCs).

What happens when person doesn't have any fingers? You can still support pin-pad in parallel ... assuming that pin-pad is acceptable to people w/o any fingers.

Next level gets somewhat more expensive ... having pin-pad, finger reader, and say iris scan (recording all ten fingers and both iris (lots of work that not only are all iris unique, even identical twins ... but left & right in same person are unique, iris is also possible in most blind people), plus finger-length scan.

jaltman@xxxxxxxx on 1/28/2002 10:38 am wrote
And what happens when I am unable to press my thumb against the reader because it is bandaged; or when my thumb ID fails because it was sliced with a knife.

biometrics

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/28/2002 02:07 PM
To: Sidney Markowitz <sidney@xxxxxxxx>
cc: Cryptography Mailing List <cryptography@xxxxxxxx>
Subject: Re: biometrics
again, the issue is cost/benefit trade-off.

The current implementation of pin/magstripe .... allows evesdropping & other techniques to efficiently electronically collect everything need across a potentially extremely large number of different accounts .... sufficient to perform multiple fraudulent transactions against each one of them.

In the card/biometric example sited .... the water glass example is a total red herring. the card has to be first stolen in order to perform a fraudulent transaction. The claim is that it is more difficult & expensive to fake a biometric lifted off the card than it is to fake a pin written on the card (aka it is much more likely a fingerprint of interest can be lifted from the stolen card). This is much more of a exploit than the water glass red herring .... so the counter is how to make it more difficult that a fingerprint lifted from the card could result in a fraudulent transaction.

Sidney Markowitz on 01/28/2002 10:47 AM wrote:
Shared "secret"? People don't leave a copy of their PIN on every water glass they use.

-- sidney


biometrics (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/28/2002 02:31 PM
To: Sidney Markowitz <sidney@xxxxxxxx>
cc: Cryptography Mailing List <cryptography@xxxxxxxx>
Subject: Re: biometrics (addenda)
so a countermeasure for the card stolen scenario ... just to make the fingerprint compromise of the card slightly harder than the common scenario of the PIN compromise with a PIN written on the card (this is in addition to various liveness tests built into sensors).

... lets say you register the little finger and the finger next to the little finger from the hand that you are least likely to use when handling a card (or water glass). Either of those two fingers are used in the chip scenario case, both the PIN/password and biometric are claimed to have a non-shared-secret paradigm implementation .... aka PIN/password and/or the biometric are registered in your card .... not someplace else. The issue of the card operating is based on the card comparing the information.

The assumption is

1) chip-based
2) non-shared-secret paradigm
3) common situation where people write PIN on the card
4) compromise starts with the minimum of stealing the card first.

So the issue for this non-shared-secret, something you have paradigm is can something you are be used in place of something you know (and the associated short-comings) and be more difficult to compromise (not impossible, just more difficult ... and therefor cost more for the attacker).

Now, a person that absolutely guarantees that they will use a minimum of 8digit random PIN and never write it anywhere .... could elect to have a card that was PIN operated rather than biometric operated. In the card case, the transaction works the same .... it is just a infrastructure issue of whether it wants PIN'ed chips or biometric chips. There seems to be a large body of people where biometric chips is much less subject to compromise (because of various human memory issues).

random shared-secret &/or biometric refs:
http://www.garlic.com/~lynn/aadsmore.htm#bioinfo1 QC Bio-info leak?
http://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
http://www.garlic.com/~lynn/aadsmore.htm#biosigs2 biometrics and electronic signatures
http://www.garlic.com/~lynn/aadsm2.htm#privacy Identification and Privacy are not Antinomies
http://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech12 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
http://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
http://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
http://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
http://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#3dvulner 3D Secure Vulnerabilities?
http://www.garlic.com/~lynn/aadsm9.htm#carnivore2 Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#biometrics biometrics
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
http://www.garlic.com/~lynn/aepay3.htm#x959risk3 Risk Management in AA / draft X9.59
http://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment standard issue
http://www.garlic.com/~lynn/aepay6.htm#harvest2 shared-secrets, CC#, & harvesting CC#
http://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop
http://www.garlic.com/~lynn/aepay6.htm#erictalk Announce: Eric Hughes giving Stanford EE380 talk this
http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
http://www.garlic.com/~lynn/aepay7.htm#ssexploit Shared-Secret exploit
http://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay8.htm#vulner account number & shared-secret vulnerabilities
http://www.garlic.com/~lynn/aepay10.htm#5 I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
http://www.garlic.com/~lynn/99.html#157 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#160 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#165 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#166 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#168 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#170 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#189 Internet Credit Card Security
http://www.garlic.com/~lynn/99.html#214 Ask about Certification-less Public Key
http://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#39 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2000.html#60 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2000b.html#53 Digital Certificates-Healthcare Setting
http://www.garlic.com/~lynn/2000b.html#90 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000f.html#1 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#7 Why trust root CAs ?
http://www.garlic.com/~lynn/2000g.html#5 e-commerce: Storing Credit Card numbers safely
http://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
http://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
http://www.garlic.com/~lynn/2000g.html#49 Use of SET?
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001f.html#25 Question about credit card number
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#35 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001k.html#58 I-net banking security
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security
http://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle attacks?
http://www.garlic.com/~lynn/2001n.html#94 Secret Key Infrastructure plug compatible with PKI
http://www.garlic.com/~lynn/2002.html#9 How to get 128-256 bit security only from a passphrase?
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow

on 1/28/2002 10:47 am wrote:
On Sun, 2002-01-27 at 14:07, lynn.wheeler@xxxxxxxx wrote:
> The issue then is that biometric represents a particularly
> difficult shared-secret that doesn't have to be memorized

Shared "secret"? People don't leave a copy of their PIN on every water glass they use.

-- sidney


Fingerprints (was: Re: biometrics)

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/28/2002 02:54 PM
To: ji@xxxxxxxx
cc: cryptography@xxxxxxxx
Subject: Re: Fingerprints (was: Re: biometrics)
I believe NIST published something about FBI needing 40 minutia standard for registration in their database.

On tv you see these things about lifting partial prints and then sending them off to FBI to try and find who the partial print matches with, aka the FBI better have rather detailed recording of whatever part of the print that happened to be lifted.

That is significantly different than trying to repeat scans in the same way, on nearly identical surface, from the same angle, of a "full" print etc. and approx. match at least a minimum number of points. By comparison, the fbi might need to have higher number of point match based on only a very specific subarea. That would imply that the needed resolution of valid points on the minimum acceptable sized subarea equivalent to typical matching of a full fingerprint.

lets say that FBI wants to do acceptable minutia match on a 15 percent finger subarea (pure conjecture on my part, i've never even read anything about minimum resolution needed in partial print search) ... then presumably the (fbi's) total finger resolution (recording) might need to be six times higher than a straight-foward comparison involving always matching a full-finger to the same full-finger recording using essentially the same methodology each time.

Even at that, the straight-forward fingerprint match (as opposed to the partial print search problem) is frequently subject to greasy & dirty finger problems.

ji@xxxxxxxx at 1/28/2002 1:46 pm wrote:
Last week I had to go to my local INS office to get fingerprinted (part of the green card process is getting your fingerprints OK'ed by the FBI (and also presumably stored for future reference)). The process is computerised, with a low-res scan of all the fingers taken once, and then each finger is individually rolled and scanned on a much higher resolution scanner.

The process took about 20-30 minutes; each finger had to be wiped with some cleaning fluid, the glass on top of the scanner also had to be wiped between scans, and a fingerprinting technician had to roll each of my fingers with the right amount of pressure to get a clear image of the fingerprint. Even with immediate feedback on a large screen showing the fingerprint and how good the scan was, some fingers took as many as five tries to get an acceptable fingerprint.

Now, this was a special-built device whose only purpose is to scan fingerprints, operated under ideal conditions by a trained technician. Draw your own conclusions about the effectiveness of mass-produced fingerprint scanners that would be integrated in other devices.

/ji


biometrics

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/29/2002 03:12 PM
To: Sidney Markowitz <sidney@xxxxxxxx>
cc: Cryptography Mailing List <cryptography@xxxxxxxx>
Subject: Re: biometrics


in the most recent PC magazine (2/12/2002) on the stands ... there is an article "Why Passwords Don't Work" (pg. 68).

In the article they repeat the recommendation that you never use/register the same shared-secret in different domains ... for every environment you are involved with ... you have to choose a different shared-secret. One of the issues of biometrics as a shared-secret "password" (as opposed to the interface between you and your chipcard) is that you could very quickly run out of different, unique body parts.

there are large number of different ways of havesting shared-secrets (pin, password, or biometric) ... the issue isn't so much whether or not pin, passwords, or biometrics can be harvested .... it refers to the business process distinction between shared-secret passwords, pins, or biometrics registered in various databases ... and "secret" passwords, pins, or biometrics that aren't registered in various databases.

sidney@xxxxxxxx on 1/26/2002 10:47 am wrote:
Shared "secret"? People don't leave a copy of their PIN on every water glass they use.

-- sidney


biometrics

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/29/2002 05:39 PM
To: Bill Frantz <frantz@xxxxxxxx>
cc: cryptography@xxxxxxxx
Subject: Re: biometrics
being able to trust the hardware token and the entering of the data ... in the secret, but non-shared-secret paradigm ... can apply equally to pin/password and biometric (i.e. the information is only communicated between the person and their hardware token with no evesdropping) ... aka to some extent something you know and something you are can have effectively similar handling and requirements as long as the paradigm is the same .... aka shared-secret paradigm and "secret" paradigm.

both something you know and something you are have various "leakage" scenarios.

there have been a number of "leakage" scenarios recently in the press with regard to magstripe debit cards where both the magstripe contents and the pin both leak (and subject to harvesting in quantity).

The issue with magstripe is that techniques are fairly readily available to produce counterfeit magstripe cards (defeating the something you have) and those techniques harvest both the magstripe and the PIN at the same time (also defeating the something you know).

Going to a chip card much more difficult to counterfeit would inhibit a lot of the huge fraud ROI .... reducing it much more to stealing individual cards (defeating something you have becomes significantly more difficult than some of the current compromises involved in recording magstripe info & making a counterfeit card).

A question then is it harder to defeat something you are by lifting fingerprint off a stolen card ... than it is to defeat something you know by reading the PIN written on a stolen card?

If you chose a finger that has low probability to be involved in handling the card .... then there is much lower probability that something you are is defeated by lifting fingerprint off of stolen card (and using it).

If you have a single card that is used for all you authentication events and there is the same PIN/password ... and there are no other PIN/passwords in your life ... it would also increase the probability that you would remember it w/o forgetting (and feel the need to write it on the card).

frantz@xxxxxxxx on 1/29/2002 2:14 pm wrote:
Or to state it another way. These cards attempt to use two factor authentication, what you have (the card) and what you know (the PIN). When a user writes the PIN on the card, it becomes one factor authentication. Almost anything that returns it to being two factor security would be an improvement. (Biometrics offers the possibility of 3-factor authentication.

What would be really nice is to be able to have the same PIN/password for everything. With frequent use, forgetting it would be less of a problem, as would the temptation to write it down. However, such a system would require that the PIN/password be kept secret from the verifier (including possibly untrusted hardware/software used to enter it.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz           | The principal effect of| Periwinkle -- Consulting
(408)356-8506         | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz@xxxxxxxx | fair use.              | Los Gatos, CA 95032, USA


biometrics

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/30/2002 10:23 AM
To: <pasward@xxxxxxxx>
cc: cryptography@xxxxxxxx, Bill Frantz <frantz@xxxxxxxx>
Subject: Re: biometrics
The "secret" PIN/Password (or biometric) is respect to the card. The card is then the thing that is actually used to authenticate (aka the card doesn't work as needed unless the correct secret has been presented to the card).

this is different from shared-secret (pin, password or biometric) where the value is registered in some repository and presenting the correct shared-secret (pin, password or biometric) represents the authentication operation. As mentioned in related postings, (shared-secret) passwords "don't work" because a different one is needed for every security domain (in fact, it is a problem with respect to all shared-secret operations).

So a card or hardware token is a something you have authentication. In the case of hardware token, the hardware token has to perform some unique operation for each authentication event. Since the hardware token is using a unique operation for each authentication event (digital signature on unique message; sever sends a unique message containing unique time or number, the receiver appends their own unique time or number to the message and then digitally signs the combined unique message with their hardware token using a private key, the receiver provided part of the message and the digital signature is returned to the original sender as proof of authentication ... aka possessing a unique something you have).

In such a hardware token proof of authentication something you have ... the corresponding "public key" is registered at the sender. The use of the "public key" is only in "authenticating" the message and therefore the person possessing the hardware token something you have. It differs from shared-secret implementations, in that the value registered can be used to both authenticate transmissions as well as originate value transmissions (giving rise to the recommendation that unique shared-secret are to be registered in each unique security domain).

However, since the something you have hardware token is using public key authentication, in place of shared-secret authentication; it is not necessary to have a unique one in every domain.

Now a simple something you have authentication process can be compromised by stealing the something you have hardware token. The hardware token can be more secure by making its correct operation dependent on a secret pin, password, &/or biometric being entered. While the authenticating agency still only does public key digital signature authentication, it has a business process where it establishes that a unique public/private key has been created with a specific kind of hardware token, that the generated private key only exists in that specific hardware token so that the authenticating agency has a high level of confidence that any message digital signature that authenticates with the registered public key .... must have originated from the corresponding hardware token.

To make it more secure than something you have authentication (addressing the stolen token compromise), the authenticating agency also makes sure that the associated token only correctly signs messages when there has been a secret pin, password, and/or biometric entered into the hardware token. Given that the authenticating agency validates the business process and nature of the hardware token (public/private key, digital signature, correct operation dependent on entering correct secret pin, password, biometric), then the authenticating agency can be relatively confident that message digital signatures correctly authenticated by a specific public key must have originated from a specific hardware token in the possession of a specific person.

Now, since the registering of a public key in multiple places doesn't represent a security compromise (of allowing one security domain to impersonate an entity to a different security domain having learned their public key), using the corresponding hardware token in multiple different environments also doesn't represent that kind of security compromise.

So we are now down to the "failure mode" of getting your card stolen AND the secret compromised for that card's correct operation. Does having a unique card for each security domain change the situation? Well, for the majority of cards they are all carried in the same container (wallet, purse, etc) and the unit of theft is most commoningly the container. So the claim there is that for all cards currently carried in the same container .... they could all be reduced to a single card (of the hardware token nature described) w/o significantly changing the failure mode.

Now lets look at the counter scenario.

Every domain that is currently shared-secret passed is upgraded to a hardware token of the type described (digital signature authentication, correct public/private key protection practices, hardware token operation dependent on entering correct secret, etc). I sit at my home computer; from that home computer I currently have possibly 80 different security domains that I access, each with its unique pin/password. Each one of those environments upgrades to the hardware token of the described specific nature (and the value registered in each of the domains is a public key, where knowing the specific public key it is possible to authenticate a message, but knowing the public key it is not possible to originate a fraudulent message ... as in the shared-secret case).

I'm now sitting here with some sort of card acceptor device at my home computer and a pile of 80 hardware tokens each with their own unique activation secret.

I claim that the operational difficulties is more severe than what the world was in progress of heading to in the mid-80s with copy protection floppy disks .... I had a unique copy protected floppy disk for every copy protected application loaded on my hard disk; whenever a specific application needed correct operation, I would have to pull the current floppy from the drive and shuffle thru the pile of copy protected floppy disks looking for the correct one and insert it into the floppy drive.

I contend that having 80 unique hardware tokens, each hardware token with a unique "secret" value (that is not written down anywhere) is a significantly worse human factors operation than the typical '80s copy protection floppy nightmare. Having to remember 80 "secret" values doesn't improve my current situation of having to remember 80 shared-secret values. However, having to also remove the current card and shuffle thru 80 different hardware tokens for the correct card, insert that card, and then enter the correct "secret" associated with that specific hardware token is totally unmanageable.

I contend that the process would support at most 2-3 unique hardware tokens .... with each unique hardware token supporting 20-30 different "logins". Even that I contend has lousy human factors since the person still has to partition and remember the different "logins" associated with a specific token (and still shuffle tokens and hope they get the correct one for the correct applications).

previous discussion of floppy disk analogy applied to hardware tokens:
http://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY

previous shared-secret/secret &/or hardware token discussions:
http://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
http://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
http://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#ecomm Authentication in eCommerce applications
http://www.garlic.com/~lynn/aadsm3.htm#kiss2 Common misconceptions, was Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp-00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
http://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
http://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#ocrp Online Certificate Revocation Protocol
http://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate Revocation Protocol
http://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
http://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
http://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#3dvulner 3D Secure Vulnerabilities?
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm9.htm#carnivore2 Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12 A PKI Question: PKCS11-> PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11-> PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12c A PKI Question: PKCS11-> PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11-> PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm10.htm#biometrics biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
http://www.garlic.com/~lynn/aadsm10.htm#bio5 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
http://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
http://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY
http://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment standard issue
http://www.garlic.com/~lynn/aepay6.htm#harvest2 shared-secrets, CC#, & harvesting CC#
http://www.garlic.com/~lynn/aepay6.htm#erictalk Announce: Eric Hughes giving Stanford EE380 talk this
http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
http://www.garlic.com/~lynn/aepay7.htm#ssexploit Shared-Secret exploit
http://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay8.htm#vulner account number & shared-secret vulnerabilities
http://www.garlic.com/~lynn/2000.html#39 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#46 question about PKI...
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2000b.html#53 Digital Certificates-Healthcare Setting
http://www.garlic.com/~lynn/2000b.html#90 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000f.html#1 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
http://www.garlic.com/~lynn/2000g.html#5 e-commerce: Storing Credit Card numbers safely
http://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
http://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
http://www.garlic.com/~lynn/2000g.html#49 Use of SET?
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001f.html#25 Question about credit card number
http://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#63 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
http://www.garlic.com/~lynn/2001h.html#75 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#10 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001i.html#35 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001k.html#58 I-net banking security
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security
http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle attacks?
http://www.garlic.com/~lynn/2001n.html#94 Secret Key Infrastructure plug compatible with PKI
http://www.garlic.com/~lynn/2002.html#9 How to get 128-256 bit security only from a passphrase?
http://www.garlic.com/~lynn/2002.html#39 Buffer overflow
http://www.garlic.com/~lynn/99.html#79 Authentication in eCommerce applications
http://www.garlic.com/~lynn/99.html#214 Ask about Certification-less Public Key
http://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI

on 01/30/2002 06:13 AM wrote:
Bill Frantz writes:


>What would be really nice is to be able to have the same PIN/password for
>everything.

Do you really mean that? Sure, if I only have to remember one thing it is easier for me. It is also a complete nightmare if it is ever compromised.

----------------------------------------------------------------------------
Paul A.S. Ward, Assistant Professor  Email: pasward@xxxxxxxx
University of Waterloo                      pasward@xxxxxxxx
Department of Computer Engineering   Tel: +1 (519) 888-4567 ext.3127
Waterloo, Ontario                    Fax: +1 (519) 885-1208
Canada N2L 3G1                       URL: http://shoshin.uwaterloo.ca/~pasward


biometrics (addenda)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/30/2002 11:08 AM
To: <pasward@xxxxxxxx>
cc: cryptography@xxxxxxxx, Bill Frantz <frantz@xxxxxxxx>
Subject: Re: biometrics (addenda)
note however, with regard to the 80 hardware tokens, or 3 hardware tokens, or 1 hardware token scenario .... a single or small number of hardware tokens (with each hardware token having an associated public key registered multiple places) then can become a personal choice.

The current scenario with shared-secret demands that a unique shared-secret be used in each unique security domain.

In the hardware token scenario the same hardware token can be used with multiple unique security domains w/o exposing the ability to originate fraudulent transactions.

The biggest exposure is lost/stolen and effectively denial of service.

Since these hardware tokens are many more times harder to compromise than eavesdropping a pin/password, possibly a thousand times harder (which includes the act of physical theft), then potentially the security profile allows such a token to be used in a hundred different security domains (exposure proportional to difficulty of compromise).

This doesn't take into account the human operational factors .... like memory problems with multiple "secret" values ... and if there are multiple tokens, each with a large number of security domains, remembering which security domain is associated with which token.

Welome to the Internet, here's your private key

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/04/2002 09:53 AM
To: "Trei, Peter" <ptrei@xxxxxxxx>
cc: cryptography@xxxxxxxx, "'Jaap-Henk Hoepman'" <hoepman@xxxxxxxx>
Subject: RE: Welome to the Internet, here's your private key
ignoring for the moment the question of why certificates would be needed at all ....

then public/private key technology is currently being used for (at least) two distinct & different business processes

1) authentication
2) encryption

The business process of human person authentication has some requirements about impersonation ... leading to a business requirement that only the person being authenticated should have access to the authentication material (aka only the specific person can originate an authenticated transaction). A hardware token that generates the key-pair inside the token and the private key can never leave the token can satisfy unique person authentication thru one-factor authentication something you have. The person is the only one with their specific token and that token is the only container for their specific private key.

The business process for encryption can be totally different. The assets being encrypted may be corporate assets, not the individuals. In the case of using public/private key in conjunction with encryption of corporate assets, the business requirements totally change. The corporation has a valid requirement for recoverying valuable corporate assets under any condition (failure/loss of token, person leaves the company, etc).

In the person authentication case, the impersonation issue typically is viewed as outweighing the failure/loss of token issue. In the case of encryption of corporate assets, the failure/loss of the token issue would typically outweight any issues of guaranteeing absolutely that the key can only occur in a single place not knonw by anybody.

The requirement for a private key only existing in a single place under control of a single person isn't an attribute of the public/private key technology .... it is an attribute of a specific business process and associated business requirements related to that business process. However, there are other business process applications for public/private key technology than human person authentication which can have somewhat different requirements.

aads chip strawman .... public/private key hardware token w/o any certificates
http://www.garlic.com/~lynn/x959.html#aads

random refs:
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12 A PKI Question: PKCS11-> PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11-> PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11-> PKCS12
http://www.garlic.com/~lynn/aadsm10.htm#diskcrypt Looking back ten years: Another Cypherpunks failure (fwd)
http://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
http://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001n.html#54 The demise of compaq
http://www.garlic.com/~lynn/2002.html#7 The demise of compaq

ptrei@xxxxxxxx on 2/4/2002 9:13 am wrote:
One other scheme I've seen, and which, while it doesn't give me warm fuzzies, seems reasonable, is to issue the the enduser a smartcard with a keypair on it. The SC generates the pair onboard, and exports only the public half. The private half never leaves the SC (there is no function on the card to export it).

If you trust the above, then the only copy of the private key is on the SC, despite it having been generated without the end users participation.

Peter


Welome to the Internet, here's your private key

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/08/2002 10:14 AM
To: Jaap-Henk Hoepman <hoepman@xxxxxxxx>
cc: cryptography@xxxxxxxx, "Arnold G. Reinhold" <reinhold@xxxxxxxx>
Subject: Re: Welome to the Internet, here's your private key
There are very good reasons for having hardware tokens as part of 2/3-factor authentication ... i.e. the hardware token is a something you have .... and very good reason for such hardware tokens to become ubiquitous. Now if there is USB plub&play for things like PC/SC ... there is much lower dependency on what the form factor that hardware token needs to take (modulo some of the EU finread standards issues) that it would be transparent to software whether it is talking USB to dongle hardware token or usb reader+card.

As mentioned previously .... the issue regarding divulging the private key is a business issue. Using public/private key in an authentication business scenario has a real requirement that the private key not be known to minimize impersonation issue. However, public/private key in encryption business scenario involving valuable corporate assets could lead to "loss" of those assets of there is a token/private-key failure/loss/stollen. Where private key is being used in business scenario involving protection of valuable corporate assets .... there is real requirement for high level of redundancy ... and the "impersonation" scenario doesn't apply as it does in the authentication business scenario; aka while the technology may be the same ... the different requirements are driven from the business needs & applications.

it is possible to establish business practices and audit procedures to significantly increase confidence in the operation of hardware tokens. ... misc. aads chip strawman discussions
http://www.garlic.com/~lynn/x959.html#aads

impresonation refs:
http://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)

misc. eu finread discussions
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market

1/2/3-factor authentication
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose14 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm7.htm#rhose15 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001g.html#1 distributed authentication
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/2001j.html#44 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security

jaap-henk hoepman <hopeman@xxxxxxxx on 2/8/2002 9:12 am wrote:
I think there _are_ good business reasons for them not wanting the users to generate the keys all by themselves. Weak keys, and subsequent compromises, may give the CA really bad press and resulting loss of reputation (and this business is built on reputation anyway). So: there are good reasons not to let the CA generate the private key, but also good reasons to not let the user generate the keys all by himself.

So the question is: are there key generation protocols for mutually distrustful parties, that would give the CA the assurance that the key is generated using some good randomness (coming from the CA) and would give the user the guarantee that his private key is truly private. Also, the CA should be able to verify later that the random data he supplied was actually used, but this should not give him (too much) advantage to find the private key.

A smartcard based system might be useful here (as suggested by other subscribers here). But a software only solution is preferred because it would maker the application area much broader (because the user does not have to be supplied with special hardware - terminals + smartcards).

Jaap-Henk


AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/21/2002 03:31 PM
To: dcsb@xxxxxxxx
Subject: AN AGILITY-BASED OODA MODEL FOR THE e-COMMERCE/e-BUSINESS ENTERPRISE
i'm fond of boyd related subject & papers ... aka http://www.garlic.com/~lynn/subtopic.html#boyd

.... here is another one (although there are places like the application of KISS to the aads chip strawman which takes somewhat opposite position) ... slightly dated:


http://www.belisarius.com/
Since the mid-1970's, there has been a subtle yet increasing awareness that the dominant business model of the 20th century, based upon limited product variability and mass production manufacturing techniques, no longer is applicable to the rapidly-fragmenting, information-intensive, electronically wired and individually-customized global marketplace which has emerged. The pervasiveness and universality of this awareness has been accelerated in the past few years with the explosive growth and penetration of the Internet and its diversity of e-Commerce/e-Business implementations.

Blair accidently sells the roads (was Re: BBC article: "Vehicles 'tracked'")

From: Lynn Wheeler
Date: 02/24/2002 10:28 AM
To: "R. A. Hettinga" <rah@xxxxxxxx>
cc: cypherpunks <cypherpunks@xxxxxxxx>,
Digital Bearer Settlement List <dbs@xxxxxxxx>, dcsb@xxxxxxxx
Subject: Re: Blair accidently sells the roads (was Re: BBC article: "Vehicles 'tracked'")
note that it didn't eliminate the economies of scale of network operation .... there is still massive investment required in things like fiber. some amount of the current pricing could possibly be an "overbuilt" & "over-invested" infrastructure ... some number of operations going bankrupt ... and then some amount of the infrastructure available on a pricing structure that doesn't require full ROI recovery of the original investment (i.e. written off).

the "electronics" revolution moved some amount of the economies of scale into multi-billion dollar fabrication plants that have to be written off every 3-5 years and new ones built at possible 2-3 times the cost of the previous generation. In some sense, the massive investment in the enabling infrastructure has led to fewer, much more massive operations that are required to support the massive cost reductions in other areas.

also, much of this is disruptive technology ... either because of technology itself and/or the second order effects of infrastructure cost reduction ... which would tend to have a distabelizing effects on operations that had reached some sort of stabilized equilibrium under earlier cost/price paradigms. One question might be "is the choatic nature of the players in hese market segments a permanent feature or a temporary transition phase as infrastructure attempts to re-establish some equilibrium after significant disruptive influence"?

past ref:
http://www.garlic.com/~lynn/aadsmail.htm#law dbts: More on law vs economics

rah@xxxxxxxx at 2/24/2002 7:44 am wrote:
The resulting exponential drop in the price of switching completely inverted the economies of scale of network operation, changing its very structure from an increasingly larger, more unified hierarchy with exactly one fixed-price circuit-switched route from any two nodes to a massively geodesic network with a combinatorical number of routes between any two nodes, each route with its own possible auction price depending on latency, noise, and lots of other factors. The result was a dramatic reduction in transaction cost, price discovery, market entry, and of course firm size, and ultimately a dramatic increase in the number of phone companies, even vertically integrated ones, and we haven't even started cash-settlement of network bandwidth yet. (The paradox, of course, is that every "information worker" who sits in front of a microcomputer to work these days, sizeably more than half the female population -- even a MacDonald's cashier -- is doing exactly what a turn-of-the-20th-century telephone operator does, reprocessing and routing information from one part of the network to another.)

Q: Where should do I put a max amount in a X.509v3 certificat e?

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 03/11/2002 11:03 AM
To: stephen.farrell@xxxxxxxx
cc: "PKIX (Grupo de la IETF)" <ietf-pkix@xxxxxxxx>,
"Yee, Peter" <pyee@xxxxxxxx>, Roberto Opazo Gazmuri <roberto@xxxxxxxx>,
     Tom Gindin <tgindin@xxxxxxxx>, "'Tim Polk'" <tim.polk@xxxxxxxx>
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificat e?
I believe that the "purchase limit" idea was to emulate the "signing limit" checks of, at least pre-80s (if not earlier) ... effectively having some value to limit various kinds of fraud and exploits in an offline transaction environment.

Sometime in the '60s, they started to discover these type of controls was being circumvented by things like multiple operations ... and so started the migration to online transactions that could support aggregation, velocity, rate, etc. Moving to an online transaction paradigm in the '70s & '80s (real time, aggregation, velocity, rate, etc) started to make the offline, credential "signing limit" paradigm redundant and superfluous.

stephen.farrell@xxxxxxxx on 3/11/2002 7:10 am wrote:
Tom,


> Since this "purchase limit" is intended as a constraint on signed
> orders, and those are signed by PKC's rather than AC's, the constraint
> needs to go into the PKC.

That's wrong (even ignoring the careless language). The requirement is presumably that the amount is somehow attested to by an authority. That doesn't distinguish an AC-based from a PKC-based solution.

> Does profiling a new extension in new-part1 make sense?

IMO, No - and not until there'll be a lot of RP s/w that pays attention.

Stephen.


Q: Where should do I put a max amount in a X.509v3 certificate?

Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 03/11/2002 01:44 PM
To: Dale Gustafson <degustafson@xxxxxxxx>
cc: "PKIX (Grupo de la IETF)" <ietf-pkix@xxxxxxxx>,
    "Yee, Peter" <pyee@xxxxxxxx>,
Roberto Opazo Gazmuri <roberto@xxxxxxxx>, "'Tim Polk'" <tim.polk@xxxxxxxx>
Subject: Re: Q: Where should do I put a max amount in a X.509v3 certificate?
not just a matter of churning the certificate credential as the "signing limit" is changed .... but also a return to pre-80s offline transactions where there is no aggregation (month to date, qtr to date, year to date), velocity, rate, acceleration, SKU-based limits (pencils, gasoline, tires, computers), MCC-based limits, etc.

... aka even simple credit limit or daily limit ... isn't single transaction value but aggregation of transactions.

credential/certificate limits like checks with signing value limits was old-fashion, offline, non-electronic solution ... but much of the infrastructure has moved to online with minimum of simple real-time aggregation making the old fashion offline credential/certificate limits redundant and superfluous.

random refs:
http://www.garlic.com/~lynn/aadsmail.htm#fraud Human Nature ... a little cross-posting
http://www.garlic.com/~lynn/aadsmail.htm#law dbts: More on law vs economics
http://www.garlic.com/~lynn/aadsmore.htm#hcrl3 Huge CRLs
http://www.garlic.com/~lynn/aadsmore.htm#killer1 Killer PKI Applications
http://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#01 redundant and superfluous (addenda)
http://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
http://www.garlic.com/~lynn/aadsm6.htm#ppsem3 Payment Processing Seminars
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate? (addenda)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
http://www.garlic.com/~lynn/aepay6.htm#pkimort2 problem with the death of X.509 PKI (forwarded)
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
http://www.garlic.com/~lynn/aadsm10.htm#limit Q: Where should do I put a max amount in a X.509v3 certificat e?

degustafson@xxxxxxxx on 3/11/2002 8:26 am wrote:
Hi Peter,

Actually, similar things are suggested in "Planning for PKI, Best Practices for deploying the PKI" by Russ Housley and Tim Polk -- see the section subtitled "Attribute Certificates", pp 274 - 277. Note that the entire chapter is titled "Future Developments" so, presumably, one needs to proceed with appropriate caution.

In any event, the rationale for placing such an attribute within a separate Attribute Certificate is clearly spelled out:

1) a Certification Authority is most likely "not authoritative" for this kind of information

2) this kind of information is also likely to change frequently which would cause highly undesirable certificate churn if included in x.509 v3 ID certificates.

In contrast, an application-specific attribute could be certified by an authoritative AA and carried in an Attribute Certificate. The AC is defined as an extension of a suitable ID certificate. Such would be necessary but perhaps not sufficient for general use of ACs to convey application-specific user priviledges. For example, since much attribute information is not disclosed outside a well-defined group of relying parties, there would also need to be a (general purpose?) mechanism to limit access to AC information exchanged.

Best Regards,

Dale Gustafson


AADS Postings and Posting Index, next, previous - home