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 accidentally 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
https://www.garlic.com/~lynn/aadsm8.htm#rhose17
specific discussion of hiding credit card numbers:
https://www.garlic.com/~lynn/2001h.html#61 ... security proporitional to risk
https://www.garlic.com/~lynn/2001h.html#58 ... Net banking, is it save??
misc stuff about security proportional to risk (i.e. related to threats):
https://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror10 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
https://www.garlic.com/~lynn/aepay6.htm#harvest harvesting of credit card numbers
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001e.html#77 Apology to Cloakware (open letter)
https://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
https://www.garlic.com/~lynn/2001f.html#35 Security Concerns in the Financial Services Industry
https://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001h.html#45 Article: Future Trends in Information Security
https://www.garlic.com/~lynn/2001h.html#64 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/2001l.html#56 hammer
misc. vulnerability analysis (related to threat model):
https://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc
https://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay7.htm#3dsecure4 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/2001c.html#38 How Commercial-Off-The-Shelf Systems make society vulnerable
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
https://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
also see security taxonomy & glossary at:
https://www.garlic.com/~lynn/index.html#glossary
i.e.
https://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:
https://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
https://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 aspect of integrity can
be dependability .... leading to things like:
https://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)
https://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):
https://www.garlic.com/~lynn/aepay3.htm#riskm
https://www.garlic.com/~lynn/aepay3.htm#riskaads
also the gao report listed:
https://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:
https://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
https://www.garlic.com/~lynn/aadsm8.htm#rhose17
^^^^ ^^^^^^^
..........................
specific discussion of hiding credit card numbers:
https://www.garlic.com/~lynn/2001h.html#61 ... security proporitional to risk
https://www.garlic.com/~lynn/2001h.html#58 ... Net banking, is it save??
^^
......................
see
https://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.
https://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
https://www.garlic.com/~lynn/aadsm9.htm
&
https://www.garlic.com/~lynn/aadsm10.htm
from
https://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.
https://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
https://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
https://www.garlic.com/~lynn/secure.htm
is a security taxonomy & glossary
https://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
https://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:
https://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001n.html#30 FreeBSD more secure than Linux
https://www.garlic.com/~lynn/2001n.html#71 Q: Buffer overflow
https://www.garlic.com/~lynn/2002.html#20 Younger recruits versus experienced veterans ( was Re: The demise of compa
https://www.garlic.com/~lynn/2002.html#24 Buffer overflow
https://www.garlic.com/~lynn/2002.html#25 ICMP Time Exceeded
https://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 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:
https://www.garlic.com/~lynn/aadsm9.htm#carnivore3 Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
https://www.garlic.com/~lynn/2002.html#19 Buffer overflow
https://www.garlic.com/~lynn/2002.html#20 Younger recruits versus experienced veterans ( was Re: The demise of compa
https://www.garlic.com/~lynn/2002.html#35 Buffer overflow
https://www.garlic.com/~lynn/2002.html#37 Buffer overflow
https://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:
https://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.
https://www.garlic.com/~lynn/aadsm2.htm#straw
https://www.garlic.com/~lynn/aadsm2.htm#strawm1
https://www.garlic.com/~lynn/aadsm2.htm#strawm2
https://www.garlic.com/~lynn/aadsm2.htm#strawm3
https://www.garlic.com/~lynn/aadsm2.htm#strawm4
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo1
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo2
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo3
https://www.garlic.com/~lynn/aepay3.htm#passwords
https://www.garlic.com/~lynn/aepay3.htm#x959risk1
https://www.garlic.com/~lynn/aepay3.htm#x959risk2
https://www.garlic.com/~lynn/aepay3.htm#x959risk3
https://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
https://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror14 [FYI] Did Encryption Empower These Terrorists? (addenda to chargebacks)
https://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
https://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate? (addenda)
https://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose4 Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose5 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
https://www.garlic.com/~lynn/aadsm10.htm#risks credit card & gift card fraud (from today's comp.risks)
https://www.garlic.com/~lynn/aadsmore.htm#debitfraud Debit card fraud in Canada
https://www.garlic.com/~lynn/aepay6.htm#fraud Online Card Fraud Thirty Times That Offline
https://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
https://www.garlic.com/~lynn/aepay6.htm#ccfraud3 "out of control credit card fraud"
https://www.garlic.com/~lynn/aepay8.htm#ccfraud Almost Half UK E-Shopper's Fear Card Fraud (CC fraud increased by 50% in 2k)
https://www.garlic.com/~lynn/aepay8.htm#ccfraud2 Statistics for General and Online Card Fraud
https://www.garlic.com/~lynn/aepay8.htm#x959paper Credit Card Fraud and E-Commerce: A Case Study
https://www.garlic.com/~lynn/aepay9.htm#risks credit card & gift card fraud (from today's comp.risks)
https://www.garlic.com/~lynn/aepay9.htm#skim High-tech Thieves Snatch Data >From ATMs (including PINs)
https://www.garlic.com/~lynn/aepay10.htm#3 High-tech Thieves Snatch Data >From ATMs (including PINs)
https://www.garlic.com/~lynn/aepay10.htm#6 credit card & gift card fraud (from today's comp.risks)
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001h.html#67 Would this type of credit card help online shopper to feel more secure?
https://www.garlic.com/~lynn/2001h.html#68 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#75 Net banking, is it safe???
https://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
https://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
random refs:
https://www.garlic.com/~lynn/2001h.html#61 Security Proportional To Risk
https://www.garlic.com/~lynn/subintegrity.html#fraud Risk, Fraud, Exploits
https://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.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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:
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.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:
https://www.garlic.com/~lynn/aadsmore.htm#bioinfo1 QC Bio-info leak?
https://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
https://www.garlic.com/~lynn/aadsmore.htm#biosigs2 biometrics and electronic signatures
https://www.garlic.com/~lynn/aadsm2.htm#privacy Identification and Privacy are not Antinomies
https://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
https://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
https://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
https://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech5 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech12 cardtech/securetech & CA PKI
https://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))
https://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
https://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
https://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
https://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
https://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#3dvulner 3D Secure Vulnerabilities?
https://www.garlic.com/~lynn/aadsm9.htm#carnivore2 Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
https://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
https://www.garlic.com/~lynn/aadsm10.htm#biometrics biometrics
https://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
https://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
https://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
https://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
https://www.garlic.com/~lynn/aepay3.htm#x959risk3 Risk Management in AA / draft X9.59
https://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY
https://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment standard issue
https://www.garlic.com/~lynn/aepay6.htm#harvest2 shared-secrets, CC#, & harvesting CC#
https://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop
https://www.garlic.com/~lynn/aepay6.htm#erictalk Announce: Eric Hughes giving Stanford EE380 talk this
https://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
https://www.garlic.com/~lynn/aepay7.htm#ssexploit Shared-Secret exploit
https://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay8.htm#vulner account number & shared-secret vulnerabilities
https://www.garlic.com/~lynn/aepay10.htm#5 I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
https://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
https://www.garlic.com/~lynn/99.html#157 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#160 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#165 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#166 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#168 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#170 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#189 Internet Credit Card Security
https://www.garlic.com/~lynn/99.html#214 Ask about Certification-less Public Key
https://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
https://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
https://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
https://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
https://www.garlic.com/~lynn/2000.html#39 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2000.html#60 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2000b.html#53 Digital Certificates-Healthcare Setting
https://www.garlic.com/~lynn/2000b.html#90 Question regarding authentication implementation
https://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation
https://www.garlic.com/~lynn/2000f.html#1 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#7 Why trust root CAs ?
https://www.garlic.com/~lynn/2000g.html#5 e-commerce: Storing Credit Card numbers safely
https://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/2000g.html#49 Use of SET?
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001f.html#25 Question about credit card number
https://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#35 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
https://www.garlic.com/~lynn/2001k.html#58 I-net banking security
https://www.garlic.com/~lynn/2001k.html#61 I-net banking security
https://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle attacks?
https://www.garlic.com/~lynn/2001n.html#94 Secret Key Infrastructure plug compatible with PKI
https://www.garlic.com/~lynn/2002.html#9 How to get 128-256 bit security only from a passphrase?
https://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:
https://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY
previous shared-secret/secret &/or hardware token discussions:
https://www.garlic.com/~lynn/aadsm2.htm#stall EU digital signature initiative stalled
https://www.garlic.com/~lynn/aadsm2.htm#strawm3 AADS Strawman
https://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB
https://www.garlic.com/~lynn/aadsm3.htm#cstech4 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#ecomm Authentication in eCommerce applications
https://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))
https://www.garlic.com/~lynn/aadsm3.htm#kiss8 KISS for PKIX
https://www.garlic.com/~lynn/aadsm3.htm#kiss9 KISS for PKIX .... password/digital signature
https://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#ocrp Online Certificate Revocation Protocol
https://www.garlic.com/~lynn/aadsm5.htm#ocrp3 Online Certificate Revocation Protocol
https://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
https://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
https://www.garlic.com/~lynn/aadsm7.htm#rhose9 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#3dvulner 3D Secure Vulnerabilities?
https://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
https://www.garlic.com/~lynn/aadsm9.htm#carnivore2 Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12 A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12c A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
https://www.garlic.com/~lynn/aadsm10.htm#biometrics biometrics
https://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
https://www.garlic.com/~lynn/aadsm10.htm#bio5 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
https://www.garlic.com/~lynn/aepay3.htm#votec (my) long winded observations regarding X9.59 & XML, encryption and certificates
https://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
https://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
https://www.garlic.com/~lynn/aepay3.htm#passwords Passwords don't work
https://www.garlic.com/~lynn/aepay4.htm#nyesig e-signatures in NY
https://www.garlic.com/~lynn/aepay6.htm#x959b X9.59 Electronic Payment standard issue
https://www.garlic.com/~lynn/aepay6.htm#harvest2 shared-secrets, CC#, & harvesting CC#
https://www.garlic.com/~lynn/aepay6.htm#erictalk Announce: Eric Hughes giving Stanford EE380 talk this
https://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
https://www.garlic.com/~lynn/aepay7.htm#ssexploit Shared-Secret exploit
https://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay7.htm#3dsecure2 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay8.htm#vulner account number & shared-secret vulnerabilities
https://www.garlic.com/~lynn/2000.html#39 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000.html#46 question about PKI...
https://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2000b.html#53 Digital Certificates-Healthcare Setting
https://www.garlic.com/~lynn/2000b.html#90 Question regarding authentication implementation
https://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation
https://www.garlic.com/~lynn/2000f.html#1 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#4 Why trust root CAs ?
https://www.garlic.com/~lynn/2000g.html#5 e-commerce: Storing Credit Card numbers safely
https://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/2000g.html#49 Use of SET?
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001f.html#25 Question about credit card number
https://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#63 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#75 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#9 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#10 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001i.html#35 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#0 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#9 E-commerce security????
https://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
https://www.garlic.com/~lynn/2001k.html#58 I-net banking security
https://www.garlic.com/~lynn/2001k.html#61 I-net banking security
https://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#5 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle attacks?
https://www.garlic.com/~lynn/2001n.html#94 Secret Key Infrastructure plug compatible with PKI
https://www.garlic.com/~lynn/2002.html#9 How to get 128-256 bit security only from a passphrase?
https://www.garlic.com/~lynn/2002.html#39 Buffer overflow
https://www.garlic.com/~lynn/99.html#79 Authentication in eCommerce applications
https://www.garlic.com/~lynn/99.html#214 Ask about Certification-less Public Key
https://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
https://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
https://www.garlic.com/~lynn/99.html#235 Attacks on a PKI
https://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 recovering
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
https://www.garlic.com/~lynn/x959.html#aads
random refs:
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12 A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm10.htm#diskcrypt Looking back ten years: Another Cypherpunks failure (fwd)
https://www.garlic.com/~lynn/2000e.html#45 IBM's Workplace OS (Was: .. Pink)
https://www.garlic.com/~lynn/2001j.html#16 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001n.html#54 The demise of compaq
https://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
https://www.garlic.com/~lynn/x959.html#aads
impresonation refs:
https://www.garlic.com/~lynn/aadsm10.htm#keygen Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
https://www.garlic.com/~lynn/99.html#172 checks (was S/390 on PowerPC?)
misc. eu finread discussions
https://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel Borenstein: Carnivore's "Magic Lantern"
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really
secure?
https://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
1/2/3-factor authentication
https://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose13 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose14 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm7.htm#rhose15 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
https://www.garlic.com/~lynn/aadsmore.htm#schneier Schneier: Why Digital Signatures are not Signatures (was Re :CRYPTO-GRAM, November 15, 2000)
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall?
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation
practicalities
https://www.garlic.com/~lynn/2001g.html#1 distributed authentication
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2001j.html#44 Does "Strong Security" Mean Anything?
https://www.garlic.com/~lynn/2001j.html#49 Are client certificates really secure?
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#34 A thought on passwords
https://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
https://www.garlic.com/~lynn/subboyd.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 accidentally 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 accidentally 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:
https://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:
https://www.garlic.com/~lynn/aadsmail.htm#fraud Human Nature ... a little cross-posting
https://www.garlic.com/~lynn/aadsmail.htm#law dbts: More on law vs economics
https://www.garlic.com/~lynn/aadsmore.htm#hcrl3 Huge CRLs
https://www.garlic.com/~lynn/aadsmore.htm#killer1 Killer PKI Applications
https://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))
https://www.garlic.com/~lynn/aadsm4.htm#01 redundant and superfluous (addenda)
https://www.garlic.com/~lynn/aadsm5.htm#spki4 Simple PKI
https://www.garlic.com/~lynn/aadsm6.htm#ppsem3 Payment Processing Seminars
https://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
https://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
https://www.garlic.com/~lynn/aadsm7.htm#auth2 Who or what to authenticate? (addenda)
https://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop
https://www.garlic.com/~lynn/aepay6.htm#pkimort2 problem with the death of X.509 PKI (forwarded)
https://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
https://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
https://www.garlic.com/~lynn/99.html#238 Attacks on a PKI
https://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