Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next, previous
- home
- The case against directories
- Who's afraid of Mallory Wolf?
- Who's afraid of Mallory Wolf? (addenda)
- Armoring websites
- Who's afraid of Mallory Wolf?
- Who's afraid of Mallory Wolf?
- The case against directories
- Bank Float May Sink
- Labour to launch ID card - and it'll cost you £25
- "Marginot Web" (SSL, payments, etc)
- Microsoft Identity Server Prepped For Windows Server 2003
- Oasis Pushes Global E-procurement Standardization
- Tackling security threats from within
- A Trial Balloon to Ban Email?
- blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
- blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
- Payments as an answer to spam
- Payments as an answer to spam (addenda)
- Payments as an answer to spam (addenda)
- Payments as an answer to spam (addenda)
- Payments as an answer to spam (addenda)
- Financial Privacy To Take The Floor
- Identity Theft Losses Expected to Hit $2 Trillion by 2005
- Maybe It's Snake Oil All the Way Down
- Microsoft Ties Security to Verisign
- OASIS and RosettaNet Set Standards Alliance
- Maybe It's Snake Oil All the Way Down
- Maybe It's Snake Oil All the Way Down
- Maybe It's Snake Oil All the Way Down
- Maybe It's Snake Oil All the Way Down
- Maybe It's Snake Oil All the Way Down
- Maybe It's Snake Oil All the Way Down
- An attack on paypal
- An attack on paypal
- virus attack on banks (was attack on paypal)
- The real problem that https has conspicuously failed to fix
- An attack on paypal
- Keyservers and Spam
- An attack on paypal (trivia addenda)
- An attack on paypal
- The real problem that https has conspicuously failed to fix
- certificates & the alternative view
- An attack on paypal
- PKI "not working"
- PKI "not working"
- Keyservers and Spam
- An attack on paypal
- UK: PKI "not working"
- basic question: semantics of "map", "tie", etc in PKI
- replay & integrity
- E-banking is board-level Issue, Says Basel Committee
- Feds, industry warn of spike in ID theft scams
- Committee calls for better e-banking security management
- IT Managers Critical Front in War on Identity Theft
- Draft E-Authentication Policy for Federal Agencies
- The Best ID Plan? Wait and See
- IT Security to be added to FAR
- Kinko's spy case: Risks of renting PC's
The case against directories
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/23/2003 12:16 PM
To: David Chadwick <d.w.chadwick@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
epay@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: The case against directories
ref:
https://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories
we've had some long term experience in this. the kerberos reference
.... was from one of the audit visits that my wife and I did on
project athena .... and sitting thru an extended detailed description
of the "new" cross-domain kerberos protocol .... and various
subsequent discussons.
however, going back even further ... almost 25 years ago ... a couple
of us were sitting around friday night trying to think up ways of
getting upper management interesting in online use. one of the
compelling business uses was an online telephone directory (for some
450,000 or so employees & increasing). we had some simple
objectives .... 1) online lookup elapsed time faster than reaching for
a local site paper directory and looking it up, 2) take 2 person weeks
or less to implement, 3) take less than a half person day per month to
support, 4) in addition to existing informaiton like name, telephone
number, internal mail-stop ... allow it to grow into things like email
address.
so we started contacting various plant sites .... asking for process
that would regularly transmit the machine readable copy that they used
for producing the site's paper directory. It turned out what started
to consume the most time were discussions with the site security
officers about security classification of an online directory
.... that was only available inside the corporation ... and only
contained name and telephone number ... and was an exact duplicate of
the paper directory. Paper directories were classified internal use
only .... the security officers wanted to classify the equivalent
information (even if it was only name and telephone number) when made
available online at a significantly higher security level (even if it
was only accessible from inside the corporation).
much longer (including technical) description of the online telephone
directory effort:
https://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
note that the internal network at the time was larger than the
internet/arpanet and continued larger up thru approximately 1985.
https://www.garlic.com/~lynn/internet.htm#4 Internet (TM) and USPTO
https://www.garlic.com/~lynn/internet.htm#0 Internet and/or ARPANET
https://www.garlic.com/~lynn/internet.htm#22 internal network's 1000th node
https://www.garlic.com/~lynn/2003d.html#59 unix
totally random trivia was in the mid-80s i was told that the internal
network had over half of all link encryptors in the world.
https://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
https://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
d.w.chadwick@xxxxxxxx on 3/22/2003 7:26 am wrote:
Lynn
well said. Access controls and privacy issues apply regardless of
technologies.
David
Who's afraid of Mallory Wolf?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 24 Mar 2003 10:10:53 -0700
To: Ian Grigg <iang@xxxxxxxx>
Subject: Re: Who's afraid of Mallory Wolf?
Cc: cryptography@xxxxxxxx
At 11:10 PM 3/23/2003 -0500, Ian Grigg wrote:
Who's afraid of Mallory Wolf?
slight observations ... i've heard of no cases of credit card number
intercepted on the internet "in flight" (requiring crypto) ... and no
known cases of MITM attack (requiring certificates)
However there have been some cases of impersonation ... being directed
to a counterfeit web-site. I know of no cases of that being done with
DNS cache poisoning ... which is also what certificates are targeted
at ... both MITM and other impersonations of various kind. the ones
i'm aware of is that the person clicks on some URL and goes to that
site .... which is a counterfeit website. This isn't caught by SSL
... since it just compares the domain name in the URL against the
domain name in the certificate presented by the server. Since the
subterfuge happens well before any DNS cache is involved ... the SSL
check of matching domain names doesn't catch anything. There have also
been various impersonation involving frames and other screen painting
techniques.
There have been cache poisonings (ip-address take over) ... there have
been also incidents in the press of domain name hijacking ... sending
updates to domain name infrastructure convincing them that somebody
else is the new domain name owner. getting a new certificate as the
new domain name owner is also a way of subverting the SSL check of
matching domain names.
https://www.garlic.com/~lynn/aepay4.htm#dnsinteg1
https://www.garlic.com/~lynn/aepay4.htm#dnsinteg2
people registering public keys at the same time they register domain names was one of the suggested countermeasures to domain name hijacking.
There was another press thing last week regarding DNS attacks. The
issue raised by the DNS attack last fall and the latest warning is
that these have the potential to bring the internet to a halt.
http://www.computerworld.com/securitytopics/security/story/0,10801,79576,00.html
so there is some effort regarding dns integrity because of its
critical importance for just having internet function at all.
past dns attack refs:
https://www.garlic.com/~lynn/2003.html#49
also
http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,75564,00.html
http://www.zdnetindia.com/news/commentary/stories/73781.html
http://www.zdnetindia.com/print.html?iElementId=73777
from a cost of business standpoint ... i've suggested why not use the
existing DNS infrastructure to distribute server public keys in the
same way they distribute ip-address (they are pieces of information
bound to the domain name, a function of the domain name
infrastructure).... and are capable of distributing other things
... like administrative & technical contacts .... although that is
getting restricted ... some bleed over from pkix
https://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories
https://www.garlic.com/~lynn/aadsm14.htm#0 The case against directories
they could be naked public keys ... which would also be subject to DNS
cache poisoning ... or they could be "signed" public keys
.... doesn't need all the baggage of x509 certs ... can just be really
simple signed public key.
Slightly related to the above posting about long ago and far away
.... when looking at allowing people (20 plus years ago) on business
trips to use portable terminals/PCs to dial in and access the internal
network/email .... a vulnerability assesement found that one of the
highest problem areas was hotel PBXs. as a result a special 2400 baud
encrypting modem was created. encrypting modem anecdote from the
time:
https://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
... these weren't in any related to the link encryptors from the
previous reference (aka supposedly over half of the link encryptors in
the world were installed on the internal network).
in any case, there was a big concern about numerous kinds of
evesdropping ... requiring encryption for information hiding. however,
the current internet credit card scenario seems to be that it is so
much easier to harvest a whole merchant file with tens or hundreds of
thousands of numbers ... than trying to get them one or two at a time
off some internet connection.
note that the x9.59 approach has always been to remove the credit card
numbers as a point of attack (form of shared-secret) by requiring all
transactions to be authenticated. as a result, just knowing the number
isn't sufficient for fraud (countermeasure against all account number
harvesting .... regardless of the technique and whether insider or
outsider attack):
https://www.garlic.com/~lynn/x959.html#x959
the low-hanging fruit theory is that if merchant sites were armored
then there could be more interest in evesdropping-based harvesting
... (leading to more demand for internet encryption). However.
armoring merchant sites is difficult since 1) there are potentially
millions, 2) human mistake is frequent/common vulnerability, 3) still
leaves insiders as threat.
other parts of security proportional to risk thread:
https://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#24 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#25 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#28 Security Proportional to Risk (was: IBM Mainframe at home)
Who's afraid of Mallory Wolf? (addenda)
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 24 Mar 2003 10:21:47 -0700
To: Ian Grigg <iang@xxxxxxxx>
Subject: Re: Who's afraid of Mallory Wolf? (addenda)
Cc: cryptography@xxxxxxxx
.... and while I don't know of any internet-based evesdropping for
account number harvesting .... there are numerous reports of skimming
in the physical world .... harvesting of account numbers by all sorts
of techniques. These include things like video cameras by crooks
trained on various kinds of POS and other terminals.
misc. skimming references:
https://www.garlic.com/~lynn/aadsm12.htm#40 In Brief: Anti-'Skimming' Guidelines Coming
https://www.garlic.com/~lynn/aadsm12.htm#57 eBay Customers Targetted by Credit Card Scam
https://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
https://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
https://www.garlic.com/~lynn/aadsm6.htm#pcards3 The end of P-Cards? (addenda)
https://www.garlic.com/~lynn/aepay10.htm#3 High-tech Thieves Snatch Data From ATMs (including PINs)
https://www.garlic.com/~lynn/aepay10.htm#41 ATM Scams - Whose Liability Is It, Anyway?
https://www.garlic.com/~lynn/aepay10.htm#44 Credit Card Skimming Rising In The US
https://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
https://www.garlic.com/~lynn/aepay9.htm#skim High-tech Thieves Snatch Data From ATMs (including PINs)
https://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
https://www.garlic.com/~lynn/2002i.html#74 A Lesson In Security
https://www.garlic.com/~lynn/2002j.html#60 How to map a user account to a digital cert?
https://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates
https://www.garlic.com/~lynn/2002l.html#20 Backdoor in AES ?
https://www.garlic.com/~lynn/2002m.html#36 (OT) acceptance of technology, was: Convenient and secure
Armoring websites
Refed: **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 24 Mar 2003 12:29:17 -0700
To: Ian Grigg <iang@xxxxxxxx>
Subject: Armoring websites
Cc: cryptography@xxxxxxxx, epay@xxxxxxxx
ref:
https://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#2 Who's afraid of Mallory Wolf? (addenda)
here is discussion of armoring websites with respect to security
proportional to what is at risk
https://www.garlic.com/~lynn/2001h.html#61 net banking, is it safe???
https://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk
random refs to hardened sites:
https://www.garlic.com/~lynn/aadsm2.htm#risk another characteristic of online validation.
https://www.garlic.com/~lynn/2001.html#33 Where do the filesystem and RAID system belong?
https://www.garlic.com/~lynn/2002.html#44 Calculating a Gigalapse
https://www.garlic.com/~lynn/2002m.html#5 Dumb Question - Hardend Site ?
https://www.garlic.com/~lynn/2002m.html#6 Dumb Question - Hardend Site ?
https://www.garlic.com/~lynn/2002o.html#14 Home mainframes
https://www.garlic.com/~lynn/2003c.html#52 diffence between itanium and alpha
Who's afraid of Mallory Wolf?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 24 Mar 2003 17:50:17 -0700
To: daw@xxxxxxxx (David Wagner)
Subject: Re: Who's afraid of Mallory Wolf?
Cc: cryptography@xxxxxxxx
At 10:02 PM 3/24/2003 +0000, David Wagner wrote:
You could take your argument even further and ask whether any crypto
was needed at all. After all, most attacks have worked by
compromising the endpoint, not by sniffing network traffic. I'll let
you decide whether to count this as a success story for SSL, or as
indication that the crypto wasn't needed in the first place. (I'm a
little skeptical of this argument, by the way, but hey, if we're
playing devil's advocate, why not aim high?)
I assert that there may be more sites that transmit credit card
numbers w/o crypto, as sites that use SSL (although transaction rates
are highly skewed so they even if it were ten times the number of
sites, it might represent fewer actual transmissions). I don't have
actual numbers, but I am aware of significant number of
sites. However, I would contend that harvesting numbers from end-point
merchant files has significantly higher return (ROI, expected results
for the effort) than any sort of network evesdropping ... and that it
is practically impossible to provide the necessary armoring as
countermeasure for this vulnerability; end point attacks by either
insider and outsider (historically, insider attacks on financial
infrastructure have represented vast majority of incidents. While it
may be possible to do a single armored site .... it isn't practical to
do a million such sites (for one thing, people make too many mistakes)
... as per previous ref to security proportional to risk (and the
merchant file risk is proportional to the credit limits of the
accounts, not the specific merchant transaction).
I would expect that network evesdropping would be employed where
vulnerability was something other than kind of fraud do'able by
attacking the end-point merchant file. Note however, skimming (various
kinds of electronic & non-electronic recording) does go on in the
physical world. Part of the issue may be that the target object
(account number) has much lower occurance in general internet traffic
(physical world skimming involves traffic that is almost solely
account numbers). If you just have to skim, there are some number of
points that are much more target rich environments (better fraud ROI)
than internet traffic.
There is some phrase that if the only thing you know how to use is a
hammer, then every solution may involve a nail.
The fundamental problem with account numbers is that they are
effectively a kind of shared-secret .... acquiring/harvesting the
numbers enables fraud. There are significant number of business
processes that require the availability of the account numbers. This
is one of the reasons for the end-point merchant files and also why
"SET" (with significantly more complex crypto infrastructure and
essentially only, also addressing data in-flight) offered very little
additional over what my wife and I were involved with setting up the
original SSL for e-commerce.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
The point of x9.59 wasn't to add even more layers of crypto and
information hiding to protect these shared-secrets .... but to change
the business model so that the account numbers were no longer
shared-secrets. X9.59 uses simple digital signature for authenticated
payment transactions and a business rule that account numbers used in
x9.59 transactions can't be used in non-authenticated payment
transactions.
https://www.garlic.com/~lynn/x959.html#x959
aka just by evesdropping an x9.59 transactions or harvesting account
numbers used in x9.59 transactions doesn't enable a crook to initiate
a fraudulent payment transaction.
Who's afraid of Mallory Wolf?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 25 Mar 2003 15:32:00 -0700
To: bear <bear@xxxxxxxx>
Subject: Re: Who's afraid of Mallory Wolf?
Cc: Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
At 12:09 PM 3/25/2003 -0800, bear wrote:
ISP's don't want to support encrypted links
because it raises their CPU costs. And mail
clients generally aren't intelligently designed
to handle encrypted email which the mail servers
could just "pass through without decrypting and
encrypting".
circa '95 .... there were comments that ISP's didn't want to verify
from/spoofed packet addresses on DHCP modem connections because it
increased their router cpu costs (actually one of the most common
routers didn't have enuf processor power to implement even trivial
packet filtering on modem lines).
https://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
now there is the observation in this thread (or the previous thread)
that many websites use SSL very sparingly because it cuts their web
traffic capacity by 80-90 percent (http vis-a-vis https given the same
hardware).
Typical sequence is that person clicks-on/types something and goes to
a site with straight HTTP, they shop for a while ... until they are
ready to check-out, they then click on the "check-out" button. That
button supplies a URL that sends them off to a HTTPS site (aka the
user didn't actually originated the HTTPS url) ... where all the
payment information is provided. Now since the client/consumer never
provided the actual HTTPS sequence .... but it was provided for them
by a webpage at the HTTP site they were shopping at .... it is
presumably trivial for the HTTP site that they are shopping at to make
sure that the HTTPS URL domain that clients are sent to .... matches
the certificate domain at that site (and a lot of shopping URLs have a
lot of appended history so that it is relatively easily contrived that
the consumer doesn't notice the domain name of the "check-out/payment"
page).
A lot of the requirement for encryption is end-to-end ... or at least
VPN-like .... so encrypted packets should mostly be transparent to
operations in their ISP roles. This isn't as true on the web-hosting
side of the house ... where SSL or similar encryption activity can
represent significant additional CPU processing load.
The case against directories
From: Lynn Wheeler
Date: 03/28/2003 08:34 AM
To: Peter Gietz <Peter.Gietz@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
ietf-pkix@xxxxxxxx, owner-ietf-pkix@xxxxxxxx
Subject: Re: The case against directories
the one detailed implementation presentation I've seen on a SAML based
product .... looked exactly like Kerberos .... but the transmissions
were SAML-encoded (and carried authorizations in addition to
authentication)
misc kerberos
https://www.garlic.com/~lynn/subpubkey.html#kerberos
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
peter.gietz@xxxxxxxx on 3/28/2003 4:55 am wrote:
> Using authentication systems like OASIS' SAML, organizations can
> (through their employees), authenticate to each others' intranets and
> through this get access to exactly the information they should have
> and in a format that make sense. The latter may be a directory tree,
> a PDF-file, a database listing, an HTML form, etc.
>
> Unlike directory systems, SAML allows secure access to any kind
> of active or passive information source, including purchasing and
> work-flow systems.
SAML is a good but complex means for communicating
authorizations ans assertions, it is not a whole middleware
infrastructure.
Bank Float May Sink
Refed: **, - **, - **
From: Lynn Wheeler
Date: 03/31/2003 12:27 PM
To: Alanslater@xxxxxxxx
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Bank Float May Sink
the reference was not between technology issues of substitute checks
and e-check .... the reference was to some common business issues
regarding float (as in the subject line). there were two specific
processing implementations for e-check done by two different
organizations. one of the organizations chose a specific
implementation because it had more float than the other implementation
(and there was lots of business discussion of float with regard to
e-echeck) ... it appeared that lots of the business people seemed to
believed that the business issues of float by far dominated numerous
different technical implementations.
somewhat related is that the ACH networks tend to perform settlement
of some amount of check related funds (fedwire tends to handle higher
value settlement). however the aads nacha trials:
https://www.garlic.com/~lynn/x959.html#aads
used the ATM debit network providing real-time authorization.
there is some comparison with canada which is now doing ACH settlement
twice a day .... eliminating some amount of float in the ACH network
(however, canada has much fewer participants that need to be
synchronized).
random past discussion of float
https://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash
https://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
https://www.garlic.com/~lynn/aadsm6.htm#echeck Electronic Checks
https://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
alanslater@xxxxxxxx on 3/31/2003 8:55 arm wrote:
Lynn --
It would be incorrect to associate Substitute Checks in any way with
the FSTC e-check project. Several years ago, I created the concept of
Substitute Checks as a way to overcome the obstacles the industry
faced in implementing truncation projects. On the surface, the
concept is anti-intuitiive and defies logic (we're in the process of
solving the problem that it was also illegal) -- but it works.
Simply put, the concept allows an entity to digitize the image of a
check, place that digitized image into the payments system and then,
most importantly, gives the paying bank the option of accepting the
digital image or re-creating a paper copy, including MICR, for
payment. The Check Clearing for the 21st Century Act gives the same
legal standing to the digital image or re-created paper copy as the
original paper copy now has.
There are profound implications for this. Reduction in float is one
of the minor benefits. There are significant benefits that accrue to
consumers, banks and businesses from substitute checks. Consider the
benefits to consumers if the checks they deposit at an ATM are
digitized. Since banks no longer have to physically pick up checks
daily during very tight timeframes, checks deposited up to say 7pm
could be processed the same day (currently many banks use a noon
cutoff). This would make the funds from the deposited checks
available a business day sooner and would earn them additional
interest. Banks could accept deposits for other banks thereby
providing the other banks customers additional time-place convenience
without increasing in fact decreasing the other bank's risk of
returned checks. Merchants could be empowered and paid to accept
deposits further increasing consumer convenience.
With digitized images, banks could verify signatures and look for
signs of fraud at the time of deposit and make decisions about
availability on the spot.
Post offices could be used to create the digital images of payments
thereby eliminating physically moving the mail in addition to
physically moving the paper check.
For overseas payments, US checks become readily accepted payment
vehicles because the foreign countries can present these checks
electronically as if they had an office in the US down the block from
the paying bank.
I can go on for a long time about the benefits of this type of payment
but I'll end it here. However, if you have any ideas about how we
should handle checks presented in Hong Kong at 9 a.m. local time which
are presented in the U.S. on the day before they were written, I'd
like to know.
Regards,
Alan
Labour to launch ID card - and it'll cost you £25
From: Lynn Wheeler
Date: 04/20/2003 04:41 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Labour to launch ID card - and it'll cost you £25
http://news.telegraph.co.uk/core/Content/displayPrintable.jhtml?xml=/news/2003/04/20/nid20.xml&site=5
Labour to launch ID card - and it'll cost you £25
By Colin Brown and Francis Elliott
(Filed: 20/04/2003)
Everyone in Britain will have to pay around £25 for a compulsory
identity card under proposals being put to the cabinet by David
Blunkett, the Home Secretary.
The "smart" card will identify the holder using iris-recognition
technology. Failure to carry the card will not be an offence but
police will be able to order people to present it at a police station.
The charge is aimed at overcoming resistance to the scheme from the
Treasury. Until now Cabinet support for a national compulsory identity
card has been outweighed by the Treasury, which has objected to
footing the estimated £1.6 billion bill.
... snip ...
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
"Marginot Web" (SSL, payments, etc)
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/20/2003 05:01 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: "Marginot Web" (SSL, payments, etc)
note that x9.59 addresses many of the payment transaction issues,
however various social engineering vulnerabilities can still exist.
article:
http://www.iang.org/ssl/maginot_web.html
from above:
[4] This has been going on for a long time in the e-gold community,
but now seems to have crossed over to credit cards
New way to steal password. A Discover credit card customer receives an
e-mail telling him that his account is on hold due to inactivity, and
that in order to reactivate his account, he must log in to this phony
Web site. The information collected includes plenty of data that would
enable identity theft Social Security number, mother's maiden name,
account number, and passwords. Similar scams have targeted PayPal and
eBay customers.
http://www.msnbc.com/news/884810.asp
http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,79380,00.html
http://tinyurl.com/7mgh
...........
the above referenced article includes references to the following
threads/postings
https://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
https://www.garlic.com/~lynn/aadsm13.htm#27 How effective is open source crypto?
https://www.garlic.com/~lynn/aadsm13.htm#28 How effective is open source crypto? (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#29 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#30 How effective is open source crypto? (aads addenda)
https://www.garlic.com/~lynn/aadsm13.htm#31 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#33 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#34 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#36 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#37 How effective is open source crypto?
https://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#2 Who's afraid of Mallory Wolf? (addenda)
https://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#5 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
Microsoft Identity Server Prepped For Windows Server 2003
From: Lynn Wheeler
Date: 04/29/2003 04:41 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Microsoft Identity Server Prepped For Windows Server 2003
http://www.internetweek.com/breakingNews/showArticle.jhtml;jsessionid=XOGY0QCHI1VBQQSNDBCCKH0CJUMEYJVN?articleID=9400091
Microsoft Identity Server Prepped For Windows Server 2003
By Paula Rooney, CRN
San Francisco -- Microsoft is turning its attention to the identity
management space.
To that end, the software giant is preparing to launch the Microsoft
Identity Server, formerly referred to as Microsoft MetaDirectory
Services 2003, said Bill Veghte, corporate vice president of
Microsoft's Windows Server Group.
... snip ...
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
Oasis Pushes Global E-procurement Standardization
From: Lynn Wheeler
Date: 04/29/2003 04:43 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Oasis Pushes Global E-procurement Standardization
http://www.internetnews.com/dev-news/article.php/2197641
April 28, 2003
Oasis Pushes Global E-procurement Standardization
By Mark Leon
The Organization for the Advancement of Structured Information
Standards (OASIS) consortium has created a forum for government
agencies, organizations, and private companies to work together on
global e-procurement standards.
The new Electronic Procurement Standardization (EPS) Technical
Committee will analyze requirements, identify gaps, and make
recommendations for improving the interoperability of XML, internet
based e- procurement systems.
... snip ...
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
Tackling security threats from within
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 04/29/2003 04:46 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Tackling security threats from within
note some amount of following is about identity theft (by insiders)
and identity management (as a security paradigm/coutermeasure).
http://www.infoworld.com/article/03/04/25/17FEinjob_1.html
Tackling security threats from within
Bolstering your company's security system provides protection against
the enemy within
By David L. Margulius
April 25, 2003
A University of Texas student steals 55,000 Social Security numbers
from the school's administrative databases. A UBS Pain Webber system
administrator activates a logic bomb in the company's network, causing
$3 million in damage. A disgruntled Australian IT employee commandeers
his company's sewage management software to dump millions of gallons
of raw sewage into local parks and rivers.
... snip ...
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
A Trial Balloon to Ban Email?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Adam Back <adam@xxxxxxxx>
Subject: Re: A Trial Balloon to Ban Email?
Cc: cypherpunks@xxxxxxxx, cryptography@xxxxxxxx, lauren@xxxxxxxx, Adam Back <adam@xxxxxxxx>
the proposal in the past has been that ISPs filter spam at ingress
from their customers. the counter-argument has been that there are
lots of ISPs that can't be trusted to do it.
So it is much easier for ISPs to have lists of other trusted &/or
untrusted ISPs that they will accept email from.
It is orders of magnitude easier (and more efficient) for ISPs to do
ingress filtering for SPAM and effectively ISP blacklists than it is
to populate the whole consumer infrastructure.
There are still some ways to slip thru the cracks with small amounts
.... but it isn't the 40-80% volume of all email that is seen today.
It does have an analogous downside to the individual privacy issues
... which are that the big ISPs could use blacklisting for other
purposes than addressing SPAM issues.
Some of the ingress filtering pushback may be similar to the early
counter-arguments for packet ingress filtering related to ip-address
spoofing. however, that seemed to be more a case of disparity among
the router vendors in which could & could not implement ingress
filtering. as majority of the router vendors achieved such capability
... the push-back significantly reduced.
https://www.garlic.com/~lynn/rfcidx7.htm#2267
2267 -
Network Ingress Filtering: Defeating Denial of Service Attacks which
employ IP Source Address Spoofing, Ferguson P., Senie D., 1998/01/23
(10pp) (.txt=21032) (Obsoleted by 2827)
there already are logs relating ingress email to originating ISP
customer id. that could be made available via some sort of legal
action. the only issue then is the strength of authentication that is
performed on customer connection to the ISP ... rather than some sort
of origin authentication for every email.
At 03:40 AM 5/9/2003 +0100, Adam Back wrote:
Yes, there is some discussion of it on slashdot, including several
other people who have commented similarly to anonymous that it is a
pretty big privacy invasion and centralised control point problem.
The claim that you can optionally be anonymous and not use a cert, or
get an anonymous cert is plainly practically bogus. You'd stand about
as much chance of having your mail read as if you shared mail hub with
spamford wallace -- ie 90+% of internet mail infrastructure would drop
your mail on the floor on the presumption it was spam.
Plus a point I made in that thread is that it is often not in the
internet user's interests to non-repudiably sign every message they
send just to be able to send mail because that lends amunition to
hostile recipients who from time-to-time target internet users for
bullshit libel and unauthorised investment advice etc.
Companies also are I would expect somewhat sensitive to not signing
everything for similar reasons as those behind their retention
policies where they have policies of deleteing emails, files and
shredding paper files after some period.
In addition PKIs because of the infrastructure requirements have
probem complex to setup and administer. So now we've taken one hard
problem (stopping spam) and added another hard problem (hierarchical
PKI deployment) and somehow this is supposed to be effective at
stopping spam.
In addition unless there is significant financial cost for
certificates and/or signifcant and enforceable financial penalty and
good identification and registration procedures enforced by the CAs it
wouldn't even slow spammers who would just get a cert, spam, get
revoked, get another cert and repeat.
Certificate revocation is already a weak point of PKI technology, and
to reasonably stop spam before the spammer manages to send too many
millions of spams with a cert, you have to revoke the cert PDQ!
And finally it all ends up being no more than an expensive
implementation of blacklists (or I suppose more properly whitelists),
because the CAs are maintaining lists of people who have not yet been
revoked as spammers. Some click through agreement isn't going to stop
spammers. Legislation or legal or financial threat is going to stop
spammers either because any level of registration time identity
verification that is plausibly going to be accepted by users, and this
is also limited by the cost -- higher assurance is more cost which
users also won't be willing to accept -- will be too easy for the
spammers to fake. And email is international and laws are not.
It is pretty much an "internet drivers license" for email.
I also think that fully distributed systems such as hashcash are more
suitable for a global internet service. My preferred method for
deploying hashcash is as a token exempting it's sender from bayesian
filtering, and any other content based or sender based filtering.
That way as an email user you have an incentive to install a hashcash
plugin
http://www.cypherspace.org/hashcash/
because it will ensure your mail does not get deleted by ever-more aggressive filtering and
scattergun blackhole systems. The camram system
http://www.camram.org/ is a variant of this.
It also more directly addresses the problem: it makes it more
expensive for spammers to send the volumes of mail they need to to
break even.
Adam
On Fri, May 09, 2003 at 03:50:02AM +0200, Nomen Nescio wrote:
> Lauren Weinstein, founder of People for Internet Responsibility, has
> come out with a new spam solution at http://www.pfir.org/tripoli-overview.
>
> According to this proposal, the Internet email architecture would be
> revamped. Each piece of mail would include a PIT, a Payload Identity
> Token, emphasis on Identity. This would be a token certifying that you
> were an Authorized Email User as judged by the authorities. Based on
> your PIT, the receiving email software could decide to reject your
> email.
>
> It is anticipated that all Pits considered acceptable by the vast
> majority of all Tripoli-compliant software user would be digitally
> signed by one or more designated, trustworthy, third-pary authorities
> who would be delegated the power to certify the validity of identity
> and other relevant information within Pits.
>
> In other words, here comes Verisign again.
>
> It is anticipated that in most cases, in order for the sender of an
> e-mail message to become initially certified by a Pit Certification
> Authority (PCA), the sender would need to first formally accept
> Terms of Service (ToS) that may well prohibit the sending of spam,
> and equally importantly, would authorize the certification authority
> to "downgrade" the sender's authentication certification in the case
> of spam or other ToS violations.
>
> Thus you have to be politically acceptable to the Powers That Be in
> order to receive your license to email, aka your PIT. And be careful
> what you say or your PIT will be downgraded.
>
> Unfortunately he doesn't discuss various crypto protocol issues:
>
> If the PIT is just a datum, what keeps someone from stealing your PIT
> and spams with it?
>
> If the PIT is a cert on a key, what do you sign? The message? What if
> it gets munged in transit, as messages do? You've just lost most of
> your email reliability.
>
> Or maybe you sign the current date/time? Then delayed mail is dead mail.
>
> Or maybe you respond to a challenge and sign that? That won't work if
> relays are involved, because they can't sign for you.
>
> Spam is a problem, but it's no excuse to add more centralized
> administrative control to the Internet. Far better to go with a
> decentralized solution like camram.sourceforge.net, basically a matter
> of looking for hashcash in the mail headers. This raises the cost to
> spammers without significantly impacting normal users.
>
blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
Date: Fri, 09 May 2003 23:35:36 -0600
To: Adam Back <adam@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>, cypherpunks@xxxxxxxx, cryptography@xxxxxxxx, lauren@xxxxxxxx, Adam Back <adam@xxxxxxxx>
Currently ISPs typically "notice" when they get complaints. ISPs could
do a much better job of actively noticing and limiting mail at ingress
... as opposed to waiting for somebody to complain and canceling the
account. Many of the recent statements about ISPs can't limit email at
ingress dynamically are similar to the comments about not being able
to filter ingress packets if their origin address didn't match the ip
address of the sender (as stated in the original posting) ... per the
ingress packet filtering RFC referenced in the original post.
My original post mentioned that the ISPs could then do their own
effort of blacklisting (of other ISPs). Currently spam blacklists can
be somewhat like vigilantes .... with the argument analogy that since
vigilantly justice can make mistakes then there shouldn't be any
highway patrol, FBI, and/or secret service. ISPs would be expected to
filter on ingress of email from their own customers .... and even if
the 10 top ISPs blacklisted other ISPs that didn't do a reasonable job
of ingress filtering ... it could start to put a big dent in the
spamming business, possibly cutting it from 40-80% of existing email
down under 5-10%. It is sort of like stop signs and stop lights
.... there are typically hundreds of more intersections than there are
traffic enforcers .... however with sufficient leverage ... it can
significantly improve the situation ... even if it can be proved that
it can't, absolutely, 100% guarantee one hundred percent compliance.
I didn't make any statement about ISPs attempting to identify spammers
when they register the account .... the original post was only with
regard to ISPs doing active email ingress filtering. My ISP recognizes
and bills me extra if I'm simultaneously connected multiple times
... there is a little latitude for modem hanging, my dropping the line
... but the modem not reporting it ... and my connecting on a
different modem. It also does traffic load-leveling if I really try
and hit it hard. If it can bill extra for simultaneous connects and
traffic load leveling, it can do both packet ingress filtering and
email ingress filtering.
past thread drawing the analogy that the information superhighway is
something like the wild west .... w/o traffic rules, traffic signs,
traffic lights, speed limits, and enforcement. start with a couple
hundred people in town .... and went to millions ... and there still
isn't even any rule about which side of the road people should be
driving on.
https://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
At 06:02 AM 5/10/2003 +0100, Adam Back wrote:
On Fri, May 09, 2003 at 10:11:52AM -0600, Anne & Lynn Wheeler wrote:
> So it is much easier for ISPs to have lists of other trusted &/or
> untrusted ISPs that they will accept email from.
Any internet user needs to be able to send mail to any other internet
user. Which means the default has to be open (blacklists rather than
whitelists). Then you have the blackhole lists like ORBs etc, which
block domains used predominantly by spammers. But the problem is
spammers don't stay in one place, they buy service from ISPs and spam
flat-out until the ISP notices and cancels the account. Some ISPs are
more grey -- they want to make money from spammers by providing them
service, and some ISPs just don't notice or respond that quickly. The
ISP can't distinguish spammers from non-spammers when they receive
customer orders. The blackhole people are arbitrary vigilantes by and
large, so the overall effect you might argue does reduce spam, but it
also results in lost mail.
My experience was I couldn't get mail from my brother who was using
btinternet, one of the largest ISPs in the UK because some idiot
blackholer blackholed their dynamic IPs. Not doubt there were at some
time some spammers using BTinternet as with just about any other ISP.
Recently I couldn't receive mail from John Gilmore, and so it goes.
So I don't see how this is a "solution", rather it is just a broken
countermeasure with scatter gun fall-out of false positives for all
the other people who find themselves sharing the same ISP as spammers
long enough for the blackhole people to add them.
Adam
blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
Date: Sat, 10 May 2003 09:36:43 -0600
To: Adam Back <adam@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>, cypherpunks@xxxxxxxx, cryptography@xxxxxxxx, lauren@xxxxxxxx, Adam Back <adam@xxxxxxxx>
do you think that earthlink would automatically blacklist aol if it
found incoming spam from aol? I think that earthlink would contact aol
and say ... your ingress filtering doesn't seem to be working. It
would only be after all attempts to understand aol's ingress filtering
that earthlink might take action.
again ... it is analogous to somebody hearing about traffic lights for
the first time and coming up with all the reasons why people would
ignore traffic lights.
I would claim that the current issue isn't that spam exists (aka
traffic violations), it is that there are billions of spams each
day. and that this easily cuts the majority of it if the top ten start
doing ingress mail filtering and that ingress mail filtering is orders
of magnitude more efficient than other kinds of solutions.
the blacklisting isn't for the mistakes ... it is for the ISPs that
obviously aren't going to follow the traffic rules.
so there are lots of kinds of tunneling. the major ISPs are already
doing ingress filtering for email not coming from a recognizable
customer. so tunneling actually reduces to a common vulnerability with
ISPs not doing ingress email filtering (aka the tunneling issue to a
ISP that isn't doing ingress email filtering is common vulnerability
with a customer directly getting an email account with ISP that isn't
doing ingress email filtering). So the issue comes back to ISPs that
are recognized as not doing ingress email filtering.
So lets say this gets something like 80 percent of the traffic
violations.
So the majority of the random traffic violations are now starting to
be taken care of. There are 1) the corporations effectively operating
as private ISPs, 2) compromised machines, 3) random anarchy.
So both #2 and #3 are vulnerabilities treated just the same as a real
spammer getting a real account and directly doing spam. These two
vulnerabilities should be caught be ingress email filtering. Real
spammers caught by ISP ingress filtering, compromised machines caught
by ISP ingress filtering, and hit&run anarchist caught by ingress
filtering .... all appear to be a common vulnerability caught by
ingress email filtering.
The issues actual reduce to a very few simple, non-complex
vulnerabilities from a business process standpoint (ignoring all the
technology twists and turns): 1) ISPs that do ingress email filtering
and 2) ISPs that do not do ingress email filtering.
If ISPs are doing ingress email filtering .... then all the situations
of known spammers, spammers masquerading enormously getting accounts,
spammers compromising other machines and masquerading enormously,
tunneling, etc ... all get taken care of. There are still the periodic
traffic accidents where somebody might be able to do a couple hundred
before getting cut .... but it probably reduces over 90 percent of the
traffic.
So the remain issue is whether an ISP is following the traffic laws
and doing ingress email filtering or flagrantly flaunting the law and
letting millions of spam thru. This is regardless of whether it is a
real public ISP ... or effectively a corporate/private ISP. The other
ISPs then use blacklisting. The first line of defense is that all ISPs
are to do ingress email filtering and the 2nd line of defense is that
the major ISPs do blacklisting on the ISPs that obviously are
flaunting the law.
The primary business issue is that majority of spam is being done for
some profit .... that the cost of sending the spam is less than the
expected financial return. This should address the 99 percentile.
Again, it is very simple, first line of defense is ingress email
filtering. This is only a moderate extension of what the major ISPs
are currently doing with regard to not accepting email from entities
that are obviously not their customers, current traffic limiting
business rules, etc. The second line of defense is blacklisting ISPs
that aren't following the traffic rules. I claim, it actually is
rather much simpler and much more effective.
So back to the obvious traffic violations. One is the compromised
machines. Large proportion of the compromised machines are their
because they all got hit by spamming virus. I claim, that over time if
over 90 percent of spamming gets cut ... then 90 percent of the
machines that get compromised by virus in spam can also get cut.
Situation is now down to large number of compromised machines each
sending couple hundred emails each ... staying under the ingress
filtering radar. That is orders of magnitude better than the current
situation but it is starting to reduce the case to manageable traffic
violations.
So this scenario gets down to providing significantly more focus on
compromised machines ... and back to a recent comment about lots of
vendors saying that consumers won't pay for better security
... because they have no motivation. This is somewhat the insurance
industry theory of improving on severity of traffic accidents (what
motivated automobile manufactury to build safer cars). My ISP
currently charges me extra over the flat rate for certain behavioral
activities. Violating ingress email filtering rules would be such a
valid inducement. I get ingress email filtering accident insurance the
premiums are based on the integrity of the machine i'm operating.
So, two simple rules .... 1) ISPs do ingress email filtering, and 2)
ISPs blacklist other ISPs that flagrantly violate the ingress email
filtering rules.
With a sizeable reduction in spam, there is corresponding sizeable
reduction in compromised machines. However, compromised machines that
do spam and hit the ISPs ingress email filtering rules, get fined. It
is treated as accident and operating an unsafe vehicle. You can get
accident and fine insurance .... but the premium is related to kind of
machine you operate. Some inducement for consuming public to purchase
safer machines. The two simple rules ... with the fines for violations
then provides some inducement for consumer buying habit regarding
purchasing safer machines. And it is all quite similar to policies and
practices currently in place.
Payments as an answer to spam
Date: Sat, 17 May 2003 08:07:35 -0600
To: "Anton Stiglic" <astiglic@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Payments as an answer to spam
Cc: <iang@xxxxxxxx>, <cryptography@xxxxxxxx>
At 11:03 AM 5/15/2003 -0400, Anton Stiglic wrote:
PODS using something à la PGP would not
imply PKI, but still a centralized server
as you said.
Payment systems don't need a PKI, but
a centralized server as you said, and
also needs some kind of financial
institution to bootstrap things (which is easier
to do in a closed system, than in an open
system like the Internet).
x9.59 standard for all elecronic payments can use digital signatures
w/o PKI or certificates ... just public key registered with account
and connectivity to senders financial institution. It isn't
"centralized" any more than the existing payment card operation is
centralized .... aka huge number of different consumer financial
institutions all with their individual operation and account
records. however, much of it is based on a private network
interconnecting all of these financial operations that predates the
existing internet ... but effectively functionally equivalent.
The existing payment card infrastructures are open in the sense thay
they do have an international standard, iso8583 .... in much the same
way that certificates have iso international standard. and there are
numerous interconnects between the internet and these infrastructure
... witness the existing electronic commerce. It is less open than the
"internet" in the sense that there are contractual, institutional, and
financial obligations that are necessary to directly participate (but
i believe that will tend to be always true except in the cases of toy
demos). However, that isn't precluding the migration of more
electronic commerce related traffic to internet-based technology in
various ways. The issue isn't directly whether it is internet-related
technology or non-internet related technology .... but much more of an
issue whether there are explicit legal and other obligations required
to participate.
x9.59 standard reference
https://www.garlic.com/~lynn/x959.html#x959
account record public key infrastructures
https://www.garlic.com/~lynn/x959.html#aads
Payments as an answer to spam (addenda)
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sat, 17 May 2003 09:21:21 -0600
To: "Anton Stiglic" <astiglic@xxxxxxxx>
Subject: Re: Payments as an answer to spam (addenda)
Cc: <iang@xxxxxxxx>, <cryptography@xxxxxxxx>
The existing payment card infrastructure (credit, debit, online
stored-value, 3rd party, etc) had used a PKI-type infrastructure prior
to about 1970, aka credential (in this case in the guise of a plastic
physical card with varioius embossing and printing) that could be used
in offline transactions, unconnected transactions.
The transition to online transactions started in the early '70s
... used an electronic end-point in the guise of magstripe added to
the existing physical credential ... while they were emboddied in the
same physical package, they represented totally different paradigms.
The existing PKI certificates are a return to the offline, pre-70s
paradigm that the existing payment card infrastructure left long
ago. The existing payment card paradigm is not only online in the
sense that it checks whether the account is still valid ... but also
checks real-time, aggregated information regarding whether there is
sufficient funds.
OCSP for PKIs is a limiting baby step into an online world with
real-time checking of whether the offline credential is still valid
.... but it doesn't actually make it into the 1970s where a stale,
static certificate is redundant and superfluous and there is direct
access to much higher quality real-time and possibly aggregated
information used for financial operations. OCSP is actually a more
timely version of the paper booklets that were distributed in the 50s
& 60s .... not an actual switch from a basically offline paradigm to
an online paradigm.
Frequently there were comments equating statements about
redundant and superfluous certificates as being a transition to a
centralized paradigm. However the issue isn't with regard to
centralized/non-centralized ... which is effectively orthogonal to the
issue regarding stale, static certificates .... it is an issue of
offline/online (not centralized/non-centralized). There is the issue
that if it is online paradigm ... it is possible to have either a
centralized or a non-centralized paradigm .... which is somewhat more
difficult to have such option in a purely offline paradigm.
random past posts on redundant and superfluous offline credentials for an online paradigm
https://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki6 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki7 CFP: PKI research worksho
https://www.garlic.com/~lynn/aadsm10.htm#limit Q: Where should do I put a max amount in a X.509v3 certificat e?
https://www.garlic.com/~lynn/aadsm10.htm#limit2 Q: Where should do I put a max amount in a X.509v3 certificate?
https://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
https://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01
https://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction?
https://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt
Payments as an answer to spam (addenda)
Date: Sat, 17 May 2003 17:56:52 -0600
To: Rich Salz <rsalz@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Payments as an answer to spam (addenda)
Cc: "cryptography@xxxxxxxx" <cryptography@xxxxxxxx>
At 07:17 PM 5/17/2003 -0400, Rich Salz wrote:
Curious.
A couple of years ago, we'd go around explaining that CRL's were the
paper booklets, and OCSP was the Verifone terminal, giving per-transactional
validity to the credentials.
I still think that makes more sense than your analogy. But then, the
company I was working for back then is now gone.
/r$
the description was that CRLs were an exact analogy of the paper
booklet, while OCSP is a more timely version of the paper booklet; aka
it is a more timely solution for an offline paradigm ... using a
little bit of online technology; but not with the actual transition
from an offline paradigm to an online paradigm.
theoretically, the payment system could have preserved the offline
paradigm and just used the online terminal to check whether the
offline credential is still valid .... however, they actually used the
online capability to actually change from an offline paradigm to an
online paradigm ... rather than using the online capability as sort of
a kludgey crutch for continuing to prop up an offline paradigm.
Payments as an answer to spam (addenda)
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sat, 17 May 2003 18:22:18 -0600
To: Rich Salz <rsalz@xxxxxxxx>
Subject: Re: Payments as an answer to spam (addenda)
Cc: "cryptography@xxxxxxxx" <cryptography@xxxxxxxx>
At 07:17 PM 5/17/2003 -0400, Rich Salz wrote:
A couple of years ago, we'd go around explaining that CRL's were the
paper booklets, and OCSP was the Verifone terminal, giving
per-transactional validity to the credentials.
I still think that makes more sense than your analogy. But then, the
company I was working for back then is now gone.
/r$
actually, i believe that my wife and I were one of the first to use
the comparison of CRLs to the paper booklets at about the same time we
coined the term certificate manufacturing to distinguish the SSL
infrastructure from a PKI (in conjunction with this thing that was to
be called electronic commerce).
some old booklet references:
https://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
https://www.garlic.com/~lynn/aepay2.htm#position AADS NWI and XML encoded X9.59 NWI
https://www.garlic.com/~lynn/aadsm2.htm#strawm4 AADS Strawman
https://www.garlic.com/~lynn/aadsm2.htm#activity AADS Activity
https://www.garlic.com/~lynn/aadsm5.htm#faith faith-based security and kinds of trust
https://www.garlic.com/~lynn/aadsm5.htm#spki3 Simple PKI
misc. certificate manufacturing refs:
https://www.garlic.com/~lynn/aadsm2.htm#scale Scale (and the SRV record)
https://www.garlic.com/~lynn/aepay2.htm#cadis disaster recovery cross-posting
https://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm5.htm#pkimort2 problem with the death of X.509 PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki6 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
--
Anne & Lynn Wheeler https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
Payments as an answer to spam (addenda)
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 May 2003 06:47:13 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
Subject: Re: Payments as an answer to spam (addenda)
Cc: rsalz@xxxxxxxx, cryptography@xxxxxxxx
At 05:50 PM 5/18/2003 +1200, Peter Gutmann wrote:
So I agree with the statement that "OCSP is actually a more timely
version of the paper booklets that were distributed in the 50s & 60s".
A real solution to the problem would follow the online authorisation
model used for financial transactions, just a straight
"Accepted/Declined" response, rather than the "Maybe/Maybe not"
silly-walk that OCSP does.
But the actual transformation from offline paradigm to online paradigm
had nothing to do with the credential. In the credential world, there
is something emboddied in the credntial that convinces the relying
party to accept or reject the operation modula a currently
valid/active credential (aka as previously outline, these credentials
are stale, static subset copy of some master information someplace,
typically kept in an account record). The transition to the online
paradigm involved asking is the payment approved, nothing to do
(directly) with the validity of any credential. The certification
authority had up-to-date information about authentication ... but also
up-to-date and aggregated information about patterns leading up to
this event. The certifying authority ... instead of commenting about
any credential ... providing yes/no regarding the transaction in the
context of real-time and aggregated information.
In fact, to the extent that any financial institution using a
certificate .... it did go thru a period of being used because of
requirement by various off-the-shelf software on the
internet. However, because of privacy and liability reasons they
aborted the contents to just an account number for a
relying-party-only certificate. However, (other than requirement to
satisfy certain off-the-shelf software), it is trivial to show that
such relying-party-only certificates are redundant and superfluous
from a business process & flow perspective.
In general, there is almost nothing that you really want to put into
some document that is going to be sprayed all over the infrastructure
for everybody to examine. The original premise for X.509 was that
there would be some information in the contents of the certificate,
that a relying-party could take a look at for the basis of making a
decision w/o requiring anything more .. like online access or
previously obtained information. Given online access and/or previously
obtained information (prior/previous business relationship) .... it is
possible to show that stale, static information embodied in a
certificate is redundant and superfluous.
random past comments on relying-party-only certificates:
https://www.garlic.com/~lynn/subpubkey.html#rpo
https://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
https://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000.html#40 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000b.html#40 general questions on SSL certificates
https://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
https://www.garlic.com/~lynn/2001c.html#56 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#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format standard
https://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
https://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#0 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2002d.html#39 PKI Implementation
https://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
https://www.garlic.com/~lynn/2002e.html#72 Digital certificate varification
https://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias
https://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
Financial Privacy To Take The Floor
From: Lynn Wheeler
Date: 05/21/2003 06:14 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Financial Privacy To Take The Floor
http://www.banktech.com/story/enews/BNK20030519S0003
Financial Privacy To Take The Floor
Ivan Schneider
May 19, 2003
Congress has a lot of banking-related legislation on its plate. But
anything that doesn't take financial privacy into consideration may
get sent right back to the kitchen.
"Financial privacy, as an issue, will affect and overshadow all other
legislative issues this year," said Michael Flood, senior analyst for
banking in the regulatory advisory services group at KPMG LLP, during
its regulatory perspectives teleconference.
The primary battleground is the Fair Credit Reporting Act, which has
pre-approved credit provisions scheduled to lapse at the start of
2004. These provisions allow banks to share loan application data and
credit bureau reports with their affiliates, provided that the
customer has been given the chance to 'opt-out.' "If it isn't
reauthorized, states can enact their own privacy legislation, which
can lead to a miasma of 50 different regulations," said Flood, who
likened the possible result to the situation faced by the insurance
industry.
... snip ...
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
Identity Theft Losses Expected to Hit $2 Trillion by 2005
From: Lynn Wheeler
Date: 05/22/2003 10:39 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Identity Theft Losses Expected to Hit $2 Trillion by 2005
http://itmanagement.earthweb.com/secu/article.php/2211101
Identity Theft Losses Expected to Hit $2 Trillion by 2005
May 22, 2003
By Sharon Gaudin
The financial damage caused by online identity theft is not only
mounting, it's exploding at a growth rate of about 300 percent a year,
according to Aberdeen Group, a Boston-based industry analyst firm.
Financial loss from identity theft is expected to reach $73.8 billion
in the United States by the end of this year -- $221.2 billion
worldwide, reports Aberdeen analysts in a study released this week.
... snip ...
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: pgut001@xxxxxxxx (Peter Gutmann)
Cc: ericm@xxxxxxxx, iang@xxxxxxxx, bill.stewart@xxxxxxxx,
cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
ekr@xxxxxxxx, rsalz@xxxxxxxx, sguthery@xxxxxxxx
Subject: Re: Maybe It's Snake Oil All the Way Down
Date: Tue, 03 Jun 2003 14:46:27 -0600
On Tue, 2003-06-03 at 07:04, Peter Gutmann wrote:
That's a red herring. It happens to use X.509 as its preferred
bit-bagging format for public keys, but that's about it. People use
self-signed certs, certs from unknown CAs [0], etc etc, and you don't
need certs at all if you don't need them, <blatant
self-promotion>I've just done an RFC draft that uses
shared-secret keys for mutual authentication of client and
server, with no need for certificates of any kind</blatant
self-promotion>, so the use of certs, and in particular a
hierarchical PKI, is merely an optional extra. It's no more required
in SSL than it is in SSHv2.
the pk-init draft for kerberos allows public keys .... allowing both
cert & cert-less implementations
<blatant aads-promotion>
the scenario allows for public key registration in lieu of shared-secret registration. the benefit is that r/o access, divulging,
sniffing, etc doesn't result in compromise (as in shared-secret)
in the token form ....
https://www.garlic.com/~lynn/x959.html#aads
the key-pair is gen'ed in the chip and never leaves the chip.
as part of 3-factor authentication
* something you have
* something you know
* something you are
the chip in the token purely provides something you have
authentication ... and the digital signature done by the token is
purely to prove that you have that particular token. It doesn't prove
who you are, it just proves that you have a specific (extremely
difficult to counterfeit) token as part of something you have
authentication.
if the token is augmented with a pin/password for its correct
operation, then there can be 2-factor authentication. It doesn't
involve shared-secrets since the pin/password is purely between the
person and the hardware token.
A business process may validate that the token is of the type requiring
PIN and/or biometric for correct operation (in order to meet
particular business integrity constraints).
An ecdsa digital signature authentication protocol for kerberos,
radius, x9.59 for all retail financial transactions, or ssh can be
identical regardless of various additional business integrity
requirements.
The ecdsa digital signature authentication protocol can be ubiquitous
regardless of various additional business integrity requirements.
The business process (for specific integrity requirements) then can
require: sofware key-pair, hardware token key-pair, the level of
integrity of the hardware token, and/or the operational
characteristics of the hardware token (no-pin, pin, biometrics, etc)
w/o changing the protocol.
If the protocol is independent of much of the business process
integrity issue then either the business and/or the end-user may be
able to have personal choice about the level of integrity
required. Furthermore, the person might even have personal choice
whether they need a unique token per security environment, a single
token for all security environments, and/or a small number of tokens
selectively applied to specific security environments
the digital signature has nothing at all to do directly with the
person, it is purely related to demonstrating the possession of the
token (as part of something you have authentication) and
possibly the integrity level of the token.
The issue of the authentication protocol is getting the bits and bytes
for transmission correct but doesn't normally say what it means
... i.e. secret, shared-secret, one-factor
authentication, two-factor authentication, something you
have authentication, something you know authentication,
etc. ... even tho frequently the protocol is envisioned to be a
specific implementation of a specific kind of authentication and
trust/integrity level.
recent token discussions
https://www.garlic.com/~lynn/2003i.html#1 two-factor authentication with SSH?
https://www.garlic.com/~lynn/2003i.html#2 two-factor authentication with SSH?
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
older token discussions
https://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
https://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall?
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001g.html#1 distributed authentication
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#61 I-net banking security
https://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
https://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002i.html#65 privileged IDs and non-privileged IDs
https://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
</blatent aads promotion>
Microsoft Ties Security to Verisign
From: Lynn Wheeler
Date: 06/03/2003 04:24 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Microsoft Ties Security to Verisign
http://www.internetnews.com/ent-news/article.php/2216571
June 3, 2003
Microsoft Ties Security to VeriSign, Certifications
By Thor Olavsrud and Mark Berniker
Microsoft Ties Security to VeriSign, Certifications By Thor Olavsrud
and Mark Berniker Microsoft (Quote, Company Info) moved to bolster its
code-securing effort called Trustworthy Computing Initiative by
announcing two security initiatives Tuesday. Microsoft and VeriSign
said they would jointly develop improved solutions for authentication
security, digital rights management (DRM) and other online security
enhancements. Financial terms of the deal were not disclosed.
... snip ...
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
OASIS and RosettaNet Set Standards Alliance
From: Lynn Wheeler
Date: 06/03/2003 04:26 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: OASIS and RosettaNet Set Standards Alliance
http://www.internetnews.com/dev-news/article.php/2216641
June 3, 2003
OASIS and RosettaNet Set Standards Alliance
By Michael Singer
Cementing their casual relationship, industry standards consortia,
OASIS (Organization for the Advancement of Structured Information
Standards) and RosettaNet Tuesday said they are now working in tangent
to streamline Web services (define) specifications for supply chain
companies. The groups actively participate in the technical work of
the other but say the partnership (dubbed the "Standards
Development-to-Implementation Alliance") is a chance to advance
e-business standards without having to do double the work.
... snip ...
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **, - **, - **, - **, - **
Date: Tue, 03 Jun 2003 17:29:44 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: pgut001@xxxxxxxx (Peter Gutmann),
bill.stewart@xxxxxxxx, cryptography@xxxxxxxx,
cypherpunks@xxxxxxxx, ekr@xxxxxxxx, rsalz@xxxxxxxx,
sguthery@xxxxxxxx
At 03:04 PM 6/3/2003 -0700, James A. Donald wrote:
I never figured out how to use a certificate to authenticate a
client to a web server, how to make a web form available to one
client and not another. Where do I start?
What I and everyone else does is use a shared-secret, a
password stored on the server, whereby the otherwise anonymous
client gets authenticated, then gets an ephemeral cookie
identifying him.. I cannot seem to find any how-tos or
examples for anything better, whether for IIS or apache.
As a result we each have a large number of shared-secret
passwords, whereby we each log into a large number of
webservers. Was this what the people who created this protocol
intended?
The issue is where does the authentication material come from.
<blatant aads promotion>
Basically, certificates were solution targeted for offline email from
the early '80s. you dial-up, connect, exchange email, hang-up. then
you read. some random person that you never, ever dealt with before
sends you something; they claim to be somebody .... the certificate is
signed by somebody you trust .... and is offered as proof that they are
who they claim to be.
the other approach in the online world &/or with previous
relations, is to have a directly accessible table of authentication
material (passwords, pins, public keys). the payment (debit/credit)
card world went from non-electronic, offline to electronic and online
(and skipped the step altogether that certificates represent ... the
electornic and offline).
note that even the certificate-based infrastructure are dependent on
this method .... basically the certificate-enabled infrastructures
everybody has a local table of "CA" public keys (i.e. those public
keys that they've previously decided to trust) ... then certificates
are validated with "CA" public keys (from their local table) and the
current message/document is validated with public key from
certificate. The primary difference between cert-based infrastructure
and certless-based infrastructure is that in the cert-based
infrastructure,, the CAs have their database of all public keys and
create these small R/O, stale, static copies of their database
records (called certificates) and spray them all over for use in
offline environments. Then relying parties just have abbreviated
CA-only public key tables and supposedly can't access the full tables maintained
at the CAs.
In the certless-based infrastructure the relying parties either
maintain their own full tables of all public keys and/or have direct
online access to the full tables. There is no need for these little
R/O, stale, static, redundant and superfluous copies of
somebody else's offline database entry (called certificates) since there
can be direct, online access to the original copy.
the generalized case can be hooking a web server to either radius or
kerberos for handling the authentication process. both radius and
kerberos support shared-secrets recorded in authentication
database (potentially along with various authorization material).
radius recording public key in lieu of shared-secret and
performing ecdsa digital signature authentication. pkinit for kerberos
also allows for public key recorded in lieu of shared-secret
with digital signature authentication (not that radius can determine
authentication method, authentication material, and authorization on
an account by account basis).
misc. radius public key authentication posts
https://www.garlic.com/~lynn/subpubkey.html#radius
misc. kerberos public key authentication posts
https://www.garlic.com/~lynn/subpubkey.html#kerberos
futher discussion specifically regarding stale, static,
redundant, superfluous certificates.
https://www.garlic.com/~lynn/subpubkey.html#rpo
slightly related discussions regarding SSL merchant comfort
certificates:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
</blatant aads promotion>
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **, - **
Date: Tue, 03 Jun 2003 20:49:48 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: pgut001@xxxxxxxx (Peter Gutmann),
bill.stewart@xxxxxxxx, cryptography@xxxxxxxx,
cypherpunks@xxxxxxxx, ekr@xxxxxxxx, rsalz@xxxxxxxx,
sguthery@xxxxxxxx
some generic reasons for hooking radius (or one of the AAA
technologies) into your webserver for authentication are:
1) supports a variety of authentication mechanisms on an account by
account basis. day one, none of the users actually need to see any
difference (single administrative interface supporting all the client
authentication options that might be in use). existing
userid/password, challenge/response and in the referenced asuretee
url, ecdsa digital signature.
2) single administrative interface for both client authentication
options as well as all of their authorization and privilege options.
3) client database is accessible in real-time by the webserver,
real-time updates can occur to both authentication information as well
as authorization, permission and privilege information using single
consistent administrative operation
4) there is no disconnect between client administration and stale,
stale, redundant and superfluous certificates that are a
subset of a r/o administrative database entry. (RADIUS) Updates
can take place in real time and immediately reflected. The certificate
story (as mentioned previously, created for offline, disconnected
environment) basically would do something like a) invalidate
the old certificate, b) issue new CRLs, c) possibly
update a OCSP LDAP, d) update the master database permissions
entry for that client, e) generate a certificate that
represents a subset of the master information, f) distribute it
to the client and g) then have the client install the new
certificate. This of course becomes unnecessary if the certificate
doesn't actually contain any information and the webserver accesses
the authorization and permissions from an online database. However, as
has repeatedly been pointed out before, if the certificate doesn't
contain any information and the webserver is accessing an online
database for authorizations and permissions ... then the webserver can
access the online database for the authentication material also. The
certificate then is stale, static, redundant and
superfluous and you are back to a single online, real-time
comprehensive administrative facility (like radius) that supports
client/account specifics for authentication, authorization,
permissions, accounting, privileges, etc.
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 04 Jun 2003 10:12:04 -0600
To: "Dave Howe" <DaveHowe@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: "Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 12:02 PM 6/4/2003 +0100, Dave Howe wrote:
For that matter, our system here discards the CC after use (the pre-auth
step with the merchant bank agent gives us back a "fulfillment handle" that
can only be used to fulfill or cancel that individual transaction - but of
course Amazon want to keep your CC details so they can do their
fast-checkout patented thingy.
the ground rules given the x9a10 working group for the x9.59 standard
was to preserve the integrity of the financial infrastructure for
all electronic retail payments (credit, debit, stored-value, POS,
internet, non-internet, aka ALL). it was one of the things that
led us down the path of certless operation. We had previously done the
work on the original payment gateway and had to perform various kinds
of due diligence on all the major CA vendors .... which started to
dawn on us that stale, static certificates were actually
redundant and superfluous in the financial business process.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
sort of the next clinker was starting to do operational and
performance profile on any of the existing payment networks .... and
it was evident that there was a huge mismatch between the existing
payment transaction payload size and any of the commonly used
certificates (even the drastically simplified replying-party-only
certificates carrying only an account number and public key).
Two major characteristics of X9.59 was that it would provide 1)
end-to-end authentication (aka the consumers financial institution
would be the one responsible for performing authentication) and 2)
account numbers used in X9.59 transactions could not be used in
unauthenticated transactions.
Some of the '90s digitally signature oriented specifications had
authentication occurring at the internet boundary and stripping off
the certificate (avoiding the extreme certificate payload penalty in
the payment network). The downside was that the party performing the
authentication didn't necessarily have the consumer's interest in mind
and Visa subsequently presented statistics at a ISO standards meeting
on the number of transactions flowing through the network 1) with a
flag claiming to have been digitally signature authenticated and 2)
they could prove that no digital signature technology was ever
involved.
Evesdropping, sniffing or harvesting account numbers in the current
infrastructure (at any point in the process, by insiders or outsiders,
traditionally financial exploits have been 90 percent insiders) can
result in fraudulent transactions. As a result, existing account
numbers effectively become a form of shared-secret and need to be
protected. With the X9.59 business rule requiring the account number
to only be used in authenticated transactions, simple harvesting of a
X9.59 account number doesn't result in fraud. Issuing financial
institutions then can use existing business processes that support
mapping of different account numbers to the same account. A
discussion of the security proportional to risk with regard to credit
card transactions:
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe?
The issue with the use of SSL for protecting credit card transactions
isn't addressing all or even the major vulnerability to the
infrastructure. Eliminating the account number as a form of
shared-secret addresses all of the vulnerabilities, not just
the transaction-in-flight vulnerability addressed by SSL. As a
byproduct of addressing all of the shared-secret related
vulnerabilities, it also eliminates the need to use SSL for protecting
the shared-secret while being transmitted.
Detailed report of its use in the NACHA debit network trials can be
found at
https://web.archive.org/web/20070706004855/http://internetcouncil.nacha.org/News/news.html
scroll down to "July 23, 2001: Digital Signatures Can Secure ATM Card
Payments"
More details of X9.59 standard:
https://www.garlic.com/~lynn/x959.html#x959
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 04 Jun 2003 20:58:47 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: "Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 04:25 PM 6/4/2003 -0700, James A. Donald wrote:
Everyone in America has several shared-secrets identifying them
-- the number of the beast to identify them to the state, and
their credit card numbers identifying them to various financial
institutions, plus a hundred passwords to login to their
email, their bank, their network provider, e-gold, etc.
The PKI idea was that we would instead use PK in place of
shared-secrets, but if an ordinary person had a private key,
what could he use it for?
The spam that seeks to get us to login to e-g0ld and the
BankOf4merica.com works because the logins are based on shared-secrets, not private keys, and the networks are setup to rely
on shared-secrets because there is no practical alternative.
one could claim that public-key is a practical alternative but it got
significantly sidetracked with independent business model that wanted
to extract huge amount of money out of existing infrastructures (say
totally brand new independent operations wanting $100/annum for every
person, extracted from the existing infrastructure for no significant
positive benefit ... aka say 200m people at @$100/annum is $20b/annum
... in return for some abstract bit vapor that doesn't change any core
business issue).
it is relatively trivial to demonstrate that public keys can be
registered in every business process that currently registers
shared-secrets (pins, passwords, radius, kerberos, etc, etc). the
issue then becomes one of cost to change/upgrade those infrastructures
to support digital signature authentication with the stored public
keys in lieu of string comparison (no new business operations, no new
significant transfer of wealth to brand new outside business entities,
etc).
however, think about even these simple economics for a minute
.... even for relatively modest technology changes that don't change
any of the business processes/relationships ... it still costs some
money ... and the beneficiary isn't the institution, it is the
individual. The individual has the paradigm changed from hundreds of
shared-secrets to a single key-pair ... however each institution
continues to see just as many individuals and account records. From a
very practical standpoint ... entities don't frequently fund things
that they don't benefit from ... and typically most success is
achieved when the entity that benefits from the change is also
driving/funding the change.
the issue is to find out how the individual pays for the change
.... or figure out how the institutions are going to benefit.
--
Anne & Lynn Wheeler https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: EKR <ekr@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Date: Fri, 06 Jun 2003 13:34:41 -0600
Cc: "James A. Donald" <jamesd@xxxxxxxx>,
pgut001@xxxxxxxx (Peter Gutmann),
bill.stewart@xxxxxxxx, cryptography@xxxxxxxx,
cypherpunks@xxxxxxxx, rsalz@xxxxxxxx,
sguthery@xxxxxxxx
At 04:42 PM 6/4/2003 -0700, Eric Rescorla wrote:
Nonsense. One can simply cache the certificate, exactly as one does
with SSH. In fact, Mozilla at least does exactly this if you tell it
to. The reason that this is uncommon is because the environments where
HTTPS is used are generally spontaneous and therefore certificate
caching is less useful.
there are actually two scenarios .... one is to pre-cache it (so that
its transmission never actually has to happen) and the other is to
compress to zero bytes. detailed discussion of certificate
pre-caching and certificate zero byte compression:
https://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2
the typical use for HTTPS for e-commerce is to hide the account number
on its way to the financial institution. for the most part, the
merchant is primarily interested in the response from the consumer's
financial institution on whether or not the merchant gets paid. If it
weren't for the associated business processes, the merchant could get
by with never knowing anything at all about the consumer (the merchant
just passes the account number on ... and gets back what they are
really interested in .... the notification from the bank that they
will get paid).
So a HTTPS type solution is that the consumer pre-caches their bank's
certificate (when they establish a bank account). .... and they
transmit the account number "hidden" using the bank's public key. This
happens to pass thru the merchants processing .... but for purposes of
the authorization, the merchant never really has to see it. The
protocol would require minor issues of replay attacks .... and be able
to be done in a single round trip .... w/o all the SSL protocol
chatter. Actually, is isn't so much pre-caching their bank's
certificate .... as loading their bank's public key into a table
.... analogous to the way CA public keys are loading into tables (aka
using out-of-band processing .... the convention that they may be
self-signed and encoded in a certificate format is an anomoly of
available software and in no way implies a PKI). The primary purpose
of HTTPS hasn't been to have a secure channel with the merchant, the
primary purpose of the HTTPS is to try and hide the consumer's account
number as it makes its way to the consumer's financial institution.
The other solution is the X9.59 standard (preserve the integrity of
the financial infrastructure for all electronic retail payments,
not just internet, not just POS, not just credit, ALL; credit,
debit, stored value, etc) that creates authenticated transactions and
account numbers that can only be used in authenticated transaction.
The consumer's public key is registered in their bank account (out of
band process, again no PKI). X9.59 transactions are signed and
transmitted. Since the account number can only be used in
authenticated transactions .... it changes from needing encryption to
hide the value as part of a shared-secret paradigm to purely a
paradigm that supports integrity and authentication. As in the above,
scenario, the merchant passes the value thru on its way to the
consumer's financial institution; and is focused on getting the
approved/disapproved answer back about whether they will be paid. As
in the bank HTTPS scenario where the bank's pubilc key is pre-cached
at the consumer, the consumer's public key is pre-cached at the bank
.... involves no PKI business processes (although there may be some
similarities that the transport of the public key involves encoding in
a certificate defined format). misc. x9.59 refs:
https://www.garlic.com/~lynn/x959.html#x959
Both pre-caching solutions are between the business entities that are
directly involved; the consumer and the consumer's financial
institution based on having an established business relationship.
The invention of PKI was primarily to address the issue of an event
between two parties that had no prior business relationship and
possibly weren't going to have any future business relationship and
that they would conclude their business relying on some mutual trust
in the integrity of a 3rd party w/o actually having to resort to an
online environment. The e-commerce scenario is that there is
real-time, online transaction with the trusted 3rd party (the
consumer's financial institution) involving prior business
relationship. This negates the basic original assumptions about the
environment that PKIs are targeted at addressing.
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 06 Jun 2003 17:45:35 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
"Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 04:24 PM 6/6/2003 -0700, James A. Donald wrote:
I don't think so.
??? public key registered in place of shared-secret?
NACHA debit trials using digitally signed transactions did it with
both software keys as well as hardware tokens.
https://web.archive.org/web/20070706004855/http://internetcouncil.nacha.org/News/news.html
in the above scroll down to July 23, 2001 ... has pointer to detailed
report?
X9.59 straight forward establishes it as standard .... with some
activity moving on to ISO
https://www.garlic.com/~lynn/x959.html#x959
pk-init draft for kerberos specifies that public key can be registered
in place of shared-secret.
various radius implementations have been done be a number of people.
in all of these cases, there is no change in the business process
and/or business relationship .... doesn't introduce totally unrelated
parties to the business activities. there is digital signing on the
senders side (actually a subset of existing PKI technology) and
digital signature verification on the receivers side (again a subset
of existing PKI technology). To the extent that there is impact on
existing business process ... it is like in the case of introducing
x9.59 authentication for credit transactions that have relatively
little authentication currently .... and as a result would eliminate
major portion of the existing credit card transaction related fraud.
The big issue isn't the availability of the technology ... although
there is a slight nit in the asuretee case being FIPS186-2, ecdsa
.... and having support in CAPI and related infrastructures. It not
working (easily) is like when my wife and I were doing the original
payment gateway .... with this little client/server startup in menlo
park (later moved to mountain view and have since been bought by AOL)
and people saying that SSL didn't exist ... misc ref from the past
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
An attack on paypal
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
Date: Sun, 08 Jun 2003 18:12:34 -0600
To: "Dave Howe" <DaveHowe@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: "James A. Donald" <jamesd@xxxxxxxx>,
"Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 11:43 PM 6/8/2003 +0100, Dave Howe wrote:
HTTPS works just fine.
The problem is - people are broken.
At the very least, verisign should say "ok so '..go1d..' is a valid server
address, but doesn't it look suspiously similar to this '..gold..' site over
here?" for
https://pseudo-gold-site/
- but really, if users are going to
fill in random webforms sent by email, they aren't going to be safe under
any circumstances; the thing could send by unsecured http to any site on the
planet, then redirect to the real gold site for a generic "transaction
completed" or even "failed" screen
A world where a random paypal hack like this one doesn't work is the same as
the world where there is no point sending out a Nigerian as you will never
make a penny on it - and yet, Nigerian is still profitable for the con
artists.
in a world where there are repeated human mistakes/failures .... at
some point it is recognized that people aren't perfect and the design
is changed to accommodate peoples foibles. in some respects that is
what helmets, seat belts, and air bags have been about.
in the past systems have designed long, complicated passwords that are
hard to remember and must be changed every month. that almost worked
when i person had to deal with a single shared-secret. when it became
a fact of life that a person might have tens of such different
interfaces it became impossible. It wasn't the fault of any specific
institution, it was a failure of humans being able to deal with large
numbers of extremely complex, frequently changing passwords. Because
of known human foibles, it might be a good idea to start shifting from
an infrastructure with large numbers of shared-secrets to a
non-shared-secret paradigm.
at a recent cybersecurity conference, somebody made the statement that
(of the current outsider, internet exploits, approximately 1/3rd are
buffer overflows, 1/3rd are network traffic containing virus that
infects a machine because of automatic scripting, and 1/3 are social
engineering (convince somebody to divulge information). As far as I
know, evesdropping on network traffic doesn't even show as a blip on
the radar screen.
In the following thread on a financial authentication white paper:
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
https://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
there is point made that X9.59 standard doesn't directly address the
Privacy aspect of security (i.e. no encryption or hiding of
data). However, the point is made that it changes the paradigm so that
the financial account number no longer represents a shared-secret and
that it can be supported with two-factor authentication
i.e. something you have token and something you know PIN. The
something you know PIN is used to enable the token, but is not a
shared-secret. Furthermore, strong authentication can be justification
for eliminating the need for name or other identification information
in the transaction.
However, if X9.59 strong authentication is used with two-factor
authentication and no identification information is necessary
.... then it would make people more suspicious if privacy information
was requested. Also, since privacy information is no longer sufficient
for performing a fraudulent transaction, it might mitigate that kind
of social engineering attack.
The types of social engineering attacks then become convincing people
to insert their hardware token and do really questionable things or
mailing somebody their existing hardware token along with the valid
pin (possibly as part of an exchange for replacement). The
cost/benefit ratio does start to change since there is now much more
work on the crooks part for the same or less gain. One could also
claim that such activities are just part of child-proofing the
environment (even for adults). On the other hand, it could be taken as
analogous to designing systems to handle observed failure modes (even
when the failures are human and not hardware or software). Misc. identify
theft and credit card fraud reference:
https://web.archive.org/web/20021017091112/http://www.consumer.gov/idtheft/cases.htm
http://www.usdoj.gov/criminal/fraud/idtheft.html
https://www.garlic.com/~lynn/aadsm14.htm#22 Identity Theft Losses Expect to hit $2 trillion
https://www.garlic.com/~lynn/subintegrity.html#fraud
Slightly related in recent thread that brought up buffer overflow exploits
https://www.garlic.com/~lynn/2003j.html#4 A Dark Day
and the report that multics hasn't ever had a buffer overflow exploit
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
somebody (else) commented (in the thread) that anybody that currently
(still) writes code resulting in buffer overflow exploit maybe should
be thrown in jail.
An attack on paypal
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
Date: Sun, 08 Jun 2003 20:00:40 -0600
To: "Dave Howe" <DaveHowe@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: "Anne & Lynn Wheeler" <lynn@xxxxxxxx>,
"James A. Donald" <jamesd@xxxxxxxx>,
"Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 02:09 AM 6/9/2003 +0100, Dave Howe wrote:
The problem is here, we are blaming the protective device for not being able
to protect against the deliberate use of an attack that bypasses, not
challenges it - by exploiting the gullibility or tendency to take the path
of least resistance of the user.
The real weakness in HTTPS is the tendency of certificates signed by Big
Name CAs to be automagically trusted - even if you have never visited that
site before. yes, you can fix this almost immediately by untrusting the
root certificate - but then you have to manually verify each and every site
at least once, and possibly every time if you don't mark the cert as
"trusted" for future reference.
that is why we coined the term merchant "comfort" certificates some
time ago. my wife and I having done early work for payment gateway
with small client/server startup in menlo park ... that had this thing
called SSL/HTTPS ... and then having to perform due diligence on the
major issuers of certificates .... we recognized 1) vulnerabilities in
the certificate process and 2) information hiding of transaction in
flight only addressed a very small portion of the vulnerabilities and
exploits.
lots of past discussions related to our use of merchant comfort
certificate term:
https://www.garlic.com/~lynn/subpubkey.html#sslcert
we concluded that a real issue is that way too much of the
infrastructure is based on shared-secrets and there was no realistic
way of providing blanket protection to all the exposures and
vulnerabilities of such shared-secret infrastructures. somewhat
related discussion in the security proportional to risk posting:
https://www.garlic.com/~lynn/2001h.html#61
so rather than trying to create a very thick blanket of encryption
covering the whole planet .... a synergistic approach was attempting
to provide alternatives to as much of the shared-secret paradigm as
possible. As in the referenced post:
https://www.garlic.com/~lynn/aepay11.htm#53 authentication white paper
strong encryption of identification and privacy (and shared-secret)
information is good ... but not having identification, privacy and
shared-secret information is even better.
there are all sorts of ways of obtaining shared-secret information
(and/or privacy and identification information prelude to identity
theft) .... including various kinds of social engineering.
as previously mentioned requirement for X9.59 standard was to preserve
the integrity of the financial infrastructure for ALL electronic
retail payments. As per previous notes, X9.59 with strong
authentication eliminates the account number as a shared-secret as
well as eliminating requirements for name, address, zip-code, etc as
part of any credit card authentication process (strong encryption of
vulnerable information is good, not having vulnerable information at all is
even better).
ALL in addition to referring to things like credit cards, debit cards,
atm transactions, stored-value transaction, over the internet, at
point-of-sale, face-to-face, automated machines, etc .... also refers
to ACH transactions. ACH information allows for unauthenticated push
or pull transactions. Social engineering requesting bank account
information so somebody can push tens of millions into your account
also allows for them to generate a pull transaction removing all the
money from your account. Part of the above posting on the
authentication white paper .... makes references to securing ACH
transactions:
https://web.archive.org/web/20030816180523/http://www.asuretee.com/company/releases/030513_hagenuk.shtm
virus attack on banks (was attack on paypal)
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 10 Jun 2003 09:19:19 -0600
To: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: virus attack on banks (was attack on paypal)
Cc: "Dave Howe" <DaveHowe@xxxxxxxx>,
"James A. Donald" <jamesd@xxxxxxxx>,
"Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 06:12 PM 6/8/2003 -0600, Anne & Lynn Wheeler wrote:
at a recent cybersecurity conference, somebody made the statement that
(of the current outsider, internet exploits, approximately 1/3rd are
buffer overflows, 1/3rd are network traffic containing virus that
infects a machine because of automatic scripting, and 1/3 are social
engineering (convince somebody to divulge information). As far as I
know, evesdropping on network traffic doesn't even show as a blip on
the radar screen.
virus attempting to harvest (shared-secret, single-factor) passwords
at financial institutions
http://www.smh.com.au/articles/2003/06/10/1055010959747.html
and somewhat related:
https://www.garlic.com/~lynn/aepay11.htm#53 authentication white paper
The real problem that https has conspicuously failed to fix
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 10 Jun 2003 21:33:37 -0600
To: Anonymous <cripto@xxxxxxxx>
Subject: Re: The real problem that https has conspicuously failed to fix
Cc: cryptography@xxxxxxxx
At 11:26 PM 6/10/2003 +0200, Anonymous wrote:
The problem to be solved is this. Spoofed sites can acquire user
credentials, especially passwords, and then use those to impersonate
the user on the real sites. With paypal and e-gold, this allows
stealing real money.
Using client certificates to authenticate would solve this, because
even if the user got fooled and authenticated to the spoofed site, the
attacker wouldn't learn the client cert secret key and so would not be
able to masquerade as the user.
The problem (among others) is that this allows a virus to steal the
client cert. If it is protected by a password, the malware must hang
around long enough for the user to unlock the cert (perhaps because
the malware sent a spoofed email calling for the user to visit the
site, even the real site!). It can then read the user's keystrokes
and acquire the password. Now it has the cert and password and can
impersonate the user at will.
slight nit .... the solution is non-shared-secret in conjunction with
something you have authentication implementing, digital signatures,
public/private keys where the private key is never divulged .... even
to the owner (the private key housing can be hardware token ... or
something embedded in the computer).
it seems that certificates sometimes are considered synonymous with
public/private key and digital signatures. however, certificates were
originated to address a specific issue with key distribution and trust
involving parties that 1) had no prior business relation, 2) were
unlikely to have any future business relationship, and 3) didn't have
online access to trusted 3rd party. however, it is actually much more
natural in a standard business process setting that public key is
registered in lieu of shared-secret authentication material when
parties are involved that have established business relationship (aka
for example a person with some sort of an account, especially in any
sort of online paradigm). Trivial examples of certificate-less
operation with public/private keys are radius, kerbers pk-init and
x9.59 standard for all retail payment transactions (internet,
non-internet, point-of-sale, debit, credit, ach, stored-value, etc).
Also note, a certificate tends to only contain the owners public key
and some other information about the owner (and nominally is assumed
to be freely distributable, somewhat in the same way the PGP keyserver
information is published). The certificate doesn't contain the private
key ... which tends to be either in a software encrypted file or an
external hardware token.
for the various possible types of social engineering & virus exploits,
eliminating shared-secrets is only a partial solution (although shared-secrets have a number of vulnerabilities and exploits, so eliminating
shared-secrets is not a bad thing)., if the individual has direct
access to the private key in any way, then it is possible to compromise
that access. That is where some flavor of something you have
authentication comes in with hardware that houses the private key and
there is no way to divulge the private key, even to the owner. EU
finread (financial reader) has an external reader with its own display
and pin-pad. This addresses the issue (even with something you have
hardware token) where a viirus can 1) display one value on the screen
and send another value to the token for signing and 2) spoof keystroke
entry with the correct PIN (perform fraudulent transactions w/o the
owners knowledge).
If the
1) private key can never be directly physically accessed,
2) the digital signature is taken to represent a form of something you
have authentication.
3) the display can be trusted to always display what will be signed
4) the keypad can't be spoofed and actually requires the person to hit
the keys
5) hardware token never signs anything unless there has been (human)
keypad entry
then the remaining types of fraud will tend to be no different than
the phone scams, mail scams and the people coming to your door scams
.... effectively no different than the types of fraud that has been
going on for hundreds/thousands of years.
An attack on paypal
Date: Wed, 11 Jun 2003 12:42:50 -0600
To: Sunder <sunder@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: "James A. Donald" <jamesd@xxxxxxxx>,
"Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 10:56 AM 6/11/2003 -0400, Sunder wrote:
In either case, we wouldn't need to worry about paying Verisign or
anyone else if we had properly secured DNS. Then you could trust
those pop-up self-signed SSL cert warnings.
actually, if you had a properly secured DNS .... then you could trust
DNS to distribute public keys bound to a domain name in the same way
they distribute ip-addresses bound to a domain name.
the certificates serve two purposes: 1) is the server that we think we
are talking to really the server we are talking to and 2) key-exchange
for establishing an encrypted channel. a properly secured DNS would
allow information distributed by DNS to be trusted .... including a
server's public key .... and given the public key .... it would be
possible to do the rest of the SSL operation (w/o requiring
certificates) which is establishing an agreed upon session secret key.
Keyservers and Spam
Refed: **, - **, - **, - **
Date: Wed, 11 Jun 2003 13:00:31 -0600
To: bear <bear@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: RE: Keyservers and Spam
Cc: Jill.Ramonsky@xxxxxxxx, dahonig@xxxxxxxx,
<cryptography@xxxxxxxx>
At 10:27 AM 6/11/2003 -0700, bear wrote:
I don't particularly like the commercial certs, but the thousand bucks
or so ought to serve as a "bond", in that if people untrust the keys,
there is real value that will be lost. That makes it require some
expenditure of resources to grab a new nym. However, even when
provoked - even when root certs have been SOLD - people still
don't untrust them, because the news of the compromise doesn't
propagate around triggering revokes on individual systems.
i've been told of the things that form the basis of
contract/obligation is providing something in return for
consideration. the certificate is sold to key owner, to the extent
there is some obligation it is tetween the certificate issuer and the
owner of the key.
there tends to not be any relationship between the relying party and
the certification authority. i believe the federal gov. got around
this by having GSA(?) be the certification authority .... with the
certificate manufactures/issuers performing as agents of GSA .... and
all the possible relying parties had some sort of contract with GSA.
That of course is a little awkward in the case of domain name server
certificates .... having all the consumer relying parties in the world
sign contracts with the major certificate vendors .... so it would
establish some sort of obligation for relying on a certificate.
An attack on paypal (trivia addenda)
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 11 Jun 2003 17:23:52 -0600
To: David Honig <dahonig@xxxxxxxx>
Subject: Re: An attack on paypal (trivia addenda)
Cc: Sunder <sunder@xxxxxxxx>,
"James A. Donald" <jamesd@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
somewhat related to the early posting in this m.l. about distributed
computing systems conference and possible interest from security and
cryptography sections.
when my wife and I were doing ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
https://www.garlic.com/~lynn/2003j.html#22 why doesn't processor reordering instructions affect most
we were working with two people in the following meeting in ellison's
conference room
https://www.garlic.com/~lynn/95.html#13
who the following year, left and joined a small client/server startup
and were responsible for something called the commerce server (the
company also had this thing called https/SSL). we then worked with
these two people on the implementation for payments for the thing
called the commerce server and well as the infrastructure regarding
trusting online merchants (as part of promoting this whole thing that
came to be called electronic commerce):
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
and more recent posting in the same thread that I had also posted
about buffer overflows and the multics study:
https://www.garlic.com/~lynn/2003j.html#15 A Dark Day
in any case, one of the jokes has been there are actually only 200
people in the industry.
ok, reference to the recent related thread on distributed system
operation:
https://www.garlic.com/~lynn/2003i.html#70 A few Z990 Gee-Wiz stats
https://www.garlic.com/~lynn/2003i.html#72 A few Z990 Gee-Wiz stats
https://www.garlic.com/~lynn/2003j.html#3 A few Z990 Gee-Wiz stats
https://www.garlic.com/~lynn/2003j.html#7 A few Z990 Gee-Wiz stats
and past posts discussing the BBB aspects for online electronic commerce:
https://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
https://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature
https://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#2 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
https://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
https://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
https://www.garlic.com/~lynn/aepay11.htm#7 FTC says incidence of ID theft jumped in 2002
https://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ?
An attack on paypal
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 11 Jun 2003 19:37:32 -0600
To: "Steven M. Bellovin" <smb@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: cryptography@xxxxxxxx
At 08:07 PM 6/11/2003 -0400, Steven M. Bellovin wrote:
Let me point folk at http://www.securityfocus.com/news/5654
for a related issue. To put it very briefly, real authentication is
hard.
"real" authentication is not actually that hard; it is
"identification" that tends to really get sticky. one of the reasons
for simplified security taxonomy like PAIN or PAIIN ... aka
Privacy
Authentication
Identification
Integrity
Non-repudiation
3-factor authentication is
something you have (like a token)
something you know (like password)
something you are (like biometrics)
In the past, I've posted regarding proposals for implementing
authentication techniques in association with various internet
operation registries .... in part because they are currently relying
primarily on identification which is easily spoofed.
the previous posts highlight the domain name take-over exploits
.... using the same techniques used in the referenced article for
ip-address take-over.
the issue for SSL domain name certificates .... and people concerned
about the integrity of the domain name infrastructure .... is that the
certification authorities aren't the authoritative reference for the
information that they are certifying .... it is the domain name
infrastructure (and similarly the ip-address registry). The domain
name take-overs have been very similar to the described techniques in
the article for ip-address take-over. Somewhat the CA industry
proposal is for the registries to implement public key registration at
the same time the domain name (or ip-address) is registered. The
public key is registered in the registry account record .... and all
future interaction is done via authenticated signed transactions
(authenticated using the public key in the registry account record).
The claim regarding the operation of the internet operational
registries is that they are effectively non-authenticated .... in much
the same way that current credit card transactions are not
authenticated. The x9.59 standard is for all electronic retail
payments and are authenticated using a public key registered in the
account record. This is effectively the some proposal (somewhat
instigated by the certification authority industry) for transitioning
the internet registries from non-authenticated transactions to
authenticated transactions (by using digitally signed messages that
are authenticated with public key registered in the corresponding
registry account record).
as in previous observations .... having a domain name owner register
their public key in the internet registry (domain name infrastructure
or ip-address registery) starts to lesson the requirement for having
SSL domain certificates.
random past posts regarding irony/catch22 for the CAs and SSL domain
name certificates:
https://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
https://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
https://www.garlic.com/~lynn/2001l.html#22 Web of Trust
https://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
https://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
https://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates
https://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
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/2002n.html#2 SRP authentication for web app
https://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all equally secure?
https://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack
https://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack
https://www.garlic.com/~lynn/2003d.html#29 SSL questions
https://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption in a system to system interface
https://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic
The real problem that https has conspicuously failed to fix
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 12 Jun 2003 08:35:03 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
Subject: Re: The real problem that https has conspicuously failed to fix
Cc: cryptography@xxxxxxxx
At 08:20 PM 6/11/2003 -0700, James A. Donald wrote:
I think you have put your finger right on the problem.
Certificates, https, and the entire PKI structure were designed
for an accountless world, but the problem is accounts.
or slightly more accurately doing authentication for accounts. the
other is frequently confusing identification with authentication. the
internet registries (both domain and ip-address) haven't been doing
authentication ... but just some simple identification. there are
situations where identification may be quite orthogonal to whether or not
you are the owner of the account in question. identification
also tends to open up the whole can of worms around protecting
privacy. as periodically stated (in reference to x9.59) thick blanket
of encryption protecting privacy information is good, the information
not being there at all is even better.
certificates & the alternative view
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
Date: Thu, 12 Jun 2003 11:14:33 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: certificates & the alternative view
Cc: cryptography@xxxxxxxx
At 08:20 PM 6/11/2003 -0700, James A. Donald wrote:
I think you have put your finger right on the problem.
Certificates, https, and the entire PKI structure were designed
for an accountless world, but the problem is accounts.
the other view ... is using a little information theory .... is that
certificates are stale, static, read-only copy of information in the
certificate authority's account record .... targeted for offline
environments where the relying party has no access to the real
authoritative agency responsible for the information.
one of the things from the '90s, in the transition from offline to the
start of a pretty much ubiquitous online world was trying to come up
with things to put into certificates to justify their price. One of
the attempts was extreme overloading of the certificate with large
amounts of identity and privacy information, and furthermore you
convince the public that they should pay for the privilege of having
huge amounts of their privacy information sprayed all over the world.
The fallback is to attempt to reduce as much as possible any
information of actual value in a certificate and to not go around
confusing identification with authentication. This was sort of the
relying-party-only certificates from the financial community in the
later part of the 90s .... don't put any information of any value
what-so-ever in a certificate; just create these huge, very large bit
patterns that were one hundred times larger than a typical payment
transaction and require that these extremely large bit patterns had to
be attached to every payment transactions sent back to the financial
institution (which already had the original copy of all the
information). From this it was possible to demonstrate a PKI
infrastructure where every certificate was compressed to zero
bytes. The horrible payload penalty and information/privacy leakage
problem was ultimately addressed with zero byte certificates. They
contained zero byte, stale, static, read-only copy of the information
in the certificate authority's account record.
An attack on paypal
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 12 Jun 2003 11:26:57 -0600
To: David Honig <dahonig@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
David Honig <dahonig@xxxxxxxx>,
Sunder <sunder@xxxxxxxx>,
"James A. Donald" <jamesd@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 05:34 PM 6/11/2003 -0700, David Honig wrote:
When I buy $20 of gas with non-bearer credentials (ie, credit card),
the vendor does a real-time check on me. Seems fair/useful to be able
to do same on them. I suppose eBay's feedback suffices... if their
last N "feedbacks" are negative, I might go elsewhere.
we sort of tried that ... however the financial justification sort of
fell apart. the big thing about BBB is being able to trust some
merchant that you have absolutely no knowledge about. However, the
actual buying patterns are extremely skewed ... with well over 80
percent of the transactions either repeat or with some organization
that there is other avenues of trust propagation .... and involving a
very small number of very large merchants. The BBB model tends to
work with higher value, infrequent transaction. The remaining online,
merchant market segment not covered via other trust processes, tended
to represent a small percentage of total transactions, spread over a
very large population of very small merchants, and frequently low
value.
eBay is an attempt to provide an alternative delivery for such market
segment .... and the issue is how does eBay operations break even
financially on a BBB like offering. The first filter is to quickly
catch major scamming operations ... and differentiate between the
one-off transactions.
PKI "not working"
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/12/2003 12:07 PM
To: "todd glassey" <todd.glassey@xxxxxxxx>
cc: "el-sign: electronic signatures - open discussion"
<EL-SIGN@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: Re: PKI "not working"
something similar in threads on https (and other online) failings from
the cryptography mailing list
https://www.garlic.com/~lynn/aadsm14.htm#41 certificates and an alternative view
https://www.garlic.com/~lynn/aadsm14.htm#5 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#9 "Marginot Web" (SSL, payments, etc)
https://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#33 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#34 virus attack on banks (was attack on paypal)
https://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
https://www.garlic.com/~lynn/aadsm14.htm#36 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#38 An attack on paypal (trivia addenda)
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
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#42 An attack on paypal
todd glossary <todd.glossary@xxxxxxxx on 6/12/2003 8:28 am wrote:
This is a cross posting from the ISC's mailing lists of the Bar
Association.
Why it is important here is that it documents perceived problems in
the PKI marketplace and I perceive that a number of these issues are
failures in the IETF's and potentially the ETSI standards processes,
since they allow processes that are at best incomplete from a
deployment stance to be elevated into standards status IMHO.
My concern is that the value of the IETF and ETSI is growing less and
less with these types of realizations in the marketplace.
Todd
To: <ST-ISC@xxxxxxxx>
Sent: Thursday, June 12, 2003 7:00 AM
Subject: UK: PKI "not working"
PKI is 'not working'
Inadequate technology for online transactions is a 'huge problem' for
those in charge of e-government, admits a leading Whitehall official
The e-envoy's office has started searching for new ways to
authenticate the users of e-services as the existing technology being
used is "not working", a senior Government official revealed on 11
June 2003. Although PKI (public key infrastructure) and digital
certificate technology has played a major role in leading projects
such as the Government Gateway, there is now growing recognition that
it is unsuited for wider public use. While digital certificates would
not be scrapped, and would be retained as an option for e-service
users, one possible alternative being suggested is that employers,
banks, the voluntary sector and other "trusted organisations" would
verify a person's identity before transacting online for
services. Speaking on condition of anonymity, the official said the
Government is now looking at "radical ways" of solving the
authentication problem. "Trust and authentication has been a huge
problem for us. We haven't got a solution for authentication. We've
been trying with PKI for about 10 years now and its not working
because it's a pain to implement and to use. We've been looking to
take the pain out of PKI. What we are saying with authentication is
that if another trusted organisation such as a bank can provide proof
saying you are who you say you are that should take the need away for
digital certificates." The move comes as the e-envoy's office is
acutely aware that it needs to step up the pace of e-government
leading up to the 2005 target.
http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?OpenDocument
Michael Power
Partner & Chief Privacy Officer
Gowling Lafleur Henderson LLP
Barristers & Solicitors
Patent & Trade Mark Agents
Suite 2600
160 Elgin Street
Ottawa, Ontario, CANADA
K1P 1C3
--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm
PKI not working
Date: Thu, 12 Jun 2003 13:10:55 -0600
To: <cryptography@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: PKI not working
picked up from a ietf pkix mailing list posting:
https://www.garlic.com/~lynn/aadsm14.htm#43
http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?OpenDocument
Keyservers and Spam
Date: Fri, 13 Jun 2003 16:50:20 -0600
To: John Kelsey <kelsey.j@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: RE: Keyservers and Spam
Cc: bear <bear@xxxxxxxx>, Jill.Ramonsky@xxxxxxxx,
dahonig@xxxxxxxx, <cryptography@xxxxxxxx>
At 11:56 AM 6/13/2003 -0400, John Kelsey wrote:
The thing that strikes me is that the PGP web of trust idea is
appropriate for very close-knit communities, where reputations matter
and people mostly know one another. A key signed by Carl Ellison or
Jon Callas actually means something to me, because I know those
people. But transitive trust is just always a slippery and
unsatisfactory sort of thing--the fact that Jon Callas trusts Fred
Smith trusts John Jones to sign a key doesn' t really tell me whether
or not I should trust him--by the time we're about three hops away,
you'd have to be God to know enough to have your signature mean
anything.
PGP .... or other similar account-based mechanisms provide trust
between parties that have established relationship .... on a purely
pair-wise, bilaterial basis. It does allow some direct trust
operations to diffuse out to other parties. It isn't so much a
close-knit community .... it is how far every specific entities's
trust operation diffuse out across other individuals.
If the entity is called a certification authority .... and it provides
an online service ... then the diffusing of specific trust operation
might propagate out to a wide community. The issue of course is what
trust attributes are propagating/diffusing and the diligence that the
entity used in establishing the information to be trusted.
If the entity is called a certification authority, and it manufactures
certificates (basically stale, static copies of some CA internal
account record) then those certificates will presumably contains some
information that is bound to the public key ... where there is some
degree of confidence (aka trust) with regard to the binding between
the information and the public key.
One issue is what meaning is there between having absolute certainty
between something like an email address and a public key. Let's say it
is an email address. Typically, email addresses at random are
meaningless to me unless they are part of some specific context
.... like somebody I have an established relationship with. However,
if I have an established relationship with the entity, then it is back
to the PGP scenario. In a broad context, businesses run on
established relationships; aka financial institutions. The whole
existing payment infrastructure effectively has the PGP scenario
without needing certificates, and not exactly being considered a very
close-knit community.
The primary difference between a financial institution actiing as an
entity in a PGP web-of-trust paradigm (say payment cards, credit,
debit, etc) and individual .... is the typical scope of the reputation
of the financial institution is larger than an individual, and
therefor the propagation/diffusing of trust is likely to have a much
further reach. To a larger degree ... the trust radius of an entity is
somewhat independent of whether it is operating in the PGP manner w/o
certificates or in certificate paradigm.
The primary difference in the certificate paradigm is not the scope of
the entity's trust .... it is the design point of delivering the
trust. The certificate paradigm of trust delivery was targeted at an
offline environment for relying parties that had no previous
relationship (and had no online and/or direct recourse to the trust
entity.
The payment card industry established a certificate-less nearly
world-wide scope of trust, in part by providing an extensive online
network.
The certificate-based design point was to be able to provide an
infrastructure for trust propagation between relying parties that had
no previous relationship, were unlikely to need future relationship,
and had no online or direct recourse to the trust entity.
An attack on paypal
Date: Thu, 19 Jun 2003 08:56:50 -0600
To: iang@xxxxxxxx
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: cryptography@xxxxxxxx
At 08:15 PM 6/18/2003 -0400, Ian Grigg wrote:
Certificate caching is a far more powerful idea
than, say, CA-signed certs. If it were added
to browsers, and servers initialised with self-
signed certs, then the security of the net would
go up immensely. Integrated with some of the
ideas that people have suggested concerning WoT,
publically distributed certs, and individualised
displays (amounting to local secrets keyed on the
cert), we could actually start to see people using
secured browsing when they wanted to rather than
when they were forced to.
typically certificates have had two characteristics .... 1) asn.1
encoding for network interoperability distribution and 2) trusted
third party binding of some information to the public key
self-signed certificate caching is really loading public key into a
locally maintained table.
in principal there is no need to maintain asn.1 encoding format in a
locally maintained table since it eliminates having to decode it on
every use .... and the asn.1 encoding is only useful if you 1) are
planning on redistributing somebody else's public key and 2) need the
original bit format for validating the self-signed signature. The
validating of the self-signed signature can be done on initially
acquiring the certificate .... and then it can be decoded, and the
decoded values loaded into the table. the table/database just becomes
entries of public keys and the associated attributes (which might be a
combination of the original plus any additional that you might want to
add along the way).
in that sense it becomes more of authentication management .... along
the lines of kerberos, radius, and/or the AAA RFCs, aka
authentication, authorization, and accounting.
in previous posts about BBB, it is possible that it would be used in
combination with online trusted references .... i.e. analogous to
real-time call to BBB and obtaining referrels and any complaint
information ... and then possibly remembering it by recording it in
the table (aka online trust propagation as opposed to the offline
trust propagation represented by TTP certificates).
Part of the issue with the offline TTP stale, static certificate model
was that it periodically tried to overload the contents of the
certificate .... trying to justify the expense of the ceritifcate to
the public key owner .... but having little or no idea what might be
the future requirements of a broad range of relying parties. A locally
maintained relying-party table/database would allow the relying party
to dynamically adapt the trust characteristics that they were
interested in.
Decoding the self-signed certificate before loading into the local
table .... helps highlight that the recorded trust characteristics
don't have to be restricted to just those that happen to exist in the
stale, static certificate (created at some time in the past by
entities that had no anticipation regarding your specific trust
requirements).
past discussions of online & offline trust propagation:
https://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
https://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
https://www.garlic.com/~lynn/aadsm14.htm#38 An attack on paypal (trivia addenda)
https://www.garlic.com/~lynn/aadsm14.htm#42 An attack on paypal
https://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature
https://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#2 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#4 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
https://www.garlic.com/~lynn/aepay11.htm#7 FTC says incidence of ID theft jumped in 2002
https://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
https://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ?
UK: PKI "not working"
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/24/2003 09:47 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: UK: PKI "not working"
anders.rundgren@xxxxxxxx on 6/23/2003 1:44 am wrote:
I fully agree with Mitchell's conclusions of what PKI is good for as
it stands today. To be able to serve millions of citizens at
thousands of independent e-government portals, either requires TTP
identity-portals (using SAML etc.), or client-side PKI using TTP CAs.
No other methods have proven to be technically or economically
feasible.
I cannot verify any major 100000-foot legal problems, but quite a
bunch of down-to-earth (zero-foot?) problems like "lousy browsers",
and the lack of ubiquitous, secure, and mobile key-containers. IMO,
it is really only the latter that hampers enterprise-PKIs as a
userid/password-replacement on a wider scale. This problem is neither
a standards problem, nor a technical ditto. It is rather an example
of blatant stupidity among "certain manufacturers".
Regarding "legally binding", virtually anything that offers reasonable
technical integrity is likely to be applicable as evidence in a court
trial in most countries. Examples of this are phone-operators'
call-lists that may prove "association" or DNA-fingerprints that may
prove "It wasn't me". What is a bit puzzling is that non-PKI
e-solutions never seem to be questioned regarding their.merits in
courts...
A "legal" aspect that though really is an issue, is TTP CA liability.
However, this is mostly a US issue where suing people is a part of the
system. I believe this will have a negative impact on PKI usage in
the US, unless there is a way to automatically accomplish what
Identrus et al "achieves" by requiring relying parties to sign
agreements freeing the issuer from liability. Here I would like to
address the PKIX WG with a request for some kind of remedy.
Anders
============
I believe it is the electronic signature act ... and there are other
parts of the same bill. it allows various kinds of electronic marks
.... but the main issue for a legal signature (& non-repudiation) is
demonstration of some sort of intent, agreement, etc. The EULAs that
require clicking in various places after reading variouis directions
meet more of the criteria of demonstrating intent & agreement than
does almost all of the CA PKIs that effectively don't enforce any
process after the certificate has been returned to the key owner.
The main issues addressed by the vairous public key digital signatures
are message authentication and integrity ..... as been repeated in
numerous past threads involving non-repudiation ... there is still an
enormous gap between message authentication/integrity and
non-repudiation.
The big issue of TTP CA PKI and legaly issue is that almost all legal
relationship (like contracts) are between two parties where one has
paid money and received something in return. That describes the
relationship between the TTP CA PKI entity and the key owner. The
legal objective seems to be to create some legal fiction that involves
a relationship between the TTP CA PKI and the relying-party. The
traditonal legal relationship doesn't apply to anything between the
TTP CA PKI and the relying-party. As been mentioned in numerous,
repeated threads on this subject in the past, GSA manufactured such a
relationship by some sort of contract between GSA and the TTP CA PKI's
... and GSA and the relying-parties .... so that the facade of legal
relationship between the relying parties and the TTPs. For the most
part, the traditional TTP CA PKI's enforce little or no process after
the certificate has been returned to the key-owner.
Note that the GSA model is similar to the business/legal relationships
established as part of the online debit/credit infrastructures. The
debit/credit infrastructure used to be an offline, manual
process. Starting in the mid-70s, they skipped over the TTP CA PKI
paradigm of offline, electronic process and went directly to an
online, electronic process. For the debit/credit infrastructure the
paradigm represented by TTP CA PKI represents a 30 yuear old
technology option that they decided to skip.
somewhat related is the recent thread on confusing authentication and
identification:
https://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#67 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#69 Confusing Authentication and Identiification?
past threads with mention of pair-wise GSA contracts with both TTPs
and relying-parties created some sort of legal relationship between
relying-parties and TTPs:
https://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01
https://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt
https://www.garlic.com/~lynn/aadsm12.htm#42 draft-ietf-pkix-warranty-extn-01.txt
https://www.garlic.com/~lynn/aadsm14.htm#37 Keyservers and Spam
misc. past threads that reference non-repudiation as well listing
other threads on non-repudiation:
https://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
https://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
https://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#57 e-commerce security????
https://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
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
basic question: semantics of "map", "tie", etc in PKI
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 08 Jul 2003 11:40:29 -0600
To: Fritz Schneider <fritz@xxxxxxxx>
Subject: Re: basic question: semantics of "map", "tie", etc in PKI
Cc: cryptography@xxxxxxxx
At 08:45 AM 7/8/2003 -0700, Fritz Schneider wrote:
This is possibly a silly question, but here goes.
Reading something PKI-related the other day I was wondering about
the semantics of different kinds of certificates. One usually says that
traditional id certs "map names to keys" or "tie keys to names"[1]. This
is usually written:
name -> key
Other certs have similar semantics (they "map" and "tie"). For example,
in order to achieve authorization one could keep an ACL which "maps
permissions to names" ("ties names to permissions"):
permission -> name
Given these two mappings its then possible to get the mapping:
permission -> name -> key
which authorizes the key for the permission.
I actually have two questions.
The first is what exactly does "mapping" mean in this sense? I'm
not sure that it means "mapping" in the sense of the algebraic definition
because for each x that is mapped, there should only be only one value to
which x is mapped, and I think of an ACL or SPKI cert as incompatible with
this notion. "Tie" and "bind" seemed to be used in to indicate both a
mapping or that something is mapped to.
My second question is, in mappings like:
permission -> name -> key
why do we think of it as mapping permission to a key and not the other way
around? The way I typically think about the task of reasoning about
authorization seems to work in the opposite direction.
-- fritz
[1] RFC2693, for example
basic authentication taxonomy is something like:
1) something you have (like a hardware token)
2) something you know (like a pin/password)
3) something you are (like biometrics)
frequently PKIs talk about certifying (aka CA's are certification
authorities, certificates represent some certification by a
certification authority) some binding between something and a public
key.
one could claim that the choice of vocabulary was trying to elevate
something from straight-forward authentication to something like
identification and non-repudiation ... which would represent much more
value and therefor the public key owner buying the certificate might
pay more. Note, however, identification and non-repudiation is
primarily of benefit to the relying-party that receives the
certificate .... but the standard TTP business model has the private
key owner paying for the certificate (not the relying party .... which
is receiving the primary benefit).
There has been lots of discussion that PKIs don't actually do
identification or non-repudiation which requires lots of additional
processes.
Certification authorities basically have an entity prove that it can
generate a digital signature that can be validated with the supplied
public key ..... basically a form of something you have
authentication ... the entity can prove it has the private key. The
certification authority then validates some other piece of information
(like the entity's email address); stores the public key and the
certified information in a database and then creates a
credential/certificate as to the binding between the certified
information and the certified public key.
Originally, x.509 specification was thought of as heavily overloading
a certificate with lots of identity related information as well as
privilege/permission related information ... bound to a public key
in a certificate. It pretty quickly became apparent that a
credential/certificate heavily overloaded with identity and permission
information and indiscriminately broadcast all over the world created
enormous privacy problems.
Financial institutions in the mid-90s dropped back to
relying-party-only certificates which basically contain only account
number and the public key because of the enormous privacy and
liability problems. However, a standard business process involving
certificate has the key-owner 1) creating a transaction/message, 2)
appending a digital signature, 3) appending the certificate ... and
transmit the "triple" to the bank.
The bank extracts the account number from the transaction/message,
reads the account record and validates the digital signature using the
public key stored in the account record. The relying-party-only
certificate containing only an account number and public key (because
of the enormous liability and privacy issues) is never used. It was
subsequently observed that such relying-party-only certificates were
redundant and superfluous.
The original purpose of certificates were to provide various certified
associations for an offline world (something analogous to
letters-of-credit from the days of sailing ships). These certificates
were a stand-in/substitute for situations where it was not possible to
directly access the real information. Most of them are quickly loosing
any reason for existence given the extensive proliferation of internet
and wireless technologies around the world. It is becoming more and
more unlikely that there wouldn't be some form of connectivity
.... especially for transactions or authentication events involving
anything of value or importance.
The semantics of private key is basically something you have
.... however given the vagaries of software computing systems, the
private key can be stored in a hardware token or in a software
encrypted file on a general purpose computer. The software encrypted
file is unlocked with a PIN/password ... given some of the
characteristics of general purpose computers (like personal
computers), any kind of file might be considered publicly copy'able by
anybody in the world. As a result, such an encrypted file .... might
actually be considered something you know authentication (as opposed
to something that you "uniquely" have). A hardware token that
generates the key in the chip and never allows the private key to
leave the chip .... might be considered more representative of
something you have authentication.
A hardware token that requires a PIN/password to operate can be
considered two-factor authentication (something you have and
something you know). Note that in this situation, the business
processes of the token and digital signature technology creates an
environment that can be used to establish something you have (aka
the hardware token). The digital signature technology is not an end in
itself ... just a method of proving that you posses a specific
hardware token (and possibly have knowledge of a specific
PIN/password).
As previously noted .... sometimes there is PKI documentation that
attempts to grossly exaggerate the meaning of a digital signature and
obfuscate the underlying business processes and procedures ....
possibly as part of a sales technique to convince public key owners to
purchase the certificates (obfuscation that attempts to establish
certificates as an end in themselves).
misc. past about relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
replay & integrity
Date: Thu, 10 Jul 2003 07:03:13 -0600
To: "Zooko" <zooko@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: replay & integrity
Cc: iang@xxxxxxxx, "EKR" <ekr@xxxxxxxx>,
"tom st denis" <tomstdenis@xxxxxxxx>, cryptography@xxxxxxxx
At 02:19 PM 7/9/2003 -0400, Zooko wrote:
I'll try to make this concrete. My thesis is different than Ian's --
rather than saying that those apps need less than what TLS offers, I
say that they need more! (So that each app need no longer implement
the added features itself.)
we did two kinds of replay countermeasures ... one for AADS RADIUS
https://www.garlic.com/~lynn/subpubkey.html#radius
and a different kinds for x9.59 (for all electronic payments in all
environments)
https://www.garlic.com/~lynn/x959.html#x959
in the aads radius there is this (real-time) protocol chatter; client
contacts server, server returns message with unique value, client
includes unique value in signed message that is returned to
server. server validates the signature and makes sure the client's
message returns the previously transmitted unique value.
for x9.59 to work in all environments ... it had to operate in single
round trip (as per many of existing financial messages). the client
creates a complete signed message and sends it to the server
(financial institution), the message has some possibly unique values
... but not necessarily guaranteed, including time. the server uses
current time and message time to bracket checking of previously
processed messages for replay.
the radius implementation requires two round-trips to establish the
unique value as part of replay countermeasure.
the x9.59 implementation (in order to meet one of the requirements for
the protocol; perform completely in single round trip) uses a log and
a sort of fuzzy time implementation (at the server). this is in part
because the client end can be considered somewhat unreliable ... not
necessarily being able to reliably remember previous value and/or keep
synchronized time. highly synchronized time could eliminate the log
check. having reliable client that was guaranteed to remember previous
transaction could get by with the log elimination by using a take off
on the single password scheme .... where both the server and the
client reliably remembers just the previously used value, this rmemory
doesn't get out of sync ... and the iteration to the next value is
non-obvious.
and of course the overall requirement given the x9a10 working group
for x9.59 was to preserve the integrity of the financial
infrastructure for all electronic payments in all environments.
E-banking is board-level Issue, Says Basel Committee
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/22/2003 05:02 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: E-banking is board-level Issue, Says Basel Committee ... fyi
http://www.banktech.com/story/enews/BNK20030722S0003
E-Banking Is Board-Level Issue, Says Basel Committee
Ivan Schneider
Jul 22, 2003
Unprecedented speed of change, increased dependence on systems
architecture, more complex operations, and magnified importance of
security -- such are the fruits of e-banking in financial services.
While it does not bring "inherently new risks," electronic banking has
changed the overall industry risk profile, according to the Basel
Committee on Banking Supervision in a July 2003 report. Therefore, the
Committee recommends, banks' senior management and boards of directors
should review and modify existing risk policies where necessary, and
take a more active role in setting the strategic direction of
e-commerce initiatives.
... snip ...
Feds, industry warn of spike in ID theft scams
Refed: **, - **, - **
From: Lynn Wheeler
Date: 07/22/2003 05:06 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Feds, industry warn of spike in ID theft scams
http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,83282,00.html?SKC=security-83282
Feds, industry warn of spike in ID theft scams
A new report shows a dramatic increase in incidents of identity theft
By Paul Roberts, IDG News Service
JULY 21, 2003
The U.S. federal government and EarthLink Inc. warned today of a surge
in unsolicited e-mail and scam Web sites that are designed to steal
the identity of unsuspecting Internet users.
The Atlanta-based Internet service provider has seen a spike since the
beginning of the year in e-mail linked to so-called "phisher" Web site
scams, which use spam to lure victims to Web sites that look like
legitimate retail or corporate sites, according to company spokeswoman
Carla Shaw.
... snip ...
Committee calls for better e-banking security management
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/23/2003 03:58 PM
To: Committee calls for better e-banking security management
Subject: Committee calls for better e-banking security management
http://www.infoworld.com/article/03/07/23/HNebanking_1.html
Committee calls for better e-banking security management
Report lists 14 "best practices" for financial institutions
By Paul Roberts, IDG News Service
July 23, 2003
An influential international banking committee issued a report Tuesday
calling for better security and management of electronic banking
(e-banking) by the world's financial institutions.
The report, "Risk Management Principles for Electronic Banking," was
released by the Basel Committee on Banking Supervision and published
on the Web.
The rapid growth of e-banking in recent years has created a wealth of
new banking products and services, but has also increased banks'
exposure to financial and legal risks, the committee said.
... snip ...
IT Managers Critical Front in War on Identity Theft
From: Lynn Wheeler
Date: 07/23/2003 04:00 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: IT Managers Critical Front in War on Identity Theft
http://itmanagement.earthweb.com/ecom/article.php/2239211
IT Managers Critical Front in War on Identity Theft
July 23, 2003
By Sharon Gaudin
A steady rise in online identity theft should be signaling IT managers
to shore up customer information before they face any further
deterioration in consumer confidence
... snip ...
Draft E-Authentication Policy for Federal Agencies
From: Lynn Wheeler
Date: 07/25/2003 07:28 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Draft E-Authentication Policy for Federal Agencies
https://web.archive.org/web/20030716055158/http://www.estrategy.gov/eapolicydraft.cfm
Draft E-Authentication Policy for Federal Agencies SUMMARY: The
General Services Administration, in coordination with the Office of
Management and Budget (OMB) request comments on the attached draft
policy on E-Authentication for Federal Agencies. GSA has coordinated
this draft policy with OMB and will work closely with OMB in reviewing
comments and issuing the final policy. In this draft policy, GSA is
requiring that agencies implement this E-Authentication Policy, which
establishes four assurance levels to create a Governmentwide standard
framework for determining what is required to access a particular
Government transaction online.
DATES: To ensure consideration of comments, comments must be in
writing and received by GSA no later than August 11, 2003.
ADDRESSES: Comments on this notice should be addressed to Ms. Von
Harrison, General Services Administration; Office of Electronic
Government and Technology (MEI), Washington, DC 20405. You are
encouraged to submit these comments by facsimile to (202) 501-6455, or
by electronic mail to egov.taskforce@xxxxxxxx FOR FURTHER INFORMATION
CONTACT: Ms. Von Harrison, General Services Administration, Office
and Electronic Government and Technology (MEI), Washington, DC 20405;
or by phone at (202) 273-0721.
The Best ID Plan? Wait and See
From: Lynn Wheeler
Date: 07/25/2003 07:59 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: The Best ID Plan? Wait and See
http://www.eweek.com/category2/0,3960,1184404,00.asp
The Best ID Plan? Wait and See
Tech Analysis: The major players in the ID management arena are still
far enough apart to warrant that IT managers proceed with caution in
plotting courses toward managing identity.
... snip ...
IT Security to be added to FAR
From: Lynn Wheeler
Date: 07/25/2003 08:02 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: IT Security to be added to FAR
https://web.archive.org/web/20040512164032/http://www.washingtontechnology.com/news/1_1/daily_news/21287-1.html
07/24/03
IT security to be added to FAR
By William Jackson
PostNewsweek Tech Media
The General Services Administration is drafting a Federal Acquisition
Regulation addition to integrate security into IT buys.
Joan Hash, director of security management assistance in the National
Institute of Standards and Technology’s Computer Security Division,
made the announcement today during a discussion of government
cybersecurity requirements at the GOVSEC security conference in
Washington.
... snip ...
Kinko's spy case: Risks of renting PC's
From: Lynn Wheeler
Date: 07/25/2003 08:05 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Kinko's spy case: Risks of renting PC's
https://web.archive.org/web/20030726051209/http://www.cnn.com/2003/TECH/internet/07/23/cybercafe.security.ap/index.html
Kinko's spy case: Risks of renting PCs
Wednesday, July 23, 2003 Posted: 9:08 AM EDT (1308 GMT)
NEW YORK (AP) -- For more than a year, unbeknownst to people who used
Internet terminals at Kinko's stores in New York, Juju Jiang was
recording what they typed, paying particular attention to their
passwords.
Jiang had secretly installed, in at least 14 Kinko's copy shops,
software that logs individual keystrokes. He captured more than 450
user names and passwords, and used them to access and open bank
accounts online.
... snip ...
AADS Postings and Posting Index,
next, previous
- home