Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next, previous
- home
- Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
- Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
- Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
- Non-repudiation (was RE: The PAIN mnemonic)
- Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
- Non-repudiation (was RE: The PAIN mnemonic)
- TWIST - Commercial Payments
- Phillips, Visa push contactless payments in consumer devices
- (federal) PKI spending hits $1b
- Setting X.509 Policy Data in IE, IIS, Outlook
- fraud and phishing attacks soar
- are debit cards safe?
- A combined EMV and ID card
- A combined EMV and ID card
- payment api for v1.0 internet open trading protocol ... fyi
- PKI International Consortium
- PKI International Consortium
- PKI International Consortium
- PKI International Consortium
- PKI International Consortium
- PKI International Consortium
- Identity (was PKI International Consortium)
- secret hackers to aid war on internet fraud
- PKI International Consortium
- Privacy, personally identifiable information, identity theft
- Single Identity. Was: PKI International Consortium
- privacy, authentication, identification, authorization
- Re:Identity Firewall. l PKI International Consortium
- Definitions of "Security"?
- eCompute ECC2-109 Project has PROBABLE solution
- eCompute ECC2-109 Project has PROBABLE solution (now official)
- Payment system and security conference
- visa cards violated, BofA reissuing after hack attack
- misc from IETF
- The future of security
- Online credit card fraud rocks Indonesia
- Yahoo releases internet standard draft for using DNS as public key server
- Moving forward with pre-shared keys
- Study: ID theft usually an inside job
- The future of security
- The future of security
- Yahoo releases internet standard draft for using DNS as public key server
- Article on passwords in Wired News
- Is finding security holes a good idea?
- Is finding security holes a good idea?
- x9.99 financial PIA standard now available from ANSI e-store
- authentication and authorization (was: Question on the state of the security industry)
- authentication and authorization ... addenda
- Japanese bank offers 'biosecurity' account
- Use cash machines as little as possible
- authentication and authorization (was: Question on the state of the security industry)
- authentication and authorization
- FUJITSU DEVELOPS ENCRYPTION TECH THAT TAKES 20 MILLION YEARS TO BREAK
- Using crypto against Phishing, Spoofing and Spamming
- Using crypto against Phishing, Spoofing and Spamming
- Using crypto against Phishing, Spoofing and Spamming
- Question on the state of the security industry
- dual-use digital signature vulnerability
- Using crypto against Phishing, Spoofing and Spamming
- dual-use digital signature vulnerability
- Using crypto against Phishing, Spoofing and Spamming
Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)<
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: "McMeikan, Andrew" <Andrew.McMeikan@xxxxxxx>
Cc: "'Anne & Lynn Wheeler'" <lynn@xxxxxxxx>,
"'cryptography@xxxxxxxxxx'" <cryptography@xxxxxxxxxx>
Subject: RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Date: Mon, 05 Jan 2004 08:34:12 -0700
At 03:10 PM 1/5/2004 +1100, McMeikan, Andrew wrote:
The only danger to such a world of peace would be those who refuse
goverment signed keys and use their own payment provider and trade
amounst themselves, they would have to be hunted down separately.
The original issue involves three factor authentication
http://www.garlic.com/~lynn/subintegrity.html#3factor
- something you have
- something you know
- something you are
A public key can be representative of hardware token ... say a token
where the private key is generated on the token and is designed to
never leave the token. A digital signature that can be verified by the
corresponding public key can be used to infer possession of the
hardware token (something you have). Furthermore, a hardware token can
be designed to only work in a specific way when the appropriate
pin/password (something you know) or biometric (something you are)
have been entered into the token. The entity receiving the digital
signature doesn't need a copy of the pin/password or biometric (making
it a shared-secret) but infers by the operation of the hardware token
that there has been something you know &/or something you are
authentication to have happened.
An institution can enroll the person in possession of the token using
whatever processes they feel necessary (say anonymous for ISPs up to
"know your customer" identity as required by various legislation for
financial institutions).
The issue is that can the validating of the entity in possession of
the token be a separate business process issue from validating the
integrity of the hardware token. The idea is that the integrity of the
hardware token can be treated as a totally separate business process
from the process of validating the entity being enrolled (an entity
that happens to possess the hardware token).
Treating them as totally separate business process doesn't preclude
collapsing the enrolling of the entity and enrolling the hardware
token into a single process. However, not treating them as separate
business process will pretty much preclude ever being able to treat
them as separate processes.
So the question is as part of the enrolling process, can the integrity
of the hardware token be treated as a totally separate business issue
from enrolling characteristics of the entity in possession of the hardware
token (say like the advertisements for the service that allows being
able to research the history of a used car). Most institutions already
have all sorts of business processes involved with enrolling the
characteristics of an entity. What would be the incremental
requirement for being able to enroll (& trust) the integrity of
a consumer presented hardware token?
So, i'm a little bit biased, I claimed that I ruthlessly discarded all
feature and function from AADS chip strawman that wasn't needed for
trusted authentication
http://www.garlic.com/~lynn/x959.html#aadsstraw
complexity can contribute to insecurity ... KISS and focus can
contribute to security.
Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: "McMeikan, Andrew" <Andrew.McMeikan@xxxxxxx>
Cc: "'cryptography@xxxxxxxxxx'" <cryptography@xxxxxxxxxx>
Subject: RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Date: Mon, 05 Jan 2004 11:19:06 -0700
aka ... in some sense the reply
http://www.garlic.com/~lynn/aadsm17.htm#0 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
is also attempting to keep separate the business processes of
identification and authentication. Will it continue to be allowed to
have authentication events (i can prove that i'm authorized to do
something) w/o also always mandating that whenever there is an
authentication operation will proof of identity always also be
required?
today, I supposedly can open an ISP account, provide proof of payment
and supply a password for that account (w/o also having to provide a
gene pattern for identification). Would it ever be possible to simply
substitute a digital signature and public key in lieu of a password
when opening an account (where that digital signature may have been
performed by a hardware token)?
will it continue to be possible in the future to have separation
between authentication and identification business processes ... or
will at some time, things change and all authentication events also
always require identification?
Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: <Andrew.McMeikan@xxxxxxx>
Cc: "'cryptography@xxxxxxxxxx'" <cryptography@xxxxxxxxxx>
Subject: RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Date: Tue, 06 Jan 2004 07:45:58 -0700
At 07:06 PM 1/6/2004 +1100, McMeikan, Andrew wrote:
This is the real bit, how tied to identity can it be bound. How
tightly do people want to be bound. In any abuse or failing of
identity whatever that identity was authorized for is going to be the
*Responsibility* of the true identity. I frequently give out my true
name (there it is at the top :) perhaps there are times I specifically
do not.
a lot of current identity theft is evesdropping &/or otherwise
harvesting shared-secrets and then doing replay attacks. part of this
is that the prevalence of shared-secrets paradigm creates significant
human factors problems with being able to memorize all the possibly
scores of shared-secrets that are used as something you know
authentication. the obvious is various kinds of skimming of real
transactions and the harvesting of merchant payment transactions file
to extract the shared-secrets sufficient to perform fraudulent
financial transactions. two aspects of this:
- the transactions are based on static shared-secrets that are
subject ... effectively to replaying the shared-secret
- a security guideline about requiring unique shared-secret
for every security domain; so (among other things) that an
authorized entity in one security domain can't extract your
shared-secret and perform fraudulent transactions in another
security domain (as simple as one employee at one merchant
getting your shared-secret and performing fraudulent
transaction at another merchant).
slightly related is posting about security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61
somewhat related issue is because of the human factor memory issue, a
common authentication shared-secret (something you know)
is mothers maiden name. The upside is that most people will tend to
remember it. The downside is
- it really isn't all that secret
- using the same shared-secret in multiple different security
domains violates the security principle requiring a unique (and
preferably unpredictable) shared-secret in every security
domain.
So, my assertion is that a significant amount of fraudulent activity
that is currently labeled identity theft is really poorly implemented
shared-secret, something you know authentication. Furthermore, various
aspects of existing shared-secret implementations lends itself to
electronic collection and/or harvesting of large batches of
shared-secrets that, then in turn can be used in fraudulent
transactions (significant fraud return-on-investment).
So one solution is significantly changing all such existing
authentication transactions and turning them into identification
transactions .... where the cost of faking the identification is
significantly higher than the value of the fraudulent transactions.
Another solution is significantly changing the existing shared-secret
authentication transactions and turning them into non-shared-secret
authentication transactions ... where the cost of faking the
authentication is significantly higher than the value of the
fraudulent transactions.
I've frequently described the use of asymmetric cryptography and
digital signature technology to infer something you have
authentication because enrollment establishes 1) private key is
contained in a specific hardware token and 2) characteristics can be
established about the hardware token where it has generated a random
key pair in the token and the token never voluntarily gives up the
private key.
Enrollment may also establish that such a hardware token also works in
a specific way when a unique pin/password and/or biometric has been
passed to the token. Later when transactions arrive that are believe
to have been digitally signed by such a hardware token, it may also be
valid to infer that something you know and/or something you
are authentication has also occurred (w/o the pin/password and/or
the biometric needing to be passed to the authenticating institution
and becoming a shared-secret).
It will probably always be possible to subvert various kinds of
identification and/or authentication technologies. Two issues are:
- can such subversion be made more costly than any resulting
risk/fraud
- can solution be authentication oriented as opposed to
identification oriented
The second is possibly a bias towards not wanting to proliferate
identity oriented events into each and every transaction that occurs
in the world (when authentication may be sufficient).
With regard to the first point, the claim has been that X9.59 changes
the existing retail electronic transactions from shared-secret based
to non-shared-secret based ... and therefor eliminates the existing
vulnerability of harvesting merchant transaction files as a threat
(discussed in the security proportional to risk reference).
http://www.garlic.com/~lynn/x959.html#x959
Furthermore, as implied in the security proportional to risk
reference, it may never be possible to eliminate the transaction file
harvesting, what x9.59 did was eliminate the threat of fraud that
results when such harvesting takes place.
Non-repudiation (was RE: The PAIN mnemonic)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Jerrold Leichter <jerrold.leichter@xxxxxxxxxx>
Cc: Cryptography <cryptography@xxxxxxxxxx>
Subject: Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Date: Wed, 07 Jan 2004 10:28:34 -0700
At 10:14 AM 1/7/2004 -0500, Jerrold Leichter wrote:
Now that we've trashed non-repudiation ... just how is it different
from authentication? In both cases, there is a clear technical
meaning (though as with anything in mathematics, when you get right
down to it, the details are complex and may be important): To produce
an authenticator/non-repudiable signature, you must have access to the
secret. There isn't, at this level, even any difference between the
requirements for the two. Where we get into trouble is in attempting
to bind the real world to the mathematics. In each case, the receiver
wants to be able to say:
lets say they are somewhat different threat models (but may have some
partial overlap).
it would be possible to give a dozen people the same passprhase and
have some degree of confidence that only the permitted entities
entitled to do something were authenticated. however, if one of them
claimed that they didn't do some specific thing ... there would be
difficulty in differentiating between the different entities as to which
entity had been authenticated at any specific time. some of the best
practices security guidelines for authentication (like not sharing
passwords) have more to do with non-repudiation ... than straight
authentication.
key-escrow can be considered mandatory for encryption keys under
non-single-point-of-failure and availability best practices. At the
same time there may be mandatory requirements for NOT having
key-escrow for authentication keys under non-repudiation best
practices ... even when the cryptographic technology is identical. The
key-escrow policies are exactly opposite depending on whether the
business use is encryption or authentication.
a straight-forward authentication issue might be whether a particular
message originated from authorized entity. That would not necessarily
include the sense that the entity agreed with the terms and conditions
described in the body of the message (say a financial transaction).
This is somewhat akin to various EULA agreements that have people
clicking on various buttons .... which is not an issue of
authentication but of agreement; aka repudiation can include things
that are outside the scope of authentication (not whether the message
originated from me ... but "do i fully agree with what is included in
the body of the message"). neither identification nor authentication
by itself can necessarily include the concept of agreement.
repudiation can include a number of items outside the sense of
identification and authentication (like aggreement).
Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: "McMeikan, Andrew" <Andrew.McMeikan@xxxxxxx>
Cc: "'cryptography@xxxxxxxxxx'" <cryptography@xxxxxxxxxx>
Subject: RE: Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
Date: Thu, 08 Jan 2004 10:42:35 -0700
At 12:21 PM 1/8/2004 +1100, McMeikan, Andrew wrote:
Key word here is allowed, yes authentication without identification is
possible, yes in my opinion it is desirable to allow, do I think it
will stay that way, YES, do I think it will stay legal?? Well trends
seem to indicate that it is becoming like a card carrying communist in
the McCarthy era, dangerous if caught.
So allowed by whom? Should it be allowed that such things have to be
allowed, or is it part of an inherent right to privacy that if only
claimed by a large enough number of society might become the norm
instead of suspicious.
two scenarios, sort of to be considered
1) x.509 identity certificates from the early '90s with all sorts of
privacy information went thru a transformation into relying-party-only
certificates for use in financial transactions; basically only entity
information was some sort of account number and a public key ... plus
a whole bunch of other gobbly-gook which still made the resulting
certificate 4k-12k bytes ... and were supposedly to be attached to
retail electronic payments that in their ISO8583 format tended to be
60-100 bytes in size ... aka a pki certificate represented a two
orders of magnitude payload bloat. Furthermore, since the
relying-party-only certificate was being transmitted back to the
relying-party that issued the certificate ... which already possessed
all the information contained in the certificate ... the two orders of
magnitude payload bloat couldn't even be justified on providing any
useful information that they didn't already have.
http://www.garlic.com/~lynn/subpubkey.html#rpo
2) HIPPA, GLB, FTC. etc .... have a bunch of stuff about disclosure of
privacy information ... aka the type of stuff that would be typically
associated with identity. authentication only wouldn't necessary
preclude or mandate that the authentication information be linked to
some sort of identity ... it just is that you wouldn't want the
authentication event itself to include identity related information
.... which could have a tendency to run afoul of various privacy
regulatory and legislative issues (like HIPPA, GLB, and FTC).
http://www.garlic.com/~lynn/subpubkey.html#privacy
I've started a merged privacy taxonomy and glossary
http://www.garlic.com/~lynn/index.html#glosnote
taking some stuff from the merged security taxonomy and glossary
... but adding stuff from HIPPA, GLB, and FTC; somewhat in part
because I've been participating in a X9 privacy standard effort.
Non-repudiation (was RE: The PAIN mnemonic)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
Date: Fri, 09 Jan 2004 15:21:32 -0700
To: iang@xxxxxxxxxxx
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: [Fwd: Re: Non-repudiation (was RE: The PAIN mnemonic)]
Cc: Jerrold Leichter <jerrold.leichter@xxxxxxxxxx>, Cryptography <cryptography@xxxxxxxxxx>
At 01:18 PM 1/9/2004 -0500, Ian Grigg wrote:
Which is to stress the original problem: the technical
side can identify an agent (a.k.a. a key) and it can
transmit an authentication via some key-based protocol,
but "agreement" is a human concept, drawn from the legal
world in this context.
So the best that can be done is to record signals of
agreement, but these can easily be faked, so they are
just additional, quasi-worthless, steps in the protocol
at the technical level.
Recording signals of agreement is like recording
a handwritten signature. It is not conclusive as it
can be easily forged. But, the (legal) protocol
includes some additional steps such as asking "did
you make that signature?" In this sense, the protocol
of agreement can only be completed in the realm of
dispute, by confirming the steps that the human made
with the memorable tokens done at that time.
my understanding is that most of the EULA issues aren't about whether
it is possible to fake or not fake the pressing the buttons ... but
whether it is reasonable that the person clicking the buttons could
have reasonably believed that they were doing something else.
protocols can have a piece of hardware digitally signing a message as
part of authentication ... w/o implying anything at all about
agreement. using the EULA example, if a process step is used for
anything other than agreement ... then the claim could be made that
can be inferred as the other process (authentication?) and not
agreement.
you also somewhat see that in POS terminal debit transactions .... the
PIN is entered as part of authentication .... but there are additional
YES/NO button pressings that is required ... that is part of inferring
agreement ... and independent of authentication.
TWIST - Commercial Payments
From: Lynn Wheeler
Date: 01/12/2004 06:37 AM
To: 'internet-payments' <internet-payments@xxxxxxxxxx>
Subject: TWIST - Commercial Payments
ran across this when using search engines looking for some non-US
glossary sources
http://web.archive.org/web/20040116021358/http://www.ateb.be/doc/doc-6-108-3.pdf
As described in the document, TWIST draws on efforts from CRG/Edifact,
IFX, RosettaNet and SWIFT (consumer to bank messages).
from above:
Seven major international banks (ABN-AMRO bank, Bank of America,
Citigroup, Deutsche Bank, HSBC, JPMorgan Chase, Standard Chartered
Bank) have worked in a TWIST taskforce together with other industry
experts that are members of TWIST to ensure universal applicability of
the requirements. Their involvement has been instrumental for the
speed and thoroughness of the analysis, for the neutrality of the
design, the universal applicability of the solutions and the critical
mass that ensures the necessary implementation effort in the near
future. This collaboration effort has been further benefited from the
knowledgeable input of various experts from consultancy firms,
software providers and corporations. All involved in TWIST support the
need for universal, open and non-proprietary standards. The TWIST task
force led by Ernst & Young and Shell aims at driving at one single,
open, and non-proprietary standard that can be implemented by any
corporate and bank, irrespective of size, location, or market
position.
Phillips, Visa push contactless payments in consumer devices
From: Lynn Wheeler
Date: 01/12/2004 10:37 AM
To: 'internet-payments' <internet-payments@xxxxxxxxxx>
Subject: Phillips, Visa push contactless payments in consumer devices
http://www.eetimes.com/sys/news/OEG20040112S0009
Philips, Visa push contactless payments in consumer devices
By Junko Yoshida
EE Times
January 12, 2004 (10:01 a.m. ET)
LAS VEGAS Philips Semiconductors and Visa International joined forces
at the Consumer Electronics Show (CES) last week to demonstrate
contactless payment and connectivity applications based on a
Philips-developed technology called near-field communication.
Their goal is to build an infrastructure for universal payment card
readers in consumer electronics and mobile telecommunication
devices. Philips will embed NFC chips in various consumer devices
while Visa provides an authentication service. Under the plan,
consumers should be able to download data or pay for digital services
through the NFC interface using a contactless card or device with
NFC-equipped consumer equipment.
... snip ..
(federal) PKI spending hits $1b
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Cryptography <cryptography@xxxxxxxxxx>
Subject: (federal) PKI spending hits $1b
Date: Fri, 16 Jan 2004 11:41:00 -0700
(federal) PKI spending hits $1b
http://web.archive.org/web/20040215095737/http://www.washingtontechnology.com/news/1_1/daily_news/22526-1.html
GAO Faults 'inconsistent' online security programs ($1b on PKIs)
http://www.informationweek.com/story/showArticle.jhtml?articleID=17301563
Setting X.509 Policy Data in IE, IIS, Outlook
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 01/27/2004 02:09 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxxxxxx>
cc: ietf-pkix@xxxxxxxxx, "Stephen Kent" <kent@xxxxxxxxxx>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
Another issue is that many of the traditional business trust models
have tended to be some sort of contract (exchange of value) between
two parties; supposedly the CA trust propagation relationship
typically is between the relying party and the CA ... while the
contractual relationship is between the public key owner and the CA
(except for situations like relying-party-only certificates .... where
the same party is both selling/issuing the certificates and also
relying on the certificates) .... aka the trust propagation
relationship and the contractual trust relationship are unrelated.
another solution has been to try and have some sort of governmental
legislative proclamation ... declaring/mandating a trust relationship
... even if one doesn't exist from a business and/or contractual
standpoint.
the gsa federal government PKI .... seems to be a variation on the
relying-party-only certificate .... the CAs appear to have a GSA
contract where they effectively are agents of the federal government
(i.e. the CAs are federal agents issuing/selling certificates on
behalf of the federal government). These certificates are then for use
by the federal government as the relying party (making them
relying-party certificates).
now, the next issue is that the majority of the federal PKI programs
appear to be online operation ... which in turn would supposedly allow
the relying-party federal government ... to have online access to the
original of the information where the relying-party-only
certificate represents a stale, static copy of some such
information stored in some databsse. Also, possibly because of privacy
issues, the stale, static (certificate) copy is likely also a
subset of the information that is actually stored in some database
(collected at the time the registration authority function was
performed involving the registration of the public key and information
about the owner of the public key). One possible issue is that the
operations being performed in conjunction with the federal PKI program
certificates are of such low value, that it doesn't justify having
online, timely access to the real information (even when it appears
that all of the applications in the program are otherwise online)
... aka long-time assertion that relying-party, stale,
static, subset certificate information tends to be redundant
and superfluous given that there can be online access to the
original, timely information.
on 1/27/2004 12:27 pm anders.rundgren wrote:
May I help you with some analysis?
PKI projects historically started with the CA, and this has influenced
some PKI standards as well, the RFC3280 policy support is a prime
example of that.
However, being a CA, is being an "information producer" which is
considerably easier than being an "information consumer" as only the
latter has to "interpret" and maybe "act" upon what the information
producer says.
If the designers of the policy system instead had focused on the
relying party (the "information consumer"), they had probably realized
that a relying party consists of 1) the relying party software 2) the
people depending on the relying party software.
Further analysis shows that the "people" category, except in the most
trivial scenarios, consists of "trust administrators" and "end users".
In the background there are also some legal folks lurking around.
If you then apply the design constraint that all these entities should
have the best possible system adapted for the entities' actual tasks
and competence, you would end-up with a very different policy scheme.
Commercial CAs know that, and therefore with few exceptions, continue
to ignore a system that was not designed with the "customer in mind".
The major difference is that policy in commercial CAs is associated
with the CA, eliminating the need for moving trust processing and
trust administration tasks into the application and user domains
respectively. This enables the creation of shrink-wrap RP software as
well as shielding end-users from too close encounters with PKI.
This also allows trust admins to anytime, using "CA properties", view
what "they actually currently trust", without having a single EE
certificate!
Anders
fraud and phishing attacks soar
From: Lynn Wheeler
Date: 02/18/2004 07:15 AM
To: 'internet-payments' <internet-payments@xxxxxxxxxx>
Subject: fraud and phishing attacks soar
Fraud and phishing attacks soar
http://www.vnunet.com/News/1152838
Email fraud and phishing attacks rocketed by more than 50 per cent in
January, with around six new attacks sent to millions of consumers
each day.
... snip ...
are debit cards safe?
From: Lynn Wheeler
Date: 02/18/2004 07:17 AM
To: 'internet-payments' <internet-payments@xxxxxxxxxx>
Subject: are debit cards safe?
are debit cards safe?
http://www.globetechnology.com/servlet/story/RTGAM.20040204.gtkirwanfeb4/BNStory/Technology/
ATM fraud in the U.S. is believed to have totalled $2-billion (U.S.)
in 2002, and in the U.K. to have risen 37 per cent to 29.1-million
pounds, up from 21.2-million pounds. And how do criminals steal from
ATMs?
... snip ...
A combined EMV and ID card
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 03/14/2004 11:12 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxxxxxx>
cc: 'internet-payments' <internet-payments@xxxxxxxxxx>,
Pekka Honkanen <lhonkane@xxxxxxxx>
Subject: Re: A combined EMV and ID card
that was one of the issues that financial institutions and others
discovered ten years about the x.509 identity certificate concept
... the horrendous leakage of privacy information. it was one of the
reasons that financial institutions tried relying-party-only
certificates in the mid-90s that was restricted to only containing an
account number (in part because of the horrible privacy information
leakage).
at least one of the scenarios involved relying-party-only certificate
appended to a digitally signed credit/debit payment transaction. This
in itself created an enormous difficulty resulting in various kinds of
extreme rube golberg designs. the issue was that a typical 8583
financial transactions was on the order of 60-80 bytes, ignoring for the
moment the size of an appended digital signature .... the problem was
that even a relying-party-only certificate could be 6k-12kbytes in
size. Using elementary, standard security principles and following
standard end-to-end security and integrity policies .... aka digitally
signed message with appended relying-party-only certificate flowing
from consumer straight-through to the consumer's issuing financial
institution resulted in a 100 times bloat in the message size aka
60-80 byte message would have a tremendous, horrible bloat to one
hundred times larger ( aka typically message of 60 bytes times 100
becomes six thousand bytes to twelve thousand bytes).
this is one of the places that originated my observation about a
relying-party-only certificate being redundant and superfluous (in
addition to truely horrible size bloat). The useful information in the
12kbyte relying-party-only certificate is the user's public key and
the account number. Since the account number is also contained in the
8583 transaction, it is redundant and superfluous to have it in the
certificate. Since it is a relying-party-only certificate, the user's
public key is registered in the institutions account record for that
user. When the 8583 transaction reaches the institution, they can
retrieve the public key from the account record based on the account
number in the 8583 transaction (to verify the digital signature). That
makes the public key in the relying-party-only certificate redundant
and superfluous. With the only two pieces of useful information in the
relying-party-only certificate shown to be redundant and superfluous,
then the certificate itself is shown to be redundant and superfluous.
Rather than coming up with a rube goldberg design corrupting
elementary, basic end-to-end security and integrity principles in
support of one hundreds times bloat in message size (attempt to
preserve the appending of a redundant and superfluous certificate)
.... just eliminate the redundant and superfluous certificate
altogether.
misc. past postings on relying-party-only certificates:
http://www.garlic.com/~lynn/subpubkey.html#rpo
misc. past postings on the subject:
http://www.garlic.com/~lynn/subpubkey.html#privacy
as an aside ... somewhat in support of work on X9 PIA standard
... I've started a privacy glossary and taxonomy .... complimenting
the other glossaries and taxonomies at:
http://www.garlic.com/~lynn/index.html#glosnote
annders rundgren on 3/14/2004 12:13 pm wrote
Thanx Pekka,
A slightly disturbing "side effect" of mixing accounts
and IDs using the Finish and Swedish schemes, is that
each time you perform a payment, the POS terminal
can without any PIN-codes etc, also read the user's ID-
certificates (public keys), effectively "leaking" identity
information to parties that should not necessarily have
such information.
Anders
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
A combined EMV and ID card
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/15/2004 12:52 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxxxxxx>
cc: 'internet-payments' <internet-payments@xxxxxxxxxx>,
Pekka Honkanen <lhonkane@xxxxxxxx>
Subject: Re: A combined EMV and ID card
sporadic problem is confusing authentication and identification. there
are various gov. requirements that may require identification as part
of account establishment but that shouldn't translate into requirement
for identification for every transaction related to such
account. transactions (like payments) have requirements where
authentication should be sufficient w/o involving identification and
all the privacy problems that creates.
note that many of the existing payment cards are subject to
transaction skimming and subsequently using the information to create
counterfeit cards.... even the EMV yes cards that have been cited in
various press on the other side of the atlantic pond.
there can be a number of issues with using a single hardware token for
both payment and non-payment purposes with detrimental information
leagage between the two domains. primarily the problems happen when
the design of the infrastructure involves static data (of the kind
that is subject to skimming with the possibility of later using the
skimmed information forfraudulent purposes). However, it is possible
to design an infrastructure that doesn't involve the kind of static
information that can be subject to skimming and fraudulent use.
One such solution is to design an infrastructure around secure
authentication as a business process .... regardless of the type of
business operation (payment, non-payment, etc). An additional objective
might be to avoid shared-secrets (where elementary security principles
require unique shared-secret for every distinct security domain). A
shared-secret could be PINs, passowords, or even physical keys (aka
you typically don't have a house key also being used for entry to an
employer's business location) ... aka a single, shared-secret based
device that was used in multiple different security domains is subject
to possibility of information leakage that could be used by one domain
to compromise a different domain.
misc. past posts discussing confusing authentication and identification
http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
http://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
http://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#2 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aepay12.htm#4 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aadsm14.htm#40 The real problem that https has conspicuously failed to fix
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
http://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
anders rundgren on 3/15/2004 1:39 am wrote:
Lynn,
You are right but the financial institutions now try to leverage
their position as trusted third parties for things outside of
their payment territory. It is hard to see that e-governments
can be realized without a generic ID without huge costs
and user inconvenience. As I have said numerous times
before in this list:
ID <> Payments
But I would also like to mention my addendum
ID >> Payments
That is, a functional ID can in an on-line world replace the need
for most other resources as you by using an ID towards resource
providers "can be whatever you need to be, or have what you
need to have".
To combine ID and Payment cards though opens a can of worms.
If the consumer uses the same PIN for all functions a rogue relying
party app can technically perform advanced "phishing" in the
background while you are paying. Most people don't like
multiple PIN-codes. I'm one :-)
Anders
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
payment api for v1.0 internet open trading protocol ... fyi
From: Lynn Wheeler
Date: 03/26/2004 09:37 AM
To: 'internet-payments' <internet-payments@xxxxxxxxxx>
Subject: payment api for v1.0 internet open trading protocol ... fyi
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Internet Open Trading
Protocol Working Group of the IETF.
Title : Payment API for v1.0 Internet Open Trading Protocol (IOTP)
Author(s) : W. Hans, et al.
Filename : draft-ietf-trade-iotp-v1.0-papi-06.txt
Pages : 103
Date : 2004-3-25
The Internet Open Trading Protocol provides a data exchange format
for trading purposes while integrating existing pure payment
protocols seamlessly. This motivates the multiple layered system
architecture which consists of at least some generic IOTP application
core and multiple specific payment modules.
A URL for this Internet-Draft is:
http://web.archive.org/web/20040404155551/http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-06.txt
PKI International Consortium
From: Lynn Wheeler
Date: 04/02/2004 11:49 AM
To: Shaheen.Nasirudheen@xxxxxxxx
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
"PKIX list" <ietf-pkix@xxxxxxxxx>, owner-ietf-pkix@xxxxxxxxxx
Subject: Re: PKI International Consortium
sort of the fundamental issue is that the certificate design point is
for offline processing .... it contains sufficient information that it
is possible for the relying party to perform some operation based on
relying on the certificate w/o needing recourse to any additional
information.
the problem is also sort of analogous to the issue of needing
different shared-secrets for different security domains ... recent
topic drift in sci.scrypt ...
http://www.garlic.com/~lynn/2004d.html#40 RFC-2898 Appendix B
lets say i have a passport certificate and i wish to do a financial
transaction on a chase bank account. the passport certificate probably
doesn't provide any information with regard to whether i even have a
financial account with chase bank .... aka the passport certificate
contains insufficient information for a relying party expecting a
valid financial transaction.
so for an offline certificate paradigm to work .... it just about
means a unique certificate for every operational domain ... containing
sufficient information that a relying party will go ahead and do
whatever operation based on the contents of the certificate.
now, if the relying party really wants a financial transaction
executed with chase .... then there is not only the issue of the
contents of a stale, static certificate designed as a solution for
offline environments ... but there is the possibility that the relying
party might be interested in online, timely, and possibly aggregated
information (not conducive for incorporation in a stale, static
certificate designed for solving problems associated with offline
environments) ... in which case, the relying party might be inclined
to perform a online operation with the authoritative agency for
that particular kind of operation. In the case of a customer financial
transaction, the relying party might be interested in performing a
financial transaction with the customer's financial institution (as
the authoritative agency for that kind of operation).
For this type of scenario, it is then possible to claim for valuable
and/or important operations (where relying parties may be interested
in timely information, as opposed to stale, static information
possibly contained in a certificate), that direclty contacting the
authoritative agency makes the use of stale, static certificates
redundant and superfluous. If the authoritative agency has registered
a public key and issued a stale, static certificate .... then if the
relying party is directly contacting the authoritative agency ... the
substitute stale, static certificate (issued for addressing the needs
of offline operations) is redundant and superfluous.
shaheen nasirudheen on 4/2/2004 8:57 am wrote:
Hello everyone,
I appreciate your feedback and most of the replies were referring to
identrus.com . My basic concern is from a customer's point of view. If
I have a digital certificate issued by a single authority that is
considered trusted internationally by all financial as well as other
commercial institutions, then I do not require to have a certificate
for Institution -1 and another for Institution -2. Do we have
something in place that takes of this issue. I would be happy to carry
and protect that one certificate which is trusted by everyone.
Thank you,
Shaheen Nasirudheen
JPMorgan ACCESS, Portal Security
978 805 1815
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
PKI International Consortium
Refed: **, - **, - **
From: Lynn Wheeler
Date: 04/02/2004 04:46 PM
To: Arshad Noor <arshad.noor@xxxxxxxxxx>
cc: PKIX list <ietf-pkix@xxxxxxxxx>, Stephen Kent <kent@xxxxxxxxxx>,
owner-ietf-pkix@xxxxxxxxxx, Shaheen.Nasirudheen@xxxxxxxx
Subject: Re: PKI International Consortium
it isn't necessarily just authentication that a relying party may have
to worry about with regard to the operation that they might be
trusting the certificate for .... but also things like
authorization. the concept of a certificate is that the relying party
can trust the certificate in an offline environment w/o necessarily
any recourse to any additional information.
the issue of recourse to additional information may because of things
like
1) privacy .... the early x.509 "identity" certificates were found to
represent signficiant privacy compromise, especially when broadcasting
all over the place. as a result, there was retrenchement to
relying-party-only certificates .... where it was sufficient to
authenticate the entity as being authorized to perform some set of
operations against some account record.
2) value ... the transaction is of sufficient value and/or complexity
that it is worthwhile to perform a online transaction (as opposed to
an offline operation purely relying on the contents of a certificate).
Note, however, that majority of relying-party-only certificates were
used in operations involving some value and therefor justified an
online operation with access to timely and/or aggregated information
(aka sufficient funds to actually cover a financial transaction).
3) authorization ... the issue may not have anything at all to do with
your identity, but whether or not you can be authenticated (not
identified) as being an authorized employee or an authorized
individual to perform transactions against a specific bank
account. Just because I can prove I'm John Smith ... isn't sufficient
to establish that I'm an authorized employee of any specific
corporation and therefor entitled to enter an employee only area.
It isn't context-sensitive identity infrastructure ... they require
context-sensitive authorization (although sometimes there is
significant confusion and institutions build identity infrastructures
that are totally orthogonal to their need for authenticationa and
authorization infrastructures).
In many of these situations, then stale, static certificates can be
totally redundant and superfluous ... either because they are
providing information that has no direct bearing on the operation
being performed by the relying party and/or because the relying party
will be doing an online operation with the authoritative agency
providing real-time and/or aggregated information (not possible with a
stale, static, offline certificate).
arshad noor on 4/2/2004 2:39 pm wrote:
I would concur with you, Steve, that a single certificate that serves all
purposes, is neither practical nor desirable. (Although I must confess
to occassionally dreaming of such a utopian environment, sometimes).
However, I believe, it is reasonable - assuming appropriate policy,
process, implementation and most importantly, cooperation - to have
industry-specific identities that may serve us all better.
("Identity Firewalls" -
http://www.xxxxxxxxxx/newsletters/2003Jan17.html
).
Companies waste far too much time and money today, building duplicate
identity infrastructures - and consequently tying their own hands with
context-sensitive identities - because it appears to be the path of
least resistance to them. But as the cost of identity theft & of
managing those numerous identity infrastructures surpasses the
perceived savings from using this path of least resistance, companies
will be forced to rethink that strategy.
Arshad Noor
StrongAuth, Inc.
PKI International Consortium
Refed: **, - **, - **
From: Lynn Wheeler
Date: 04/02/2004 05:11 PM
To: Shaheen.Nasirudheen@xxxxxxxx
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
Arshad Noor <arshad.noor@xxxxxxxxxx>,
PKIX list <ietf-pkix@xxxxxxxxx>, Stephen Kent <kent@xxxxxxxxxx>
Subject: Re: PKI International Consortium
The arpanet was a traditional, homogeneous network ... that happen to
be a packet-switch implementation rather than circuit-switch
implementation. Note however, it was NOT an internet. It corresponded
much closer to the standard OSI model of homogeneous infrastructure
(but having a packet orientation rather than a circuit orientation).
I've claimed that one of the reasons that the internal network was
larger than the arpaent for all of that period ... was that the
internal network had effectively the equivalent of a gateway built
into every node ... allowing support for heterogenous networking. The
great switch-over from arpanet to internet occured on 1/1/83 ... with
the introduction of internetworking .... a "layer" that doesn't even
exist in the OSI model (sitting somewhere between layer3/networking
and layer4/transport). At that time of the switchover the arpanet was
around 250 nodes and the internal network was nearly 1000 nodes. The
combination of internetworking, heterogeneous networking support,
gateways, and the appearance of PCs and workstations as internet
network nodes resulted in the internet eventually exceeding the number
of nodes on the internal network sometime around mid-85.
misc. past posts related to arpanet, csnet, nsfnet, internet, internet
switch-over and the internal network:
http://www.garlic.com/~lynn/internet.htm
a story not related in the above was some corporate type doing
technology audit in the late 70s and being told about the size of the
internal network. the person supposedly wrote a report stating that it
was impossible ... because to build a network of that size using
traditional homogeneous networking technology (common at the time)
would have required more people total than had been working for the
corporation over the previous ten years.
misc. past posts related to OSI, arpanet, iso, etc:
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
the above mentions another issue w/OSI. attempting to get HSP
(high-speed protocol) work item in X3S3.3 (iso chartered us standards
organization responsible for networking and transport layer
standards). The problem was that ISO had a rule that there couldn't be
standards work on protocols in this area that violated OSI. HSP was
going to go directly from level4/transport to the MAC interface. This
violated OSI in two respects 1) it bypassed the level3/level4
interface and 2) it interfaced to MAC layer. LANs/WANs/MAC are a
violation of OSI with the MAC layer sitting somewhere in the middle of
layer3/networking. Because of the OSI violation rule, X3S3.3 rejected
the work item.
in late '69, i did get involved in a project as an undergraduate
building a telecommunication controller using an Interdata/3. this
resulted in later getting blamed for helping create the
plug-compatible manufacturing (PCM) controller business:
http://www.garlic.com/~lynn/subtopic.html#360pcm
shaheen nasirudheen on 4/2/2004 3:37 pm wrote:
Hello everyone,
Quote from bbn.com : "In 1968, the Advanced Research Projects Agency (ARPA)
sent out a Request for Quotation (RFQ) to build a network of four Interface
Message Processors (IMPs). Many of the large computer and
telecommunications organizations didn't even respond--they thought it was
impossible. " -
http://web.archive.org/web/20020603123655/http://www.bbn.com/arpanet/index.html
If the pioneers believed that "Internet" is impossible, then I dont think
we would enjoy sending these emails today.
PKI International Consortium
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/03/2004 08:21 AM
To: Arshad Noor <arshad.noor@xxxxxxxxxx>
cc: PKIX list <ietf-pkix@xxxxxxxxx>, owner-ietf-pkix@xxxxxxxxxx
Subject: Re: PKI International Consortium
An example with slight variation on this was some EU directive that
electronic payments at point-of-sale should be as anonymous as cash,
aka it should be possible to authenticate a transaction for
authorization w/o requiring any identification what-so-ever.
The issue is that if you have some sort of authentication, aka
something you have, something you know, something you are
.... and possibly non-shared-secret based ... it is possible to have
an authorization context that just does authentication and no
identification is involved.
it that case, if there is an authorization context ... with some
recorded authentication mechanism ... then the authentication is bound
to the authorization context and there is no identification at all.
in such a taxonomy .... a certificate represents a stale, static,
authorization context for offline environments ... where the public
key is the authentication mechanism bound to the authorization
context. The authentication mechanism is some form of something you
have .... based on uniquely having a private key that generates a
digital signature that can authenticated with the public key. This is
basically the scenario for the relying-party-only certificates from
the mid-90s (somewhat resulting from retrenching from the horrible
privacy issues of full blown x.509 identity certificates). Note,
however, it isn't the certificate that creates the something you
have associated with the private key, the certificate provides the
portable, stale, static authorization context for offline
environments. It is equally possible to have an online environment
where the public key is bound to an online authorization mechanism and
no certificates are involved at all. The online payment point-of-sale
transactions with relying-party-only certificates exemplified
redundant and superfluous. The transaction was valuable enough that
timely and aggregated online information was deemed justified (the
benefit of having an online, timely transaction more than offset the
incremental cost of having an online transaction) .... but a
relying-party-only certificate was provided such that there could be
an offline authorization context .... but that was then made redundant
and superfluous by having the transaction executed online with an
online authorization context.
The example I've used for identity is the problems with issuing SSL
server domain certificates. The authoritative agency for domain
names is the domain name infrastructure. The typical process for
obtaining an SSL server domain certificate is to provide very strong
identification information to the SSL certificate issuer. The issue is
that the domain name infrastructure has some identification
information registered for the owner of the domain name. The challenge
for the SSL certificate issuer is to be able to perform some level of
identification matching from what is provided by the certificate
applicant with the identification that is on file for the domain name
owner. The reason for the identification operation is that there is no
industry-specific authentication. This (lack and resorting to
identification) turns out to be expensive and somewhat error prone.
A suggestion (somewhat from the certificate industry) is that a public
key is registered with the domain name infrastructure when the domain
name is registered. Then when somebody applies for a certificate, they
digitally sign the operation. The certificate issuer then just needs
an online authentication of the digital signature with what is on file
with the domain name infrastructure and a very expensive and
error-prone identification process is turned into a much simpler and
less expensive industry-specific authentication operation. There is an
implied authorization that the owner of the domain name is allowed to
obtain an SSL domain certificate for that domain name.
Of course, there is possibly a slight catch-22 for the SSL certificate
industry ... that if the certificate industry can make use of online
public keys from the domain name infrastructure .... that possibly the
rest of the world could also ... leading to possibly eliminating the
need for SSL domain name certificates with stale, static
certificates binding public keys to domain names.
arshad noor on 4/2/2004 8:49 pm wrote:
I am in complete agreement with you, Lynn. An industry-specifc
identity should be designed to perform only a single function -
authenticate the holder of the credential. Authorization must
ALWAYS be determined by the context that has successfully
authenticated the entity - and those authorization rules must
always be owned and controlled by the context owner.
PKI International Consortium
Refed: **, - **, - **, - **, - **
From: lynn.wheeeler@xxxxxxxx
Date: 04/04/2004 09:01 AM
To: amg@xxxxxxxx
cc: amg@xxxxxxxx, PKIX list <ietf-pkix@xxxxxxxxx>,
owner-ietf-pkix@xxxxxxxxxx
Subject: Re: PKI International Consortium
The use of relying-party-only certificates were done in large part
because of privacy issues ... which could be
• personal privacy issues with identity information
• personal privacy issues with personal attributes
• institutional sensitivity/privacy issues with institutional attributes
However, for a relying party that used an index/account number from a
relying-party-only certificate to index an entity entry in a
repository or access an online service, it can be shown that the
stale, static replying-party-only certificate is redundant
and superfluous. The issue is that the relying party is retrieving
attributes and/or authorization from the online service and/or an
entity entry from their own respository ... and, in effect, a public
key bound to an entity is then just another personal attribute. A
public key personal attribute is safely stored in an entity's entry in
a repository just like any other personal attribute, no matter how
many PKI infrastructures may wish to infuse public keys with mystical
properties (alhtough public key can be a non-shared-secret where so
many other attributes take on shared-secret properties).
One scenario is FAST project that was being done by FSTC
http://www.fstc.org/
this basically attempted to leverage the 8583 real-time
infrastructures to provide real-time yes/no answers about things other
than authorizing financial transaction.
For instance, rather than having an attribute certificate with
date-of-birth (which currently represents a identity theft
vulnerability) to establish whether a person is younger/older than 18
.... an entity would sign a age level question, much in the same way
they might sign a x9.59 financial transaction. This is then sent off
to the financial institution, which decodes it and replies yes/no to
the relying party. The FI maintains a repository entry for the entity
... including things like timely, sensitive and/or aggregated
information. The FI can answer questions about younger/older than 18
(w/o having to reveal date-of-birth) or answer yes/no to a financial
transaction w/o having to reveal credit limit or current balance.
The current issue is that things like identity theft vulnerabilities
aren't limited to just identity, but can include other personal
attributes as well; in fact could include any attribute that might
potentially be used as part of a shared-secret paradigm. Also
sensitivity of attributes may not be just be limited to personal
attributes, but may also include institutional sensitivity regarding
institutional attributes.
amg wrote:
Hi,
> If a relying party needs to know that I possess certain
> attributes, and if I can present an "Attribute Certificate" that
> convinces them that I do indeed possess those attributes, then what
> purpose is served by also having me present an "Identity Certificate"?
You are completely right, Eric. There are many situations that require
the knowledge of certain attributes but do not require knowledge of
identity. For instance, accesing the Playboy should require knowledge
of the user being over 18, but no identity information should be
revealed.
PKI International Consortium
From: Lynn Wheeler
Date: 04/04/2004 08:28 PM
To: "todd glassey" <todd.glassey@xxxxxxxx>
cc: "Arshad Noor" <arshad.noor@xxxxxxxxxx>, "PKIX list" <ietf-pkix@xxxxxxxxx>, owner-ietf-pkix@xxxxxxxxxx
Subject: Re: PKI International Consortium
the EU directive just said something about being as anonymous as cash
.... in general the privacy mandates signficantly reduce the run of
the mill phishing .... it is somewhat like cryptography .... some
cryptography is secure for all but the most determined government
operations.
it is possible to make account number electronic financial
transactions like x9.59
http://www.garlic.com/~lynn/x959.html#x959
.... authenticated but not identified.
In that sense they become pretty agnostic with respect to
identification. Governments are able to mandate "know your customer"
rules for the accounts ... which given the appropriate government
action can extract all sorts of details. However, it doesn't preclude
other governments allowing purely anonymous accounts.
todd glassey wrote:
Lynn - good commentary - but I also want to add that cash transactions are
not anonymous in that they leave finger prints and they survived this
"reduction in their anonymity" after the adoption of fingerprinting by law
enforcement... i.e. Someone handles the money and there is all kind of
tangible evidence left, the issue is the cost of collecting and maintaining
it.
Todd
Identity (was PKI International Consortium)
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/04/2004 08:57 PM
To: Eric Norman <ejnorman@xxxxxxxx>
cc: PKIX list <ietf-pkix@xxxxxxxxx>, owner-ietf-pkix@xxxxxxxxxx
Subject: Re: Identity (was PKI International Consortium)
I've lately been busy working on X9.99 financial industry financial
standard for privacy, learning more than i want to do about EU-DPD,
GLB and HiPPA, etc. Somewhat to complement the merged security
taxonomy & glossary work:
http://www.garlic.com/~lynn/index.html#glosnote
I've started a merged privacy taxonomy & glossary ... pulling from EU
data privacy directive, GLB, HiPPA, OMB, FTC and a couple others.
My earlier statement was that there was significant retrenchment from
the X.509 Identity certificates of the early '90s because of the
serious privacy issues that the information represented. The issue
wasn't so much what features in X.509 Identity certificates were
related to identity ... but what features in X.509 identity
certificates that raised serious privacy issues. EU-DPD, HiPPA, and
GLB have issues about PHI (protected health information) and PII
(personally identifiable information) and sensitive perosnally
identifiable information.
From their standpoint, it isn't so much identity information per se
... it is any kind of personal information that adversely affect a
person's quality of living (like fraud, phishing, identity theft,
etc).
In the past i've defined a taxonomy for authentication information and
certificates. In effect, there is some entity information that is
registered someplace ... likely at a certificate issuer ... but
possibly someplace else. The certificate issuer packages up a R/O copy
of that information and creates a static certificate containing that
information and distributes it (or at least returns the r/o copy of
the information, i.e. the certificate to the entity requesting the
certificate). The certificate by its very nature is static ... the
digital signature of the certificate issuer goes to a great deal of
trouble to establish it as static (and if it ever does change ... the
certificate becomes invalid).
The certificate is, in a way, a high-integrity, static, r/o cached
copy of some information stored some place else. This allows it to be
used in an offline process when the relying-party doesn't otherwise
have recourse to the original information.
In that sense, it is directly analogous to CPU r/o cached entries, or
filesystem r/o cached records, or database r/o cached entriess.
Once the cached copy (certificate) is distributed, it by definition is
stale ... representing the state of some record at some time in the
past. The information contained in the cached certificate/copy may or
may not be stale, but by definition the certificate itself is stale.
So therefor, I assert that it is perfectly reasonable to refer to
certificates as static and stale (regardless of whether or not the
information contained within the certificate has yet become stale).
One point in using the characteristics static and stale to describe
the certificate paradigm .... is to highlight that certificates are in
effect, r/o cached entries of some other information. It makes a
distinction between the information that might be contained in a
certificate from the certificate paradigm itself. There has been a lot
of work on the basic nature of cached information ... which i believe
is applicable to the certificate paradigm. That work is totally
orthogonal to the nature of the information itself (that might be
contained in a certificate).
ejnorman wrote:
Well, my opinion is that you won't have much luck dealing with
"Identity issues" until you have a good definition of "identity".
Here's my shot at it. If you start from the premise that identity is
just a set of attributes, then your identity is those attributes that
are constant and last forever.
So, my "Identity certificate" asserts an association between me and
the University of Wisconsin. Is that part of my identity? It depends
on how you interpret that assertion. If you interpret it as "was at
one time affiliated with that university", then that lasts forever and
it is (Winston Smith to the contrary). If you interpret it as "is
currently affiliated...", then it isn't.
The only observation I can make right now is that with the former
interpretation, Lynn Wheeler doesn't get to use the adjectives "stale"
and "static". Whether that's any more useful than counting angels
dancing on pinheads remains to be seen, I suppose.
secret hackers to aid war on internet fraud
From: Lynn Wheeler
Date: 04/05/2004 08:35 AM
To: internet-payments@xxxxxxxxxx
Subject: secret hackers to aid war on internet fraud
note somewhat related to below:
http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk
http://www.timesonline.co.uk/article/0,,5-1063208,00.html
April 05, 2004
By Joe Morgan
FEARS that small online retailers are the weakest link in the fight
against internet fraud have prompted MasterCard, the global payment
scheme group, to set up secret teams of hackers to test security
systems in the sector.
...snip...
PKI International Consortium
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/06/2004 09:53 AM
To: Arshad Noor <arshad.noor@xxxxxxxxxx>
cc: PKIX list <ietf-pkix@xxxxxxxxx>, Stephen Kent <kent@xxxxxxxxxx>,
owner-ietf-pkix@xxxxxxxxxx
Subject: Re: PKI International Consortium
we were called in by one of the industry groups to do some work on the cal.
e-sign legistlation ... and then later on the federal bill. their interest
was focused on some of the implications between e-sign and privacy. one of
the things that they had studied was the driving factors behind privacy
legislation ... which they claimed to be 1) identity theft and 2) denial of
(institutional) service. Note that since then, there are issues with
exposure of email addresses ... for instance look at the postings in the
PKIX archive:
http://www.imc.org/ietf-pkix/mail-archive/maillist.html
the issue with institutions in the mid-90s retrenching from the early
x.509 identity certificates to relying-party-only certificates
(basically a public key and an account number ... or other database
index ... where the actual information might be located) .... wasn't
directly an identity theft issue .... it was the significant privacy
issues. Some of the privacy issues are related to identity theft
... but it isn't solely an identity theft issue.
the various privacy legislative and regulatory aspects are related to
exposing personal identifiable information ... how and where that
information might be exposed ... regardless of whether or not that
information might be contained in a certificate or any other
form. some of the exposure issues may be related to identity theft.
GLB has a bunch of stuff about sharing of information within an
institutions and/or affiliated third parties. One could imagine a
document (certificate or otherwise) ... where it would be perfectly ok
to transmit and/or exchange between the individual and the primary
institution ... but there would be a requirement that no other entity
be allowed to see it. If some types of that information happened to be
contained in a certificate ... then how that certificate was used, how
it was transmitted, and who was allowed to see it might be subject to
various privacy legislation and/or privacy regulations.
i just saw a reference this morning about somebody raising the issue
that the proposed google email service may be in violation of various
privacy legislation and/or regulations.
In hypothetical scenario an entity digitally signs a perfectly
acceptable transaction. In a certificate-based authentication
paradigm, the certificate could contain personably identifiable
information that has absolutely nothing at all to do with the subject
transaction. There could be one or more relying-parties that had
interest in authenticating the digital signature. Under various
legislative and/or regulatory constraints it might be possible that
some relying-parties would not be permitted access to the certificate
because of privacy constraints. Such privacy constraints might also
impose restrictions on how the certificate was transmitted and/or
handled.
arshad noor wrote:
I do not believe identity theft will ever be eradicated
regardless of the number of certs. However, if we assume
that identity certs are useful, then there is some optimal
number that balances the risk against the inconvenience of
carrying too many credentials. In the absence of objective
research recommending the precise number, or range, the
identity firewalls concept advances one figure.
Privacy, personally identifiable information, identity theft
From: Lynn Wheeler
Date: 4/08/2004 02:51 PM
To: PKIX list <ietf-pkix@xxxxxxxx>
Subject: Privacy, personally identifiable information, identity theft
minor references to eu data privacy directive related to those email
issues:
http://www.dmeurope.com/default.asp?ArticleID=1417
http://www.dmnews.com/cgi-bin/artprevbot.cgi?article_id=27045
lynn.wheeler wrote:
we were called in by one of the industry groups to do some work on the
cal. e-sign legistlation ... and then later on the federal
bill. their interest was focused on some of the implications between
e-sign and privacy. one of the things that they had studied was the
driving factors behind privacy legislation ... which they claimed to
be 1) identity theft and 2) denial of (institutional) service. Note
that since then, there are issues with exposure of email addresses
... for instance look at the postings in the PKIX archive:
http://www.imc.org/ietf-pkix/mail-archive/maillist.html
Single Identity. Was: PKI International Consortium
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date:04/09/2004 08:03 PM
To: Shaheen.Nasirudheen@xxxxxxxx
cc: "Al Arsenault" <aarsenau@xxxxxxxx>, amg@xxxxxxxx,
"Anders Rundgren" <anders.rundgren@xxxxxxxx>,
"Arshad Noor" <arshad.noor@xxxxxxxx>,
"Terwilliger, Ann" <aterwil@xxxxxxxx>,
"Eric Norman" <ejnorman@xxxxxxxx>,
"PKIX list" <ietf-pkix@xxxxxxxx>, "Stephen Kent" <kent@xxxxxxxx>
Subject: Re: Single Identity. Was: PKI International Consortium
note that the financial examples aren't really identification ... they
really are authentication ... and that actually helps make it work. it
is somewhat a fabrication to call it identification.
if my financial authentication device is lost/stolen/breaks/fails/etc,
i can call up and AUTHENICATE myself as the owner of the account and
get a new one. The various questions are all effectively some form of
shared-secret ... that they hope the person on the street can
remember. They ask things like transactions on previous statements
... but they also ask address, social security number, and
mothers-maiden-name. For mothers-maiden-name ... they've never
actually ID you ... they've effectively asked for a
shared-secret that they hope you can remember/answer. Because of some
issue about mothers-maiden-name might not be the best of secrets ... I
know people that make up values to fill in that field .... you just
have to make sure you remember it, when the mothers-maiden-name tag
shows up ... you remember what secret you actually filled in. The use
of SSN is something of a schizophrenic problem ... it is dual-use both
as a (mandatory) identification (by gov. requirements) and as a
shared-secret (something you can answer for authentication). The
problem with the mandatory identification aspect of SSN is that it
becomes propagated to a large number of places, compromizing its use as
a shared-secret authentication mechanism.
the authentication taxonomy is
• something you have
• something you know
• something you are
shared-secrets are part of something you know; hardware tokens are
example of something you have. Digital signatures for authentication
purposes tend to be of the something you have nature ... i.e. in
theory you and only you have a copy of your private key. Note in this
context ... whether or not certificates are part of the paradigm is
orthogonal to the authentication taxonomy.
Financial cards have also been of the something you have
paradigm. In the past, there has been great deal of effort in making
them hard to counterfeit these cards .... majority of it based on
assuming that the criminal generates the counterfeit cards completely
from scratch. The current problem is one of skimming where all the
information to make a duplicate card is copied (as opposed to having
to start from scratch creating a counterfeit card).
something you have authentication paradigm breaks down when the
object is no longer unique. this can happen with private keys if
wherever one is stored becomes compromized. It has also happened in the
case of the EMV counterfeit yes cards .... i.e. effectively the same
technology for skimming to make duplicate (counterfeit) magstripe
cards is also used to make duplicate (counterfeit) EMV cards.
the issue regarding the contents or nature of a certificate is totally
orthogonal to the use of public/private key system as a something you
have authentication mechanism. The advantages that the digital
signature mechanism has over existing shared-secret paradigms ... 1)
resilent to insider attacks that copy the master secret database
(there is no shared-secret that they can get that allows them to
impersonate you), 2) phishing attacks are slightly more complicated
since you don't actually "remember" your private key (i.e. something
you have rather than something you know )
The downside of private keys in a file on your PC ... is that it is
relatively suseptable to phishing and virus attacks ... if they can
get you to click on something and give up your logon password ... they
can get you to click on something and give up the (private key) file
encryption key (transmitting the file at the same time).
Placing the private key in a hardware token, where effectively nobody
can get it (or duplicate the private key) .... then requires change in
tactics. They have to convince you to (physically) mail off the
hardware token along with any PIN ... or get you to use the hardware
token in transactions on their behalf.
Again ... nothing in the uses of private key and/or hardware tokens
for authentication is directly related to certificates. The
certificates paradigm is part of a structure for validating the
results of the authentication .... but is not part of the generation
of the authentication or the authentication taxonomy.
shaheen nasirudheen wrote:
Hello everyone.
Though new to this group, within a short span I understand there are people
who favor single identity and who does not. I also understand that there is
an effort towards standardizing or centralizing PKI among the Financial
Institutions. One such effort is Identrus. Thanks to some of the members of
this group who helped me with good information. However, moving forward,
can I look forward for a single identity that I can use to identify myself
to any public system that require identification and authentication? If
there is an ongoing effort in this regard, please let me know so that I can
participate.
Regards,
Shaheen Nasirudheen
privacy, authentication, identification, authorization
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/10/2004 05:34 PM
To: "PKIX list" <ietf-pkix@xxxxxxxx>
Subject: privacy, authentication, identification, authorization
basically somebody provides some authentication information, in
public/private key scenario ... a digital signature is generated by a
private key as part of a something you have authentication paradigm.
there could be some certification process where a hardware token is
involved (certifies the operation of specific hardware token analogous
to FIPS or common criteria, not as in a public key certificate issuing
institition), the hardware token is certified as generating (on-chip)
a key pair where the private key never leaves the chip. the hardware
token could also be certified as generating specific kinds of digital
signature when correct PIN or biometric is presented. with such a
certificate infrastructure .... the relying party might then have
grounds to believe that in addition to something you have, there may
bave been something you know and/or something you are
authentication. This wouldn't be a shared-secret based operation
.... but the relying-party could infer something you know and/or
something you are if it trusted the certification process for the
hardware token operation.
the relying-party then obtains a public-key and validates the digital
signature. the infrastructure for the public-key could be a database
(conforming to most existing business processes for authentication
material) or a certificate (in the PKI model).
the infrastructure typically has bound the public-key to some
identification, index, and/or authorization information. In the case
of identification or index, that information is frequently then used
to lookup some authorization information (i.e. specific identity is
allowed to do specific stuff). A trivial example is a generic employee
certificate ... all it contains is some generic employer information
and the public key, if the digital signature authenticates ... then it
is known that the person is some employee and is entitled to do
whatever generic employees are entitled to do.
the issue here is that there aren't a lot of business processes that
perform identification (or authentication) just for the sake of it
(having absolutely no other purpose) .... the business process is
performing the operation as part of some additional activity. For
instance, there aren't a lot of identification stores in malls, where
you walk in authenticate/identify ... and then walk out (with no other
operation occuring).
The early x.509 identity certificates tended to contain a lot of
arbitrary information that ran afoul of various pricacy issues. The
result was retrenching to relying-party-only certificates that contain
an indication or domain-specific index ... which was then used to
index a database entry that then provided the actual information
needed for executing a business process.
Putting in generic identity information or possibly institutional
specific identity and/or authorization information (like clearance
levels) in a public certificate (targeted for uncontrolled
distribution) tends to violate various privacy and/or institutional
rules/policies.
just because some item of information is encapsulated in a public
certificate doesn't magically mitigate all rules and policies
regarding the handling of that information
Re:Identity Firewall. l PKI International Consortium
Refed: **, - **, - **
From: Lynn Wheeler
Date: 04/11/2004 08:02 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: "Arshad Noor" <arshad.noor@xxxxxxxxx>,
"PKIX list" <ietf-pkix@xxxxxxxxx>,
"Stephen Kent" <kent@xxxxxxxx>
Subject: Re:Identity Firewall. l PKI International Consortium
i was at a presentation of a vendor SAML product about a year ago that
was being deployed in a number of institutions. the CTO was presenting
all the message flows. I made some comment that the message flows
looked nearly the same as a Kerberos presentation i had sat thru circa
1990. The response was that there was just only so many ways that
distributed security control could be implemented.
anders rundgre wrote:
What Steve did not mention, is that the authentication and
authorization schemes that are firmly in place since three
decades or so for bank-to-bank and supplier-to-manufacturer
networks, together with recent developmemts like SAML and
3D Secure, will likely forever change how PKI is applied, which
also will affect schemes like the Identity Firewall.
Probably PKI deployment will follow two main directions,
relying-party-only and general purpose TTPs. Which one
will be dominating depends IMHO not on technical
issues but on business models and costs. There are to my
knowledge practically no limitations to what you can do
with an identity credential using indirect auth* schemes.
Indirect auth* schemes BTW offer huge cost, control, and
scalability advantages over the schemes currently being
deployed by many public sector PKI programs.
Definitions of "Security"?
Date: Wed, 14 Apr 2004 09:34:58 -0600
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: hadmut@xxxxxxxx
Subject: Re: Definitions of "Security"?
Cc: cryptography@xxxxxxxxxxxx
At 08:01 AM 4/14/2004, hadmut wrote:
Hi,
I'm looking for interesting and unusal defitions of the
term "Security" (or "secure")
there was a discussion on PAIN taxonomy for security earlier in the
year ... misc. references
http://www.garlic.com/~lynn/aadsm16.htm#11 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
http://www.garlic.com/~lynn/aadsm16.htm#14 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
http://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic)
eCompute ECC2-109 Project has PROBABLE solution
From: Anne & Lynn Wheeler <lynn@xxxxxxxxxx>
Date: Thu, 08 Apr 2004 23:24:40 -0600
Subject: eCompute ECC2-109 Project has PROBABLE solution
To: cryptography@xxxxxxxxxx
http://web.archive.org/web/20030207160039/http://www.ecompute.org/ecc2/
There has been a PROBABLE solution generated as of 1425 hrs GMT, April
8, 2004.
Until Certicom has confirmed this, it will be treated as a PROBABLE
solution and the DP collection will continue.
The two people who have submitted the DP values have been emailed.
Until Certicom formally accepts this, please do not stop your clients.
Remember, this is only a PROBABLE solution and we do not done yet!
The ECC2-109 Team
eCompute ECC2-109 Project has PROBABLE solution (now official)
From: Anne & Lynn Wheeler <lynn@xxxxxxxxx>
Date: Fri, 16 Apr 2004 10:15:20 -0600
Subject: Re: eCompute ECC2-109 Project has PROBABLE solution (now official)
To: cryptography@xxxxxxxxxx
At 11:24 PM 4/8/2004, Anne & Lynn Wheeler wrote:
http://web.archive.org/web/20030207160039/http://www.ecompute.org/ecc2/
it is now official
eCompute ECC2-109 Project
We have received unofficial OFFICIAL word that the solution is valid!
As a result, the DP server has been closed and we’re working on
finalizing the final stats. No further DP values will be accepted and
the DP server will remain closed.
A little later today we’ll be posting complete information regarding
the solution, some project stats, and other final information. Until
then
We wish to thank everyone who has contributed to this project. With
your help, it was a success. Without your help, it never could have
happened!
The solution was achieved through a collision of points provided by:
glenon from Ars Technica Team Vodka Martini
Maximum_Confusion from TechIMO
The following was written by Chris Monico to describe the solution
achieved.
... snip ..
Payment system and security conference
Refed: **, - **, - **
From: Lynn Wheeler
Date: 04/18/2004 11:07 AM
To: internet-payments@xxxxxxxx
Subject: Payment system and security conference
reminder from this month's enhyper newsletter, 2004 payment system and security conference
http://www.enhyper.com/paysec/
also mention financial cryptography blog ... by some of the same people
http://www.financialcryptography.com/
they also have short blurb on:
http://www.bitpass.com/
enhyper also discovered norm hardy and some of his papers: ... the digital silk road
http://www.cap-lore.com/Economics/DSR/
http://www.agorics.com/Library/dsr.html
norm's past include LLNL, 360s, vm/370, secure operating systems and secure transactions:
http://cap-lore.com/
and secure operating systems at tymshare with gnosis and keykos:
http://www.agorics.com/Library/keykosindex.html
http://web.archive.org/web/20020204180320/http://www.cis.upenn.edu/~KeyKOS/
.... and there is EROS -- extremely reliable operation system
(outgrowth of keykos)
http://www.cis.upenn.edu/~eros/
... note above mentions looking at getting an EAL7+ evaluation for eros.
when MD bought tymshare they were looking at spinning off a number of
things. i was brought in to do a technical audit of gnosis as part of
its spin-off as keykos. they were also spinning off Doug Engelbart who
was working at Tymshare at the time ... tymshare was running doug's
"augment" system on pdp10 ...
http://www.superkids.com/aweb/pages/features/mouse/mouse.html
http://sloan.stanford.edu/MouseSite/dce-bio.htm
http://www.invisiblerevolution.net/engelbart/glossary/augment_nls.html
http://www.sciencedaily.com/encyclopedia/nls
and total topic drift, i've got lots of references to vm/370:
http://www.garlic.com/~lynn/subtopic.html#545tech
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
visa cards violated, BofA reissuing after hack attack
Refed: **, - **, - **
From: Lynn Wheeler
Date: 04/19/2004 11:49 AM
To: internet-payments@xxxxxxxxx
Subject: visa cards violated, BofA reissuing after hack attack
http://business.bostonherald.com/technologyNews/view.bg?articleid=439
Visa cards violated: BofA is reissuing after hack attack
By Jay Fitzgerald
Friday, April 16, 2004
Holders of Fleet Visa business credit cards may be the latest victims
of hackers who possibly got hold of sensitive card numbers via a
merchant's computer system, officials acknowledged yesterday.
Fleet Credit Card Services, now part of Bank of America [BAC: chart,
news] Corp. after this month's takeover of FleetBoston Financial
Corp. [FBF: chart, news] , is sending new cards to an unspecified
number of customers because of a security breach at an unnamed
merchant.
.... snip ....
old posting on security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61
misc from IETF
From: Lynn Wheeler
Date: 04/30/2004 10:59 AM
To: internet-payments@xxxxxxxx
Subject: misc from IETF
recent moved from draft to RFC & BCP (cross-posted in sci.crypt ng):
RFC 3766 Determining Strengths For Public Keys Used For Exchanging
Symmetric Keys
for announcement & ref see:
http://www.garlic.com/~lynn/2004e.html#18
also, the following note from the ietf trade working group on
electronic commerce markup language (ECML):
Just to update you on what is happening, since the Last Call on them
is over and there were no negative comments, I have requested on
behalf of the working group, that
draft-ietf-trade-voucher-lang-06.txt and
draft-ietf-trade-voucher-vtsapi-06.txt
be published as Informational RFCs and I have submitted a new version
of the ECMLv2 draft:
draft-ietf-trade-ecml2-spec-09.txt
Donald
The future of security
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sat, 08 May 2004 15:36:16 -0600
Subject: Re: The future of security
To: Ian Grigg <iang@xxxxxxxx>
Cc: cryptography@xxxxxxxx
On Thu, 2004-05-06 at 17:52, Ian Grigg wrote:
c. much less emphasis on deductive no-risk
systems (PKIs like x.509 with SSL) due to the
poor security and market results of the CA
model.
at the nist pki r&d workship (mentioned elsewhere in some other post
in this mailing list) there was discussion of
1) using private key signing for things like signature (like in human
signature) agreement/authorization as opposed to straight
authentication. one of the issues is that if you ever use a private key
to digitally some random challenge/response data in a authentication
paradigm ... you might be at risk ever using the same private key for
signature purposes ... since it might be possible that some of the
random data you may have signed might not have been truely random after
all
2) naked public keys ... aka w/o certificates at all
3) and in some of the breaks the certificate use in payment
transactions. sort of two issues in payment transactions were/are a)
privacy and b) size bloat. in the mid-90s, the traditional x.509
identity certificate from the early 90s was drastically cut back to
relying-party-only, "account number" certificate because of privacy
issues with identity information. The work on certificate-based
financial transaction started with taking a 60-80 byte payment
transaction, instead of ISO8583, using ASN.1 encoding to blow it up to
200-300 bytes; added a 128-byte RSA signature (then adding in the ASN.1
encoding) and a relying-party-only certificate that typically ran 4k-12k
bytes; having starting from a 60byte normal transaction, the
certificate-based stuff would blow it up by factor of one hundred times
to 6k to 12k bytes. The certificate was totally redundant and
superfluous since the financial institution was the relying party and
already had all the information. In the X9.59 work it was observed that
it was possible to encode an ECDSA signature in an ISO8583 transaction
in 42 bytes ... so absolute minimum for authenticated payment
transaction would go from 60 bytes to a little over 100 bytes ... w/o
throwing in a bunch of extraneous, duplicated and/or superfluous data
that provided absolutely no added value (the payment transaction still
contained the same data, digital signature authentication was added ...
and all the payload carried in a certificate was totally redundant and
superfluous since the relying-party had a superset). It isn't exactly
that payment security requirements have to be proportional to the cost
of certificate security ... it was that certificate security increased
the payload costs by a factor of one hundred times and provided NO added
value.
some of my further observations about mixing authentication signing and
signature signing ... as well as nature of naked public keys ...
recently posted to thread in sci.crypt:
http://www.garlic.com/~lynn/2004e.html#20 Soft signatures
and "the future of security" ... somewhat orthogonal to cryptography ...
there was recently a letter from NSF to some former multician that was
posted to the alt.os.multics n.g. that started a thread on (not
necessarily crypto) system security (and multics never having been
broken). a couple posts in the thread
http://www.garlic.com/~lynn/2004e.html#27 NSF itnerest in Multics security
http://www.garlic.com/~lynn/2004e.html#36 NSF itnerest in Multics security
Online credit card fraud rocks Indonesia
From: Lynn Wheeler
Date: 05/07/2004 10:42 PM
To: internet-payments@xxxxxxxx
Subject: Online credit card fraud rocks Indonesia
http://straitstimes.asia1.com.sg/asia/story/0,4386,249296,00%20.html
It is so rampant that popular e-commerce sites are slapping curbs or even outright bans on purchase bids from the country
By Robert Go
JAKARTA - Mr Fektur claims he earns 20 million rupiah (about S$3,900) a month - a sum that firmly puts him in Indonesia's middle class.
... snip ...
Yahoo releases internet standard draft for using DNS as public key server
From: Lynn Wheeler
Date: 05/19/2004 09:26 PM
To: internet-payments@xxxxxxxx
Subject: Yahoo releases internet standard draft for using DNS as public key server
yahoo draft internet standard for using DNS as a public key server
http://web.archive.org/web/20040607200622/http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt
misc past news refs:
http://docs.yahoo.com/docs/pr/release1143.html
http://blogs.ittoolbox.com/linux/technologist/archives/000241.asp
http://web.archive.org/web/20040215184953/http://www.computerweekly.com/Article127082.htm
http://zdnet.com.com/2100-1104_2-5164279.html
http://www.ecommercetimes.com/perl/story/32995.html
a few past threads on using DNS as a public key server
http://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aepay4.htm#comcert2 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert4 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption
http://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki12 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
http://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
http://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
http://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#8 Server authentication
http://www.garlic.com/~lynn/2001c.html#9 Server authentication
http://www.garlic.com/~lynn/2001d.html#36 solicit advice on purchase of digital certificate
http://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
http://www.garlic.com/~lynn/2001e.html#26 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#40 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#2 Root certificates
http://www.garlic.com/~lynn/2001g.html#19 Root certificates
http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
http://www.garlic.com/~lynn/2001n.html#57 Certificate Authentication Issues in IE and Verisign
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
http://www.garlic.com/~lynn/2002p.html#18 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#51 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#53 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new)
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Moving forward with pre-shared keys
From: Lynn Wheeler
Date: 05/20/2004 10:07 AM
To: "Joseph Salowey" <jsalowey@xxxxxxxx>
cc: "'Eric Rescorla'" <ekr@xxxxxxxx>, hzhou@xxxxxxxx, ietf-tls@xxxxxxxx,
"'David A. McGrew'" <mcgrew@xxxxxxxx>,
"'Nancy Cam-Winget'" <ncamwing@xxxxxxxx>
Subject: RE: Moving forward with pre-shared keys
similar ... but different ... is pre-stored keys .... the yahoo draft
that showed up yesterday to use DNS as a public-key server.
minor reference:
http://www.garlic.com/~lynn/aadsm17.htm#36
Study: ID theft usually an inside job
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 05/22/2004 09:16 AM
To: internet-payments@xxxxxxxx
Subject: Study: ID theft usually an inside job
Study: ID theft usually an inside job
http://www.msnbc.msn.com/id/5015565
Up to 70 percent of cases start with employee heist
By Bob Sullivan
Technology correspondent
MSNBC
Updated: 7:03 p.m. ET May 21, 2004
A soon-to-be-released study reveals what some identity theft experts
have hinted at for years -- the crime is largely the work of
insiders. In a study of more then 1,000 identity theft arrests in the
United States, Michigan State professor Judith Collins has discovered
that perhaps as much as 70 percent of all identity theft starts with
theft of personal data from a company by an employee.
... snip ...
this isn't inconsistent with earlier studies claiming that general
fraud tended to be 90 percent insiders.
posting related to internet payments ... and security proportional to
risk
http://www.garlic.com/~lynn/2001h.html#61
part of the issue is the excessive amount of identity &/or static
shared-secret information laying about in authentication
infrastructures .... making the infrastructure vulnerable to identity
theft, or other kinds of impersonation and/or replay attacks.
The future of security
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 26 May 2004 09:51:01 -0600
To: "Steven M. Bellovin" <smb@xxxxxxxx>
Subject: Re: The future of security
Cc: Ian Grigg <iang@xxxxxxxx>,
Graeme Burnett <rgb@xxxxxxxx>, cryptography@xxxxxxxx
At 09:36 AM 5/11/2004, Steven M. Bellovin wrote:
In message <409ACFC7.6050407@xxxxxxxx>, Ian Grigg writes:
>
>Security architects
>will continue to do most of their work with
>little or no crypto.
And rightly so, since most security problems have nothing to do with
the absence of crypto.
>
>j. a cryptographic solution for spam and
>viruses won't be found.
This ties into the same thing: spam is *unwanted* email, but it's not
*unauthorized*. Crypto can help with the latter, but only if you can
define who is in the authorized set of senders. That's not feasible
for most people.
one of the issues has been that many crypto security solutions have
been oriented towards hiding information. that may work with outsiders
... but traditionally, 90percent of fraud has been insiders ... and
recent news last friday about study to be published was that
interviewing something like 1000 people involved in identity theft
cases ... it was determined that at least 70percent had some sort of
employee involvement.
in that sense ... the internet and introduction of the possibility of
outsider related fraud ... has distracted/obfuscating focus from the
real, long standing issues.
my repeated observation that current generation of desktop systems
were originally introduced to operate in a standalone environment
where applications could be introduced that freely took over the whole
machine. attempting to continue to satisfy the standalone ... total
take-over requirements at the same time using the same platform for
generalized interconnect to an increasingly hostile environment
creates some diametrically opposing objectives.
The future of security
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 28 May 2004 10:44:17 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
Cc: astiglic@xxxxxxxx, iang@xxxxxxxx,
smb@xxxxxxxx, cryptography@xxxxxxxx, rgb@xxxxxxxx
Subject: Re: The future of security
At 09:27 AM 5/28/2004, Peter Gutmann wrote:
No they won't. All the ones I've seen are some variant on the "build a big
wall around the Internet and only let the good guys in", which will never work
because the Internet doesn't contain any definable inside and outside, only
800 million Manchurian candidates waiting to activate. For example
MessageLabs recently reported that *two thirds* of all the spam it blocks is
from infected PCs, with much of it coming from ADSL/cable modem IP pools.
Given that these "spammers" are legitimate users, no amount of crypto will
solve the problem. I did a talk on this recently where I claimed that various
protocols designed to enforce this (Designated Mailers Protocol, Reverse Mail
Exchanger, Sender Permitted From, etc etc) will buy at most 6-12 months, and
the only dissent was from an anti-virus researcher who said it'd buy weeks and
not months. The alternative proof-of-resource-consumption is little better,
since it's not the spammers' resources that are being consumed.
the caveat to that is many of the infected machines were originally
infected by spam with spoofed origin ... somehow convincing users to
click on something. authentication would help somewhat with that
... and, in fact, some of the spam being sent out by the infected
machines, in turn uses spoofed origin. authentication might also help
address the identity-theft oriented spam ... claiming to be your bank
and needing personal information.
it doesn't help with ... click on this to get the latest, greatest
game ... where there isn't any attention at all paid to the origin
... just looking for instant gratification.
the 60s/70s time-sharing systems nominally had some assurance applied
to the introduction of executables into the environment. this is my
comment about the desktop systems having diametrically opposing
requirements ... the original design point of totally unconnected,
stand alone environment where an introduced executable could take over
the whole machine ... and at the same time fully wired to an
increasingly hostile environment needing signficant safeguards and
processes associated with assurance of introduced executables. the
intermediate step was that some of these stand-alone machines acquired
interconnect capability for a local, safe, isolated
departmental/office network. This had hardly any restricted execution
and access capability ... again not worrying about protection against
a hostile and unsafe operation.
the shared environment analogy is highway traffic and rules about
operating an unsafe vehicle could result in both having your license
revoked and the vehicle confiscated (it doesn't require the driver to
be a highly trained car mechanic ... it just holds the driver
responsible).
connecting systems that were designed for fundamentally safe and
isolated environment to wide-open anarchy hostile operation exposes
all sorts of problems. somewhat analogous to not actually needing a
helmet for riding a motorcycle ... or seat belts and airbags to drive
a car.
Yahoo releases internet standard draft for using DNS as public key server
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 01 Jun 2004 12:06:00 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
Cc: cryptography@xxxxxxxx, nelson@xxxxxxxx
Subject: Re: Yahoo releases internet standard draft for using DNS as public key server
At 10:14 PM 5/30/2004, Peter Gutmann wrote:
The S/MIME list debated this some time ago, and decided (pretty much
unanimously) against it, for two reasosn. Firstly, because it adds
huge ugly blobs of base64 crap to each message (and before the ECC
fans leap in here, that still adds small ugly blobs of base64 crap to
each message). Secondly, because if you get a message from someone
you know you'll be able to get a pretty good idea of its authenticity
from the content (for example an SSH developer would be unlikely to be
advocating SSL in a list posting), and if you get a message from
someone you don't know then it's pretty much irrelevant whether it's
signed or not. So the consensus was not to sign messages.
this may or may not be my KISS authentication thread.
mid-90s, some number of financial institutions retrenched from x.509
identity certificates to simple relying-party-only certificates
... because of enormous privacy issues regarding blanketing the world
with privacy information contained in identity certificates.
however, they were still looking at taking a 60-80 bytes payment
message, attaching a 128byte digital signature, and then attaching a
4k byte to 12k byte relying-party-only certificate ... and sending it
back to the financial institution that issued the certificate. this is
not counting any ASN.1 encoding that might have been done which then
possiby includes a bunch more bytes. note that standard payment
message message has been around some 30 years carefully crafted as
simple 7bit ascii w/o any addition encoding requirements. the purpose
of the certificate was to carry the account number ... which was also
included in the signed payment message ... and the public key
... which was stored in the account record back at the financial
institution that was receiving the transmission and had originally
issued the relying-party-only certificate.
so the financial institution receives this new payment object,
retrieves the account number from the (signed) payment message and
uses the public key in the account record to verify the signature
... w/o ever resorting to the certificate. So we have a payload bloat
of one hundred times ... in order to carry a certificate that is
redundant and superfluous and never used.
so x9.59 was fairly carefully crafted to add a 42byte ECC signature to
a standard 60-80byte payment message. any special encoding to carry
42byte ecc 8bit in 7bit transmission at worst doubled the signature
payload size.
http://www.garlic.com/~lynn/x959.html#x959
Article on passwords in Wired News
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 06 Jun 2004 13:54:01 -0600
To: Ernst Lippe <ernstl@xxxxxxxx>
Subject: Re: Article on passwords in Wired News
Cc: martin f krafft <madduck@xxxxxxxx>, cryptography@xxxxxxxx
At 02:19 AM 6/5/2004, Ernst Lippe wrote:
What is that card? There are some schemes that use debit cards
with an embedded smartcard. If you are referring to one of these
schemes I don't think that they are more secure than TAN's. If
it is a card that you carry along with you, the risk that it will
be stolen is higher than the risk that some TAN's will be stolen,
because in most cases you are able to store your TAN's in
a safe place in your home. The only apparent advantage of
using a card is the PIN, i.e. something you know, but all
internet banking application that I have seen require some form
of password which has at least the same security as a PIN.
If it really is a debit card, then the security is probably
even worse. In several debit card schemes the PIN for cash
transactions is the same as the PIN for web transactions (
if the users have the possibility to change either PIN, it
is a safe bet that they will be both the same), and it it not
at all difficult to determine the PIN in this case.
there is two factor authentication:
• something you have
• something you know
in this scenario we could conclude there are are a least
3-4 types of something you know authentication.
• re-usable shared-secret, things like run-of-the-mill
account numbers .. where knowing the account number is
sufficient to perform a fraudulent transaction. these are
extremely attractive to criminals ... because merchants
tend to aggregate them in transaction files ... so a single
theft of the transaction file could represent an extremely
huge return-on-investment (benefit/risk trade-off). some past
discussion of this with regard to security proportional
to risk:
http://www.garlic.com/~lynn/2001h.html#61
• shared-secret, one-time account numbers. this is
a fairly adequate countermeasure for the major fraud
scenario ... harvesting merchant account files. there
can still thefts/copying of individual account sheets,
just like there can be thefts of individual cards. note
however that the benefit/risk of individual thefts is
orders of magnitude less than the merchant transaction
file harvesting. as per the above url discussion of
security vis-a-vis risk ... harvesting a merchant account
file of re-usable account numbers may represent a $50m
exposure ... and hundreds of thousands of dollars
expense to a bank to block the affected accounts and
re-issue new cards. one time numbers may represent
little or no countermeasure to the individual vulnerability
.... but it represents a countermeasure for the aggregate
vulnerability that is several orders of magnitude larger
and more expensive
• something you have cards ... that are supposedly
hard to counterfeit ... but changing technology over
the years have made them more and more vulnerable,
PINs with most of these existing cards have been
somewhat something you know shared-secret ...
i.e. some flavor of it is transmitted to the financial
institution. skimming technology captures the
magstripe value as well as the entered PIN;
counterfeit cards are then manufactured ... along
with notation regarding the correct pin. this
skimming also relies on re-usable values ... and
skimming operations can be setup and automated
to capture tens of thousands
• newer generation of something you have cards
with embedded chips and non-shared-secret
PINs ... i.e. the correct PIN has to be sent
to the chip ... before the chip performs the
correct operation. Some of these have acquired
the yes card label in some parts of euro-press.
transaction information is skimmed ... sufficient
to create a counterfeit chip-card. these counterfeit
chip-cards answer YES to everything ... i.e.
whether the pin entered was correct, whether the
transaction value is less than limit, etc. again
the skimming process has been automated,
allowing the capture of information for potentially
thousands of counterfeit cards (the skimming
can be identical to that used with magstr