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:
https://www.garlic.com/~lynn/subpubkey.html#rpo
misc. past postings on the subject:
https://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:
https://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: https://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
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
https://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#2 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#4 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aadsm14.htm#40 The real problem that https has conspicuously failed to fix
https://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
https://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: https://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:
https://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 ...
https://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: https://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:
https://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:
https://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:
https://www.garlic.com/~lynn/submain.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. " -
https://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
Refed: **, - **, - **
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
https://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 HIPAA, etc. Somewhat to complement the merged security
taxonomy & glossary work:
https://www.garlic.com/~lynn/index.html#glosnote
I've started a merged privacy taxonomy & glossary ... pulling from EU
data privacy directive, GLB, HIPAA, 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, HIPAA, 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:
https://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"?
Refed: **, - **, - **
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
https://www.garlic.com/~lynn/aadsm16.htm#11 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
https://www.garlic.com/~lynn/aadsm16.htm#14 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
https://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
https://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:
https://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
https://web.archive.org/web/20020204180320/http://cap-lore.com/CapTheory/upenn/
.... 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:
https://www.garlic.com/~lynn/subtopic.html#545tech
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://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:
https://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:
https://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:
https://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
https://www.garlic.com/~lynn/2004e.html#27 NSF itnerest in Multics security
https://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
https://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
https://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
https://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aepay4.htm#comcert2 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert4 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption
https://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki12 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
https://www.garlic.com/~lynn/aepay10.htm#81 SSL certs & baby steps
https://www.garlic.com/~lynn/aepay10.htm#82 SSL certs & baby steps (addenda)
https://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
https://www.garlic.com/~lynn/2001c.html#8 Server authentication
https://www.garlic.com/~lynn/2001c.html#9 Server authentication
https://www.garlic.com/~lynn/2001d.html#36 solicit advice on purchase of digital certificate
https://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
https://www.garlic.com/~lynn/2001e.html#26 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001e.html#40 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001g.html#2 Root certificates
https://www.garlic.com/~lynn/2001g.html#19 Root certificates
https://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
https://www.garlic.com/~lynn/2001n.html#57 Certificate Authentication Issues in IE and Verisign
https://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
https://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
https://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
https://www.garlic.com/~lynn/2002p.html#18 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#43 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#51 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#53 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003l.html#60 Proposal for a new PKI model (At least I hope it's new)
--
Internet trivia, 20th anv: https://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:
https://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
https://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.
there have been some number of time-sharing systems from the 60s & 70s
that were designed from the ground up to handle multiple, concurrent
users that potentially had conflicting, competitive, and/or opposing
objectives (say multiple users from competing corporations and
industrial secrets might be involved). these systems with designed in
security from the ground-up have shown to be immune to many of the
current day vulnerabilities and exploits. to some extent, there could
be valid claims about attempts to use cryptography as bandaids to
address fundamentally flawed infrastructures (or at least
infrastructures that were specifically designed to not handle many of
the existing situations that they have been used for) ... aka lets use
bandaids to treat strep infections.
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.
https://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 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:
https://www.garlic.com/~lynn/2001h.html#61
• shared-secret, one-time account numbers. this is
a fairly adequate countermeasure for the major fraud
scenario ... harvesting merchant account files. there
can still thefts/copying of individual account sheets,
just like there can be thefts of individual cards. note
however that the benefit/risk of individual thefts is
orders of magnitude less than the merchant transaction
file harvesting. as per the above url discussion of
security vis-a-vis risk ... harvesting a merchant account
file of re-usable account numbers may represent a $50m
exposure ... and hundreds of thousands of dollars
expense to a bank to block the affected accounts and
re-issue new cards. one time numbers may represent
little or no countermeasure to the individual vulnerability
.... but it represents a countermeasure for the aggregate
vulnerability that is several orders of magnitude larger
and more expensive
• something you have cards ... that are supposedly
hard to counterfeit ... but changing technology over
the years have made them more and more vulnerable,
PINs with most of these existing cards have been
somewhat something you know shared-secret ...
i.e. some flavor of it is transmitted to the financial
institution. skimming technology captures the
magstripe value as well as the entered PIN;
counterfeit cards are then manufactured ... along
with notation regarding the correct pin. this
skimming also relies on re-usable values ... and
skimming operations can be setup and automated
to capture tens of thousands
• newer generation of something you have cards
with embedded chips and non-shared-secret
PINs ... i.e. the correct PIN has to be sent
to the chip ... before the chip performs the
correct operation. Some of these have acquired
the yes card label in some parts of euro-press.
transaction information is skimmed ... sufficient
to create a counterfeit chip-card. these counterfeit
chip-cards answer YES to everything ... i.e.
whether the pin entered was correct, whether the
transaction value is less than limit, etc. again
the skimming process has been automated,
allowing the capture of information for potentially
thousands of counterfeit cards (the skimming
can be identical to that used with magstripe cards).
Is finding security holes a good idea?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 16 Jun 2004 09:57:08 -0600
To: "Arnold G. Reinhold" <reinhold@xxxxxxxx>
Subject: Re: Is finding security holes a good idea?
Cc: "Steven M. Bellovin" <smb@xxxxxxxx>,
Ben Laurie <ben@xxxxxxxx>,
Eric Rescorla <ekr@xxxxxxxx>, cryptography@xxxxxxxx
At 10:14 PM 6/15/2004, Arnold G. Reinhold wrote:
"The Mythical Man-Month" is a great book, but it's almost 30 years
old. Brooks considered OS/360 to be hopelessly bloated. My favorite
quote (from Chapter 5, The Second System Effect, p. 56):
"For example, OS/360 devotes 26 bytes of the permanently resident
date-turnover routine to the proper handling of December 31 on leap
years (when it is Day 366). That might have been left to the
operator."
Modern operating system are 2 to 3 orders of magnitude larger than
OS/360.. They are far more reliable than OS/360 was in its early days
and do not presume the availability of an on-site team of operators
and system programmers. For the most part they are still maintained
one bug at a time The bug fixing process has not reached Brook's
predicted crisis.
a small joke where we would rib the mvs people that the 40k byte
os/360 simulator in cms did almost as good a job as the 8mbyte plus )
os/360 simulator in MVS (i.e. kernel reserved 8mbytes of the virtual
address space, there was also a whole bunch of non-resident
stuff). recent thread in comp.arch:
https://www.garlic.com/~lynn/2004f.html#55 Infiniband - practicalities for small clusters
references to environment in the disk engineering lab with "testcells"
which resulted in 15min MTBF for MVS with single test cell operating
... and therefor required that single testcell (at a time) development
& test occured in stand-alone environment. I rewrote the I/O subsystem
so that six to 12 testcells could be operated concurrently in an
online environment:
https://www.garlic.com/~lynn/subtopic.html#disk
there are several feedback effects to controlling bug process
.... when bugs get to bad ... the users, customers, installations stop
doing the things that hurt (the joke about guy going to the doctor and
saying it hurts when i do this ... and the doctor says stop doing
it). the other effect is that when the backlog of bugs get too long
... everybody gets pulled off everything else and the only thing that
goes on is bug fixes.
finally, there has been fairly stringent change control and regression
testing evolved at all stages in the infrastructure ... if the new
changes can't do all the work that the unchanged system could ... then
the changes aren't rolled in. For large, complex infrastructures, this
has a tendency limiting change. One might conclude that was one of the
reasons that the whole future system failed in the early 70s which was
going to be a much more radical change than 360 had been before it. In
a seminar at MIT in the early 70s, Amdahl sort of alluded to this as
being one of the arguments that he used to get funding for his new
company.
the supposed justification for FS (future system) project was
countermeasure to the PCM controller business ... something that I've
beenaccused as helping originate from a project that I worked on as an
undergraduate ... supposedly producing the first PCM controller
(i.e. reverse engineered 360 channel interface, built channel board
and programmed a minicomputer to emualte a 360 controller)
https://www.garlic.com/~lynn/submain.html#360pcm
specific reference to fs overview
https://www.garlic.com/~lynn/2000f.html#16 [OT] FS - IBM Future System
lots more references to future systems
https://www.garlic.com/~lynn/submain.html#futuresys
if you are really feeling interested ... when I did the resource
manager ... I did a series of 2000 tests that took three months
elapsed time beofre release the product ... misc. past refs to
regression testing & benchmarking procedure:
https://www.garlic.com/~lynn/submain.html#bench
the base product had a process that released a monthly accumulated fix
(PLC) tape. They wanted me to provide a monthly resource manager PLC
tape on the same schedule .... however, I said that it would be nearly
impossible for me to do it more than once every three months since at
a minimum I would have to do at least 100 different regressions tests
taking minimum of 48 hrs elapsed time for even an incremental PLC
distribution. resent posting about the whole PLC business
https://www.garlic.com/~lynn/2004g.html#40 IBM 7094 Emulator - An historic moment?
lots of past posts about resource manager, scheduling, page
replacement algorithms, caching, etc:
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock
Is finding security holes a good idea?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 16 Jun 2004 10:24:33 -0600
To: "Arnold G. Reinhold" <reinhold@xxxxxxxx>
Subject: Re: Is finding security holes a good idea?
Cc: "Steven M. Bellovin" <smb@xxxxxxxx>,
Ben Laurie <ben@xxxxxxxx>,
Eric Rescorla <ekr@xxxxxxxx>, cryptography@xxxxxxxx
oh, and almost forgot ... a rambling story that gets around to talking
about future system project ... and all the super security that they
put in place to protect all the future system documentation ... they
really wanted to have an environment where the future system
documentation was only available in restricted online, softcopy
environment and it was impossible to get hardcopy (this was somewhat
after a incident were paper document of unannounced 370 virtual memory
was "copied" and leaked to the press ... which led to putting
embossing numbers on all copy machines which would show up on all
copies). somebody made the off-hand statement that even I couldn't
access the documents .... so i replied i could do it in less than five
minutes (... actually 60 seconds ... but i first had to remove all
connections to the machine because what i was going to do was really
fundamental).
https://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
x9.99 financial PIA standard now available from ANSI e-store
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/18/2004 08:51 AM
To: internet-payments@xxxxxxxx
Subject: x9.99 financial PIA standard now available from ANSI e-store
somewhat in conjunction with working on X9.99, i started a merged
financial privacy taxonomy and glossary. for more notes & pointers on
merged taxonomy & glossary work see:
https://www.garlic.com/~lynn/index.html#glosnote
x9.99 at the ansi e-store
http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.99%3a2004
authentication and authorization (was: Question on the state of the security industry)
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 01 Jul 2004 20:40:39 -0600
To: John Denker <jsd@xxxxxxxx>
Subject: Re: authentication and authorization (was: Question on the state of the security industry)
Cc: cryptography@xxxxxxxx, Ian Grigg <iang@xxxxxxxx>
At 12:26 PM 7/1/2004, John Denker wrote:
The object of phishing is to perpetrate so-called "identity
theft", so I must begin by objecting to that concept on two
different grounds.
there are two sides of this .... some amount of crime statistics call
it ID-theft .... which plausibly could be either identity or
identification ... but in general involves situation where criminal is
impersonating you to one degree or another to perform some fraudulent
action.
there has been some attempt to distinguish impersonation events
between fraudulently extracting money from existing accounts and
fraudulently creating new accounts in your name.
practically, objecting to the label id-theft may be like objecting to
the label suicide bomber.
in general, the problem is using any kind of static data for
authentication. it applies to name, birthdate, mother's maiden name,
pins, passwords, account numbers .... any kind of static data. it
worked for a long time ... but it was based on assumption that it had
characteristics of 1) shared-secret and 2) used uniquely, different
static data in different security domains.
the growth of electronic environments has drastically affected this in
lots of ways (invalidating the core assumptions that was behind the
use of such static data for authentication, it wasn't that static data
didn't work ... but it worked well only as long as the underlying
assumptions were valid):
1) drastic increase in number of different electronic environments
requiring unique shared-secrets ..... basic human factors making it
impossible to process unique shared-secret for every possible (scores
of unique) environment
2) drastic increase in number of different electronic environments
... drastically increasing the number of places that shared-secrets
are being used ... which increasing the places that shared-secrets can
be harvested (for criminal purposes)
3) drastic increase in electronic environments that contain
information about individuals ... drastically increasing the number of
places that personal information can be harvested (of the type that is
likely to be used in shared-secret, static authentication information)
for criminal purposes.
minor reference to the account based scenario .... security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
and then there is the whole thing about frequent confusion of
identification and authentication:
https://www.garlic.com/~lynn/aepay3.htm#mcomm (my) misc. additional comments on X9.59 issues.
https://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12b A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm14.htm#40 The real problem that https has conspicuously failed to fix
https://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
https://www.garlic.com/~lynn/aadsm17.htm#13 A combined EMV and ID card
https://www.garlic.com/~lynn/aadsm17.htm#16 PKI International Consortium
https://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
authentication and authorization ... addenda
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 02 Jul 2004 07:57:02 -0600
To: cryptography@xxxxxxxx
Subject: Re: authentication and authorization ... addenda
ref:
https://www.garlic.com/~lynn/aadsm17.htm#46
one of the industry groups brought my wife and me in to help work on
the cal. and then the federal e-sign legislation. there is this
intersection between privacy, e-sign, and fraud. in any case, one of
the things that they had done was a study of the driving factors for
legislative and regulatory privacy activity ... the two primary
driving factors were
• id-theft
• (institutional) denial of service (to individuals)
the claim could be made that the id-theft issue is almost totally
related to the use of various kinds of static data for authentication
and that given the current pervasive electronic online world .... that
it is effectively impossible to continue operating with static data
paradigm w/o having to accept large amount of exploits and fraud.
the privacy legislative and regulatory mandates can try and establish
rules for "protecting" information ... but keeping static data
authentication information "private" is a loosing battle. in part,
because traditionally 90% of the exploits have involved insiders
.... although recent study now only claims that at least 77% of the
incidents involve insiders. All the internet histeria about outsiders
... in part just obfuscates identifying the real sources of the
problem.
one assertion is that the whole environment collapses because large
scale, wide-spread static data based authentication paradigm has too
many vulnerabilities ... somewhat as per the previous reference to
security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
if nothing else ... there isn't sufficient finances to fund the
security necessary to protect all the authentication static
data. also, this isn't taking into account the wide-spread education
necessary for countermeasure to the social engineering and phishing
exploits.
some sort of hardware token with non-static data (as something you
have authentication) starts to address the situation. the issue isn't
that the hardware token can't be stolen .... but it is difficult to
steal electronically a million at a time (large scale harvesting with
little investment and risk is one of the things that makes phshing so
attractive ... the potential fraud ROI is enormous).
If the hardware token implements a non-static data authentication
paradigm and never exposes its internal secrets (say like a private
key of public/private key pair) ... then no amount of phishing can
convince somebody to divulge something that they don't know. social
engineering might still be able to convince people to mail their
authentication token to some far off country (that requires quite a
bit more gullable populace .... comparable to convincing everybody
that they have to mail off their driver's license to some far off
location).
changing the paradigm from static data authentication to non-static
data authentication would do more for reducing id-theft
vulnerabilities than all the privacy and security regulations. one of
the side issues .... is sometimes if all you have is a data security
classification & protection hammer ... then the solution to all
problems is protecting the data. The security proportional to risk
scenario is it is impossible to protect the pervasive use of
authentication static data ... the paradigm has to be changed.
legislative and regulatory privacy mandates would still be necessary
for the other privacy driving factor .... (institutional) denial of
service (to individuals).
there will still be various kinds of impersonation fraud .... if you
can't perform fraudulent financial transactions by stealing account
numbers .... criminals might still open accounts in victims
names. However, an assertion is if the points of attack are reduced by
several orders of magnitude ... aka from all transactions (because of
stolen account numbers) to stolen hardware tokens and opening accounts
... then it is possible to better concentrate the security budget on
the drastically reduced attack points and threat models.
i mentioned before that i've been one of the x9.99 (privacy impact
assessment) standard co-authors for the last year or so .... and it is
now out for public comment (can be bought from the ansi e-store)
... and there is work item proposal to move it forward to ISO. For
part of the background work, i started a merged privacy taxonomy and
glossary .... similar to the merged taxonomy & glossary work that i've
done in other areas:
https://www.garlic.com/~lynn/index.html#glosnote
FTC has some resources in this area:
http://www.ftc.gov/bcp/conline/edcams/gettingcredit/resources.html
I gave a talk earlier this week at treasury conference in DC on
privacy and id-theft ... and there were some number of questions about
resources for individuals that are victims of id-theft
Japanese bank offers 'biosecurity' account
From: Lynn Wheeler
Date: 07/02/2004 12:58 PM
To: internet-payments@xxxxxxxx
Subject: Japanese bank offers 'biosecurity' account
https://web.archive.org/web/20040910000733/http://www.kansascity.com/mld/kansascity/business/technology/9066667.htm?1c
TOKYO (AP) - A Japanese bank on Friday launched a biosecurity account,
the holders of which can only conduct transactions once they have
proved their identity -- by showing the pattern of veins on their
palms.
... snip ...
slightly related to id-theft & authentication thread in another mailing list:
https://www.garlic.com/~lynn/aadsm17.htm#46 authentication and authorization (was: Question on the state of the security industry)
https://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
Use cash machines as little as possible
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 04 Jul 2004 14:25:23 -0600
To: cryptography@xxxxxxxx
Subject: Use cash machines as little as possible
http://www.thisislondon.com/news/business/articles/timid80044?source=
http://www.thisismoney.com/20040704/nm80044.html
ONE of Britain's biggest banks is asking customers to use cash
machines as little as possible to help combat soaring card fraud.
... snip ...
authentication and authorization (was: Question on the state of the security industry)
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 07 Jul 2004 10:07:29 -0600
To: "Anton Stiglic" <astiglic@xxxxxxxx>
Subject: RE: authentication and authorization (was: Question on the state of the security industry)
Cc: "'John Denker'" <jsd@xxxxxxxx>,
<cryptography@xxxxxxxx>, "'Ian Grigg'" <iang@xxxxxxxx>
At 07:23 AM 7/5/2004, Anton Stiglic wrote:
Identity has many meanings. In a typical dictionary you will find
several definitions for the word identity. When we are talking about
information systems, we usually talk about a digital identity, which
has other meanings as well. If you are in the field of psychology,
philosophy, or computer science, identity won't mean the same
thing. One definition that relates to computer science that I like is
the following: "the individual characteristics by which a thing or
person is recognized or known".
another way of looking at it in an authentication/authorization
infrastructure is that some set of privileges are asserted ... this is
typically done by having some sort of identification associated with
those privileges (like an account number or userid). There can be some
confusion whether what is being asserted is a tag, identity or
identification. if the tag being asserted, is something like a
person's name, the institution is likely just using it for a tag to
look up the set of privileges associated with that name (they may not
actually care who you are ... they want to know what privileges are
associated with the name/tag).
then there is some sort of authentication as to the binding to those
set of privileges .... aka 3-factor authentication taxonomy
• something you know
• something you have
• something you are
note, in some scenarios .... it is possible that knowing the account
number provides both the privilege assertion as well as the something
you know authentication (aka knowing the account number is sufficient
to make withdrawals).
in any case there are frequently used institutional processes that can
be characterized by assertion of privileges and authentication. The
taxonomy of those processes can be considered independent of the terms
used to label the processes (is a guard really interested in who you
are or just finding out what privileges and permissions you have).
so we have an environment with institutions and CSOs and an attitude
that the institution and the institution integrity must be protected
from outsiders (and criminal insiders)
however, with the prevalent use of static data and something you
know authentication paradigms ... there is huge amounts of static
data laying around, ripe for the harvesting ... where the criminal
impersonates an individual. so one view is that the vulnerability is
the extensive use by institutions of static data and something you
know authentication, where the individual may have little or no
ability to protect the majority of the information. The crime appears
to be against the individual and the source of the information may be
totally unrelated to where the crime actually occurs. Assuming that
the source of the vulnerability are the institutional infrastructures,
some laws have been passed to try and hold the institutions
responsible for the protection of individual information. in some
scenarios, institutions are charged with protecting individual
information from the institution itself (which sort of inverts a
security officers job of protecting institution from others).
However, in some scenarios
https://www.garlic.com/~lynn/2001h.html#61
the common use of static data is so pervasive that an individual's
information is found at thousands of institutions. The value of the
information to the criminal is that the same information can be used
to perpetrate fraud across all institutions and so the criminal value
is enormous. However the value to each individual institution may be
minimal. As a result there can be situations where an individual
institution hasn't the infrastructure or the funding to provide the
countermeasures necessary to keep the criminals away from the
information (they simply don't have the resources to provide security
proportional to the risk).
The value of the static data authentication information to a criminal
is far greater than the value of the information to the institution
... or the cost to the criminal to acquire the information is
possibly orders of magnitude less than the value of the information
(for criminal purposes).
Given such a situation .... the infrastructures simply don't have the
resources to provide the countermeasures adequate to meet the attacks
they are going to experience (there is such a huge mismatch between
the value of the information to the individual institutions and the
value of the information to the criminal).
Which results in my assertion that there has to be a drastic move away
from the existing static data authentication paradigm .... because
there is such a mismatch between the value to secure the information
verses the value of attacks to obtain the information.
It isn't that theory can't provide mechanisms to protect the
information .... it that the information is spread far and wide and is
in constant use by thousands of business processes, and that
protection problem is analogous to the problem of having people
memorize a hundred different 8+character passwords that change every
month (which is also a shortcoming of the static data authenticaton
paradigm).
misc:
https://www.garlic.com/~lynn/subintegrity.html#fraud
https://www.garlic.com/~lynn/subpubkey.html#privacy
authentication and authorization
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 07 Jul 2004 10:25:02 -0600
To: "Anton Stiglic" <astiglic@xxxxxxxx>
Subject: RE: authentication and authorization
Cc: "'John Denker'" <jsd@xxxxxxxx>,
<cryptography@xxxxxxxx>, "'Ian Grigg'" <iang@xxxxxxxx>
At 09:20 AM 7/6/2004, Anton Stiglic wrote:
Well, there is nt established technical definition for "digital
identity", but most definitions seem to focus to what I defined it as.
there is actually a whole series of issues.
the identity x.509 certificates from early 90s were targeted at stuff
that appeared to be totally unrelated to existing business processes
and environment.
given the scenario that existing business relationships and
permissions have been established .... there is requirement to
asserting access to those permissions (some means of asserting some
identification associated with the permissions and some means of
authentication or substantiating the rights to the permissions).
identity x.509 certificates have been totally unrelated to such a
business environment ... although attempts have been made to contort
them into that use. the original premise was that the identity x.509
certificates could be used by parties that previously had no direct
knowledge of each other and could make use of the x.509 certificates
w/o needing any recourse to any additional information. one problem
was a random name from some place in the world had no context or
meaning to some other random entity some place in the world.
putting a person's instantly changing available balance in the
certificate might do. however this had (at least) two problems 1) it
could be considered privileged information that deemed not advisable
in public certificates with copies all over the planet and 2) with
possibly thousands of each such certificate cached all around the
world .... there was some issue with instantaneously and dynamically
updating all copies.
so in the mid-90s there was some retrenchment to relying-party-only
certificates ... which basically only contained an account number and
the public key. the transaction always went to where the permissions
and other important information was available. However it was
trivially possible to show that in such situations, the certificates
are redundant and superfluous.
The majority of the business infrastructures in the world don't need
free floating and complete personal information contained in a
certificate about random and totally unknown entities. The need a
non-static-data authentication paradigm to replace the static data
authentication paradigm, i.e. simply replace pin/password with public
key and digital signatures.
misc:
https://www.garlic.com/~lynn/subintegrity.html#fraud
https://www.garlic.com/~lynn/subpubkey.html#privacy
FUJITSU DEVELOPS ENCRYPTION TECH THAT TAKES 20 MILLION YEARS TO BREAK
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 08 Jul 2004 08:33:42 -0600
To: <cryptography@xxxxxxxx>
Subject: FUJITSU DEVELOPS ENCRYPTION TECH THAT TAKES 20 MILLION YEARS TO BREAK
http://www.antaranews.net/en/index.php?id=s6384
Tokyo, July 8 (ANTARA/AFP) - Japanese IT giant Fujitsu Ltd. said
Wednesday it has developed credit card encryption technology which is
impossible to break with existing means
... snip ...
Using crypto against Phishing, Spoofing and Spamming
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 08 Jul 2004 09:44:52 -0600
To: hal@xxxxxxxx ("Hal Finney")
Subject: Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: cryptography@xxxxxxxx
At 10:40 AM 7/7/2004, Hal Finney wrote:
SET failed due to the complexity of distributing the software and
setting up the credentials. I think another reason was the go-fast
atmosphere of the late 90s, where no one wanted to slow down the
growth of ecommerce. The path of least resistance was simply to bring
across the old way of authorizing transactions by card number.
both SET & SSL encrypted data in transit.
an issue is that SET is significantly more complex and provided no
additional countermeasure (vis-a-vis SSL) against major
remaining exploits .... like harvesting the merchant transaction file
while at rest.
there was some issue that SSL was the incumbent ... so SET had to
demonstrate significant better ROI to displace it ... rather than
significantly higher "I" with little or no additional "R".
some SSL:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
the security proportional to risk reference (using merchant
transaction file as example)
https://www.garlic.com/~lynn/2001h.html#61
couple minor past refs related to SET business operations
https://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
another SET issue was that it took a typical ISO 8583 transaction of
60-80 bytes and added a RSA 128-byte digital signature and issuing
certificate of 4k-12k bytes .... effectively increasing the payload
size by a factor of two orders of magnitude. it stripped all the SET
overhead off at the internet boundary and transmitted a traditional
8583 message (in part because it was difficult to justify a 100-fold
increase in payload size for no obvious benefit) with a flag
indicating whether the signature had verified.
There was some presentation at an ISO meeting by one of the
association business people about the number of 8583 messages with the
signature-verified flag turned on and they absolutely knew that there
was no SET technology involved (some justification was association was
proposing rules that transactions with the flag on would have lower
merchant fees).
missing is that typical authorization includes a lot of dynamic and
aggregation factors (like credit limit) that are totally missing in a
simple stale, static certificate-based (offline) authentication
model. In fact, most infrastructures that involve transactions of any
value have migrated and/or are migrating to online infrastructures
that involve timely and/or aggregated information .... something that
is missing from a purely offline, certificate-based, stale,
static data infrastructure.
misc. implications
1) given an online transaction environment, it is then trivial to show
that certificates are redundant and superfluous ... because it is
possible to access the timely updated copy of the information rather
than having to rely on the stale, static copy of the certificate
information (designed to satisfy an offline environment requirement)
2) certificate market then becomes relegated to both offline and
no/low value (as infrastructures of value migrate to online paradigms)
3) there is little/no justification for paying money for certificates
if only no/low value infrastructures are involved.
4) w/o significant funding for certificate-based infrastructure, there
is little money to underwrite high-integrity certificate-based
operations
5) with no high-integrity certificate-based operations, it is
difficult to justify using certificates for high-value operations
6) go to #2
as has past frequently noted, the requirement given the x9a10 retail
payments working group for the x9.59 standard was to preserve the
integrity of the financial infrastructure for all retail payment
environments. one of the considerations was being able to accommodate
end-to-end integrity ... aka the financial responsible entity for
authorizing the transaction also performs the authentication. another
issue for x9a10 was to address other kinds of risks
.... like the merchant transaction file where the information
traditionally has to occur in the clear to support normal business
operations (offer something more than the encryption of data
in-flight).
https://www.garlic.com/~lynn/x959.html#x959
lots of posts about certificate infrastructures
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
and relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
misc. stuff on x9.59, identity, authentication, and privacy
https://www.garlic.com/~lynn/subpubkey.html#x959
Using crypto against Phishing, Spoofing and Spamming
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 09 Jul 2004 04:14:01 -0600
To: hal@xxxxxxxx ("Hal Finney")
Subject: Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: cryptography@xxxxxxxx
At 10:40 AM 7/7/2004, Hal Finney wrote:
SET failed due to the complexity of distributing the software and setting
up the credentials. I think another reason was the go-fast atmosphere of
the late 90s, where no one wanted to slow down the growth of ecommerce.
The path of least resistance was simply to bring across the old way of
authorizing transactions by card number.
the other issue was rsa public key op overhead (besides extreme
payload bloat, extreme additional complexity, and no significant
countermeasures for prime exploits compared to e-commerce incumbent
SSL) ... ref: previous post:
https://www.garlic.com/~lynn/aadsm17.htm#53
when the initial set specification was published, i did a business
profile and a performance profile (including public key operations
profile). somebody i knew was playing with bsafe library and tweaked
it to run four times faster. I got him to run the SET public key op
profile on a number of processors.
i mentioned the numbers at some SET get together and the response from
the SET people was that it was 100 times too slow (if they had ever
run any bsafe they should have realized that it was four times too
fast). anyway ... sometime later when they had actual SET
implementations running ... the earlier profile numbers were within a
couple percent of measured on actual implementations.
i also observed that given nominal extended peak avgs. of
1000/transactions per sec .... that if SET ever actually became
mainstream operational (rather than just toy pilots) ... processing
would need something like 100,000 to 250,000 extra processors to
handle the RSA op processing load. the counter argument was that SET
would take so long to became mainstream ... that by then CPUs might be
ten to 100 times faster and it might only require 10,000 to 25,000 (or
1,000 to 2,500?) extra processors.
Using crypto against Phishing, Spoofing and Spamming
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 15 Jul 2004 09:06:42 -0600
To: Rich Salz <rsalz@xxxxxxxx>
Subject: Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: Hal Finney <hal@xxxxxxxxx>,
<cryptography@xxxxxxxx>
At 06:42 AM 7/15/2004, Rich Salz wrote:
it wasn't a CCard transacdtion, my liability under SET was unlimited
(at least until Congress caught up to the technology). Looking at the
risk management aspect, SET was a big loser for the customer.
my earlier responses
https://www.garlic.com/~lynn/aadsm17.htm#53
https://www.garlic.com/~lynn/aadsm17.htm#54
i also included some discussion on it at a talk i gave on naked keys
at global grid forum conference last month, focusing on business
issues of authentication; ... minor ref (with pointer to the GGF pages
& presentation):
https://www.garlic.com/~lynn/2004g.html#53
with some comparison to x9.59
https://www.garlic.com/~lynn/x959.html#x959
.... one of the business issues with public key infrastructures is the
dual-use vulnerability of using digital signatures for both
authentication and signatures.
many of the authentication infrastructures have the server sending the
user some random data to be signed as part of authentication (issues
like replay attacks, etc); which the user never looks at.
ignoring all the non-repudiation issues .... real signatures are
suppose to imply things like agreement, approval, and/or authorization
(of the contents of what is being signed).
the dual-use vulnerability is ever having signed random data ... w/o
reading it .... and using the same technology to sign documents where
reading is implied (as well as agreement, approval, authorization).
the scenario is somewhat out of MASH where Radar is periodically
having the col. sign documents w/o having read them.
Question on the state of the security industry
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 15 Jul 2004 17:18:21 -0600
To: Ian Grigg <iang@xxxxxxxx>
Subject: Re: Question on the state of the security industry
Cc: cryptography@xxxxxxxx
A couple recent news stories
1)
Intuit warns of credit card risk
http://news.com.com/Intuit+warns+of+credit+card+risk/2100-1029_3-5269821.html
2)
Cyberattacks are soaring, countermeasures are sucking up tons of cash,
and hardware and software vendors for the most part are sitting it
out, *Bob Evans* says. But big customers are starting to say enough is
enough, so the business-technology world is about to get whirled.
http://www.informationweek.com/story/showArticle.jhtml;jsessionid=WK0LPHXYB4YSUQSNDBGCKHY?articleID=22104612
...................
i've been saying for some time that after market security is broken by
design ... it is somewhat like after market seat belts of the 60s. for
security to work, it has to be designed & built in from the start
.... some relatively recent comments about after market security:
https://www.garlic.com/~lynn/2002h.html#39 Oh, here's an interesting paper
https://www.garlic.com/~lynn/2002p.html#27 Secure you PC or get kicked off the net?
https://www.garlic.com/~lynn/2003n.html#14 Poor people's OS?
dual-use digital signature vulnerability
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 16 Jul 2004 08:31:27 -0600
To: cryptography@xxxxxxxx
Subject: dual-use digital signature vulnerability
ok, this is a long posting about what i might be able to reasonable
assume if a digital signature verifies (posting to c.p.k newsgroup):
https://www.garlic.com/~lynn/2004h.html#14
basically the relying-party has certified the environment that houses
the private key and the environment that the digital signature was
done in ... then the verification of the digital signature might be
assumed to imply one-factor or possibly two-factor authentication
(i.e. if the relying-party has certified that a private key is housed
in a secure hardware token and can never leave that hardware token,
then the verification of the digital signature might imply one-factor,
something you have authentication).
that establishes the basis for using digital signature for
authentication purposes ... being able to assume that verification of
the digital signature possibly implies something you have
authentication (or something similar).
just the verification of the digital signature, however doesn't do
anything to establish any implication about a legal signature where
the "signer" is assumed to have read and agrees to the contents of the
thing being signed (intention to sign the content of the document as
agreement, approval, and/or authorization).
lets assume for argument sake that some sort of environment can be
certified that provides a relying party some reasonable assurance that
the signer has, in fact, read and is indicating agreement, approval,
and/or authorization ... then there might possible be the issue of the
dual-use vulnerability.
the dual-use comes up when the person is signing random challenges
as purely a means of authentication w/o any requirement to read the
contents. Given such an environment, an attack might be sending some
valid text in lieu of random data for signature. Then the signer may
have a repudiation defense that he hadn't signed the document (as in
the legal sense of signing), but it must have been a dual-use attack
on his signature (he had signed it believing it to be random data as
part of an authentication protocol).
Using crypto against Phishing, Spoofing and Spamming
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sat, 17 Jul 2004 09:25:41 -0600
To: Florian Weimer <fw@xxxxxxxx>
Subject: Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: hal@xxxxxxxx, cryptography@xxxxxxxx
At 10:46 AM 7/10/2004, Florian Weimer wrote:
But is it so harmful? How much money is lost in a typical phishing
attack against a large US bank, or PayPal? (I mean direct losses due
to partially rolled back transactions, not indirect losses because of
bad press or customer feeling insecure.)
misc. recent selections
Online Phishing Scams Exploding
http://itmanagement.earthweb.com/secu/article.php/3382341
Business faces growing loss from identity theft
http://www.vnunet.com/news/1156655
Firms hit hard by identity theft
http://www.boston.com/business/technology/articles/2004/07/14/firms_hit_hard_by_identity_theft/
ID theft costing UK billions in taxes
http://news.zdnet.co.uk/0,39020330,39160532,00.htm
ATM skimmers go hi-tech down under
http://www.finextra.com/fullstory.asp?id=12184
Phishing will cost financial firms $400m in 2004
http://www.finextra.com/fullstory.asp?id=12173
Worried firms consider email boycott
http://www.vnunet.com/news/1156684
social engineering has frequently been talking somebody into giving up
some information that then can be used for impersonation in later
fraudulent transactions. A something you have token of some sort is
a lot harder to give-up than shared-secrets for use in something you
know authentication. A private key that never leaves the hardware
token can't be given up because even the owner doesn't know it. also,
conjecture is that it is a lot harder to convince general public to
mail off some physical object compared to getting them to divulge some
information.
hardware tokens don't eliminate social engineering attacks where the
victim is talked into performing some transaction on behalf of the
attacker ... but they would tend to address the whole vulnerability
landscape related to something you know shared-secret authentication
paradigms.
one of the cost issues with technology for server reputation is that
it typically applies to servers that the consumer is visiting for the
first time (or visits extremely rarely). the consumer pretty much
ignores repetitive information for sites that they visit
frequently. it has been that something like ninety percent (or better)
of internet transactions are done by the frequently visited sites. so
the cost issue is that the reputation technologies basically tend to
apply to the millions of low-volume and/or low-revenue sites (in
aggregate accounting for 10 percent or less of all transactions)
... which aren't looking to spend a lot of money on such technologies.
it is somewhat like the better business bureau use .... people will
tend to contact the better business bureau before they deal with some
vendor for the first time .... but they aren't likely to contact the
better business bureau each time they deal with a vendor that they
have extensive repeat business with. it at least some scenarios ....
an alternative to the business logo .... is a better business bureau
or gov. licensing logo on a website .... that provides click-thru to
the official site .... where the consumer can review complaints and/or
history about the business in question. i believe that this is
somewhat the ebay model ... where past transaction history reputation
of individuals can be checked.
dual-use digital signature vulnerability
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 Jul 2004 08:54:56 -0600
To: Amir Herzberg <herzbea@xxxxxxxx>
Subject: Re: dual-use digital signature vulnerability
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>, cryptography@xxxxxxxx
At 01:33 AM 7/18/2004, Amir Herzberg wrote:
I don't see here any problem or attack. Indeed, there is difference
between signature in the crypto sense and legally-binding
signatures. The later are defined in one of two ways. One is by the
'digital signature' laws in different countries/states; that approach
if often problematic, since it is quite tricky to define in a general
law a binding between a person or organization and a digital
signature. The other way however is fine, imho: define the digital
signature in a ('regular') contract between the parties. The contract
defines what the parties agree to be considered as equivalent to their
(physical) signature, with well defined interpretation and
restrictions.
...
the digital signature laws, for the most part, defined how a
certification authority went about binding the owner of a public key
(or at least the entity presenting a public key and a digital
signature that could be verified by that public key) and some other
information ... and presenting that in a certificate. However, I don't
remember seeing any of the e-sign laws a) defining a non-repudiation
environment that is mandated for signature digital signing environments
(indicating that the key owner has read, understood, and approves,
agrees, and/or authorizes the contents of the message and b) as
part of the integrity of the message, there is proof that such a
non-repudiation environment was used.
1)
the relying party being able to certify the integrity level of
something like a hardware token .... for use in something you have
authentication .... aka the relying party verifies a digital signature
and that verification may used to imply something you have
authentication (at this point there is absolutely nothing involving a
certificate). However, in order for the relying party to be able to
assume or imply what the verification of the digital signature
actually means .... and therefor how much it can trust the
verification ... it needs to know how the private key is maintained
and operated. If the act of verifying a digital signature actually
means or implies that it is something you have authentication
... then it needs to have some certification along the lines that the
private key is used and maintained in a hardware token with specific
characteristics. It has nothing at all to do with any certificate
traditionally mentioned in various kinds of e-sign laws.
2)
during the early '90s, the identity certificates tended to be
overloaded with all sorts of identity and privacy information. this
was fairly quickly realized to represent serious privacy and liability
issues. this was retrenched to things like relying-party-only
certificates that basically only had a public key and some sort of
account identifier (which could be used by the relying party to pull
up the real information .... w/o having it publicly broadcast all over
the world). However, there were also things like non-repudiation
bits defined in certificates ... that have since been severely
depreciated. During the mid-90s there were some infrastructures being
proposed that if you had some data which had an appended digital
signature and an appended certificate containing a non-repudiation bit
.... then the burden of proof (in disputes) could be shifted from the
relying party to the signing party.
This was vulnerable to possibly two exploits
a) the digital signer had believed that they had signed random data as
part of an authentication protocol ... as opposed to having signed
some document contents indicating agreement, approval, and/or
authorization (as in real live signature .... aka the dual-use
scenario) and/or
b) since the appended certificate isn't part of the signed transaction
.... the relying-party might be able to find a digital certificate
(belonging to that key-owner for the same public key) that had the
non-repudiation bit set and substitute a non-repudiation certificate
for the certificate that the key-owner had actually appended (aka the
certificate is not part of the integrity of the message covered under
the digital signature).
3)
at the NIST PKI workshop a couple months ago .... there were a number
of infrastructure presentations where various entities in the
infrastructure were
a) signing random data as part of authentication protocol (where the
entity performing the digital signature was given no opportunity to
view the contents being signed) they were using hardware token
implementation .... and they were assuming that the verification of
the digital signature implied some sort of something you have
authentication. however there was nothing in the infrastructure that
provided certification and/or proof that the private key was kept and
maintained in a hardware token .... so there was no proof as to the
level of integrity and/or level of trust that the relying party could
place in the verification of that digital signature
used in the authentication protocols)
However, there was no distinguishing and/or provable characteristics
that were provided which a relying-party could use to distinguish
between (random) contents that were signed as part of an
authentication protocol and (authorization) contents ... where the
relying-party could assume to indicate that the signer was agreeing,
approving, and/or authorization what was indicated by the contents of
the document.
Since there was no proof provided to the relying-party as to the
environment and conditions under which the signing actually occurred
.... then a dual-use attack is for non-random contents (aka some sort
of authorization document) to be injected into an authentication
protocol .... under the assumption that the entity performing the
digital signature will never look at the contents. Then such digitally
signed contents can be used in an approval, agreement, and/or
authorization scenario to imply that the entity performing the digital
signature was actually approving the contents of the document.
4)
this now verges into various of the non-repudiation definitions
and threads that have occurred in the past. in effect, for any kind of
infrastructure where the digital signature is being used to imply that
the token-owning entity (responsible for the digital) signature
agrees, approves, and/or authorizes what is in the content of the
message being signed (as opposed to some random data being signed as
part of authentication protocol and is never viewed) ... there has to
be some additional signing environment (demonstrating that the signer
has actually read, understood, and agrees with the contents) ... and
the proof of the use of such a signing environment infrastructure has
to be carried as part of the integrity of the message .... in order
for the relying party to rely on it being a real signature
signing event ... as opposed to have really originated from an
authentication protocol where the person believed that random data was
being signed (and never actually viewed the contents being
signed). Note that not only does such an non-repudiation
signing environment need to have been used .... but the proof of its
use has to be carried as part of the integrity of the message (in
order for the relying party to distinguish between random data being
digital signed and case where the person having signed after viewing
the contents, understanding the contents and approving, agreeing,
and/or authorization what was indicated by the contents). So it isn't
just that a non-repudiation environment has to be used for
signing operations (as in human signature) ...but the proof of such
non-repudiation environments have to be carried as part of the
integrity of the message .... to differentiate from a dual-use attack
where the signing is believed to be random data and the person never
views the contents.
5)
other kinds of infrastructure implementations may be to have two
completely different hardware tokens with two completely different
public/private key pairs.
the hardware token used for authentication protocols doesn't concern
itself with the contents of the data ... in fact it always appends a
disclaimer to all random data (that it signs) stating that the digital
signature cannot be used to imply any agreement, approval,
authorization and/or any obligation on the part of the
token-owning entity.
the hardware token used for authorization, agreement, and/or approval
signing events will never perform a digital signature operation unless
it first senses that the token owner has read, understood and
approved of the contents.
all protocols indicate as part of the hardware token interaction, which
type of digital signature will be performed ... and the owner of the
hardware tokens is then instructed appropriately when hardware token
swapping needs to occur.
=========
random past posts about non-repudiation:
https://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm12.htm#5 NEWS: 3D-Secure and Passport
https://www.garlic.com/~lynn/aadsm12.htm#12 TOC for world bank e-security paper
https://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
https://www.garlic.com/~lynn/aadsm12.htm#38 Legal entities who sign
https://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses "Authority-stamp-signatures"
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
https://www.garlic.com/~lynn/aadsm14.htm#48 basic question: semantics of "map", "tie", etc in PKI
https://www.garlic.com/~lynn/aadsm15.htm#32 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#34 VS: On-line signature standards (slight addenda)
https://www.garlic.com/~lynn/aadsm15.htm#35 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
https://www.garlic.com/~lynn/aadsm16.htm#11 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm16.htm#13 The PAIN mnemonic
https://www.garlic.com/~lynn/aadsm16.htm#14 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm16.htm#17 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm16.htm#18 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm16.htm#23 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#3 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#5 Non-repudiation (was RE: The PAIN mnemonic)
https://www.garlic.com/~lynn/aadsm17.htm#55 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#38 distributed authentication
https://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
https://www.garlic.com/~lynn/2002g.html#37 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002h.html#68 Are you really who you say you are?
https://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002i.html#77 Does Diffie-Hellman schema belong to Public Key schema family?
https://www.garlic.com/~lynn/2002j.html#24 Definition of Non-Repudiation ?
https://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#16 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision
https://www.garlic.com/~lynn/2003.html#29 Message (authentication/integrity); was: Re: CRC-32 collision
https://www.garlic.com/~lynn/2003f.html#37 unix
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature
https://www.garlic.com/~lynn/2003h.html#38 entity authentication with non-repudiation
https://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
https://www.garlic.com/~lynn/2003k.html#6 Security models
https://www.garlic.com/~lynn/2003m.html#38 Questioning risks of using the same key for authentication and encryption
https://www.garlic.com/~lynn/2003o.html#22 securID weakness
https://www.garlic.com/~lynn/2003o.html#29 Biometric cards will not stop identity fraud
https://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication?
https://www.garlic.com/~lynn/2003p.html#11 Order of Encryption and Authentication
https://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication?
https://www.garlic.com/~lynn/2004e.html#20 Soft signatures
Using crypto against Phishing, Spoofing and Spamming
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 Jul 2004 09:51:46 -0600
To: EKR <ekr@rtfm.com>
Subject: Re: Using crypto against Phishing, Spoofing and Spamming...
Cc: Ian Grigg <iang@xxxxxxxx>, Florian Weimer <fw@xxxxxxxx>,
cryptography@xxxxxxxx
At 05:55 PM 7/17/2004, Eric Rescorla wrote:
Now, my threat model mostly includes (1), does not really include
(3), and I'm careful not to do things that leave me susceptible
to (2), so SSL does in fact protect against the attacks in my
threat model. I know a number of other people with similar threat
models. Accordingly, I think the claim that "secure browsing
is not secure" rather overstates the case.
there sort of two parts of SSL .... I believe the original
justification was based on perceived integrity issues with the domain
name infrastructure and various kinds of hijacking attacks. the client
got back a certificate, verified the integrity of the certificate
(from a table of certificate authority public keys), verified that it
appeared to originate from the certificate owner and then compared the
certificate domain name string with the domain name used in the
URL. once that was done, there was key-exchange to protect the
contents of the transmission.
the catch-22 was that the domain name infrastructure is also the
authoritative agency as to the owner of the domain name. the SSL
domain name certification authorities have this horrendously, error
prone and expensive problem of getting sufficient identification
information from the certificate applicant and attempting to match it
with the identification information carried by the domain name
infrastructure as to the owner of the domain name.
so the first issue is that the integrity of the domain name
infrastructure could be attacked with a domain name hijack ... then
the attacker applies for a certificate .... and the identification
provided the certification authority and the identification on file
with the domain name infrastructure compare ... and the attacker gets
a valid certificate.
so the certification authorities came up with a proposal to have
domain name registers .... also supply a public key at the time of
registration. then future communication with the domain name owner is
digital signed ... which the domain name infrastructure can verify
with the public key on file. this is a countermeasure against domain
name hijacking (improving the integrity of the domain name
infrastructure and rising the trust that certification authorities can
place in the authoritative agency). the other issue is that the
certification authorities can use the public key on file with the
domain name infrastructure to turn an expensive, and error-prone
identification process into a much simpler and KISS authentication
process .... aka domain name certificate applicants digitally sign
their requests ... which are then verified with the public key on file
at the domain name infrastructure.
the two issues then are that with increased domain name infrastructure
trust ... 1) it should reduce the demand for domain name SSL
certificates (motivated by integrity concerns about the domain name
infrastructure) and 2) it could eliminate the need for domain name SSL
certificates .... since all clients could possibly also use the public
keys on file with the domain name infrastructure (in lieu of needing
to get public keys from certificates).
So now to the key-exchange issue protecting credit-card numbers from
evesdropping and harvesting. The issue is that the crooks tend to go
after the best fraud ROI (return on investment). The claim is that it
is so much more profitable to harvest the merchant transaction file
.... that until that barn door is closed .... the crooks have little
incentive to go after credit card numbers by evesdropping packets in
flight. There have been some assertions that there has been no known
cases of picking up account numbers from packet evesdropping .... even
where SSL or any other encryption is being used to protect data
in-flight. Part of the issue is that evesdropping packets takes a lot
more work ... and provides much less return than going after the
merchant transaction file. Other scenarios have also been end-point
attacks ... where password files are harvested and/or viruses are
installed at end-points to harvest information .... as opposed to
doing anything with data in-flight.
So, it could be claimed that there is some question about what is
cause and what is effect i.e. are the end-point attacks because
everything is encrypted .... or are the end-point attacks occurring
because they are so much more profitable and easier. Given that there
are significant amounts of non-encrypted traffic ... then the claim
could be made that the crooks are getting so much more from end-point
attacks ... and until that is addressed ... that attacks on data in
flight is somewhat academic (since there is so little evidence about
fraud happening from data in flight attacks). The other argument has
traditional been that 90 percent of fraud has been insiders, typically
also associated with various kinds of end-point attacks (rather than
any kind of outsider attack on data in flight). There was some recent
study that at least 77 percent of the identity theft has involved
insiders. This would also indicate that the end-points are the primary
points of attack .... and that data-in-flight attacks are of primarily
of academic interests ... not particularly contributing to fraud, even
when no encryption or protection is involved.
One might even assert that the attention paid to data-in-flight
attacks is actually counterproductive ... distracting attention from
the much more serious and significant end-point attack threats
.... which has always been the major problem.