X9.59 mailing list
x959 Postings and Posting Index,
next, previous
- home
- identity, fingerprint, from comp.risks
- Sun releases Liberty-enabled software
- Sun releases Liberty-enabled software
- Ministers to Act on Rise in Identity Theft
- misc. IETF e-commerce announcements (from IOTP working group)
- Self-Regulating SSL Certificate Authority
- A Look into Banking Trends for 2003
- FTC says incidence of ID theft jumped in 2002
- Internet Consumer Fraud Continues to Rise
- Bank of America ATMs Disrupted by Virus
- E-Commerce Standard Plans Made Public
- Bank of America ATMs Disrupted by Virus
- Star study: Identity Theft In The United States: An Update
- Microsoft Fixes Passport to Meet EU Privacy Rules
- More Identity Theft ... Security Stands in Line Behind Other Priorities
- NIST recommends dual biometrics for visas
- E-Authentication gateway draws interest outside of e-gov projects
- Criminals using high-tech methods for old-style crimes
- Hacker accesses 2.2 million credit cards
- Japan seeks smarter ideas for smart cards
- XACML Access Control Markup Language Ratified as OASIS Open Standard
- Solving the problem of micropayments
- FBI Probing Theft of 8 Million Credit Card Numbers
- DOD Prepares for biometric embedded smart card pilot
- Motorola goes with USB On-the-Go
- CMS sets health care e-payment standards
- CMS sets health care e-payment standards
- Solving the problem of micropayments
- Solving the problem of micropayments
- CIOs Must Be Involved In Controlling Risk In Financial Services
- Iris recognition helps to prevent ID fraud
- Privacy again a hot-button issue for legistlators
- Don't-Ask-Don't-Tell E-commerce
- Spam's Being Used For Identity Theft And Blackmail, Symantec Says
- Recent IOTP and ECML publications
- X9/03 LB#8 - Formation of a New Subcommittee - X9C
- Amazon/Bezos: web advertising patent
- Who's afraid of Mallory Wolf?
- Card Technology Forecast: 2004-2009
- related to electronic contracting (new X9C group)
- ID theft costs banks $1 billion a year
- Be Prepared: Gartner Outlines Top Security Risks
- Bank Float May Sink
- Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)
- First Data buying Concord EFS
- Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)
- Bank of America's Trade Finance Strategy
- Actual Losses To Identity Fraud Top $1 Billion
- Blackboard Gets Gag Order Against Smart-Card Hackers
- A More Anonymous Internet
- Concern Grows About ID Theft
- Nokia, MasterCard test wireless payment
- Visa, Philips team to promote 'contactless' credit card
- Authentication white paper
- FINREAD was. Authentication white paper
- FINREAD ... and as an aside
- FINREAD was. Authentication white paper
- US warns banks about virus
- PKI's not working
- US warns banks about virus ... another ref:
- PKI's not working
- HIPAA, privacy, identity theft
- HIPAA, privacy, identity theft (addenda)
- E-merchants Turn Fraud-busters
- EFTA to Adaopt ATM Ant-Fraud Measures
- E-merchants Turn Fraud-busters (somewhat related)
- Confusing Authentication and Identiification?
- Confusing Authentication and Identiification?
- Confusing Authentication and Identiification?
- Confusing Authentication and Identiification?
- Confusing Authentication and Identiification? (addenda)
- Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
- Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
- Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
identity, fingerprint, from comp.risks
From: Lynn Wheeler
Date: 01/06/2003 07:32 PM
To: epay@xxxxxxxx
Subject: identity, fingerprint, from comp.risks
Date: Sun, 05 Jan 2003 01:09:40 +0000
From: Markus Kuhn <Markus.Kuhn@xxxxxxxx>
Subject: Risks of diverse identification documents
The Home Office is currently running a consultation exercise on the
introduction of an identity infrastructure for Britain. This would consist
of a biometric database with basic records of the entire population. Anyone
in the database would be able to get an identity card, which would
essentially enable the holder to grant easily read access to his or her
record to any peer who needs some form of assurance about one's
identity. Details on the consultation are on
http://www.homeoffice.gov.uk/dob/ecu.htm
The system proposed is nothing unusual and quite similar to what most
European and many Asian countries have used successfully for several
decades.
Such identity infrastructures are generally widely accepted in these
countries, where most people consider them today to be a desirable and
effective protection against what has become known in some countries that
still lack them as "identity theft".
Nevertheless, there is fierce opposition to the proposals from various
British privacy advocacy groups. Similar discussions can be observed at the
moment in the US and Japan.
While much of the opposition is of a somewhat religious/tinfoil-hat nature
and therefore difficult to address, some of it has been voiced by notable
computer-security experts and therefore deserves some serious response.
The probably most commonly recurring theme is that the introduction of
a national identity card would lead to over-reliance on a single
document. The need to corrupt only the issuing procedures of a single
mechanism -- so the often expressed concern -- would ultimately make
identity theft easier rather than harder. This is probably based on
the implicit assumption that independent identity systems perform
independent checks with statistically independent failure
probabilities. Therefore their security should increase exponentially
with the number of verification systems and more would be better.
Defense-in-depth and its use of multiple diverse security mechanisms
is in general a feature of sound security engineering. However,
applying this general idea in the context of government
infrastructures against identity theft this way is in my opinion
horribly wrong and naive for a number of reasons, which I'd like to
address very briefly.
The most obvious problem is that the UK's present alternative --
identification based on multiple documents and issuing procedures --
adds very little as none of the currently widely available documents
is protected by controls of desirable strength. This is just
illustrated again by recent media demonstrations on how easily it is
to abuse UK birth certificates:
http://news.bbc.co.uk/1/hi/programmes/kenyon_confronts/2625395.stm
In practice, anyone wishing to verify an identity gets only the
minimal protection of all the ID schemes in common use, because as
soon as you break one of them, you can quite easily proliferate your
fake identity into several other systems. Get a fake UK birth
certificate (fairly easy) and apply with it for a fake UK drivers
license (therefore also not much more difficult), use both to get a
fake UK passport and all three to comfortably get fake account access,
education degrees, travel documents, security clearances, etc. etc.
Most of the existing systems depend on each other, which leads easily
to circular verification (A thinks B knows I and B thinks A knows I).
They all lack the somewhat more expensive direct checks of
non-document evidence that for example a properly protected
distributed add-only database of the biometric long-term history of
those registered could support economically and effectively.
Multiple documents? Unfortunately, the world of fake ID documents
currently works more like "Buy one, get three more free!" The number
of systems doesn't count much after all.
But this is not the only reason why it is so crucial to have at least
one identification scheme that is seriously difficult to break, while
having more than one of these is unlikely to be worth the cost and
hassle.
There is first of all also the problem that within a single
infrastructure, it is far easier for those in charge of its integrity
to verify and ensure that the overall policies such as the separation
of duties for critical checks really leads to checks that are
independent by design, and not by chance.
Another reason is that the costs for the training/equipment/time/etc.
necessary for the adequate verification of security documents
increases at least linearly with the number of different document
types accepted. And the risk of fraudsters finding by brute-force
search one accepted type of identification for which a particular
verifier is not well prepared to recognize comparatively simple fakes
increases even exponentially with the overall number of different
identification forms accepted.
Hence I am not surprised by the desire in the UK government to finally
also offer its tax payers one single simple cheap properly engineered
and run identity infrastructure. It is needed to replace all the
existing often ridiculously weak alternatives (including old birth
certificates, old driving licenses, magstripe-cards, knowing mother's
maiden name or showing a laser-printed utility bill) that are all
currently used by especially the UK financial industry as acceptable
means for gaining access to critical personal information and
property.
Perhaps the discussion should first of all be driven by comparing
actual practical identity-theft versus privacy-violation statistics in
countries with and without proper government-provided identification
infrastructures, instead of naively applying generic security recipes
such as more-mechanisms-are-better to an application area with far
more specific properties.
Markus Kuhn, Computer Lab, Univ of Cambridge, GB
http://www.cl.cam.ac.uk/~mgk25/
Sun releases Liberty-enabled software
Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/13/2003 08:58 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Sun releases Liberty-enabled software
http://news.com.com/2100-1001-980266.html?tag=fd_top
... snip ...
Wells Fargo has been using the test version to handle authentication
on several parts of its online banking site, Barco said. Liberty makes
sure a customer signed on to the online banking system, for example,
can get to the bill payment system or the brokerage system without
having to log in to each one.
.. snip ...
==============
above article references liberty
http://www.projectliberty.org/home.html
being based on the security assertion markup language
http://www.oasis-open.org/committees/security/
last week i ran across somebody using SAML ... to effectively
re-implement Kerberos ... but in place of kerberos tickets there were
these packets of SAML formated information.
Somewhat related is the Security Services TC glossary ... which
includes references to the federated/merged security glossary on the
garlic web pages:
http://www.oasis-open.org/committees/security/docs/draft-sstc-hodges-glossary-01.html
slightly related Kerberos reference:
https://www.garlic.com/~lynn/2003.html#50 Origin of Kerberos
the SAML webpage also references the AAA series of RFCs. Click on
https://www.garlic.com/~lynn/rfcietff.htm
and in the RFCs listed by section, click on Term (term->RFC#).
and scroll down to:
Authentication, Authorization and Accounting
see also accounting , authentication , authorization
3127 2989 2977 2906 2905 2904 2903
Sun releases Liberty-enabled software
From: Lynn Wheeler
Date: 01/14/2003 08:00 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Sun releases Liberty-enabled software
additional articles:
http://www.computerworld.com/hardwaretopics/hardware/server/story/0,10801,77522,00.html
http://itmanagement.earthweb.com/entdev/article.php/1568391
Ministers to Act on Rise in Identity Theft
From: Lynn Wheeler
Date: 01/15/2003 06:12 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Ministers to Act on Rise in Identity Theft
http://www.timesonline.co.uk/article/0,,2087-532826,00.html
The Sunday Times - Britain
January 05, 2003
Ministers to act on huge rise in stolen identities
Jon Ungoed-Thomas and Edin Hamzic
THE identity of David Blunkett has been "stolen" by a reporter who was
able to use a copy of the home secretary's birth certificate to obtain
a provisional driving licence. Blunkett's name and date of birth
appear on the licence.
The use of the certificate, legally obtained, to get a licence in
Blunkett's name has highlighted the growing threat posed by identity
fraud. The government is now planning new laws to curb the practice.
Last night, Beverley Hughes, the Home Office minister, said measures
could include tighter checks on the identity of those seeking copies
of birth certificates and other documents.
"If we are to protect people better from this growing threat, we would
need to make more stringent checks," said Hughes.
The hijacking by conmen of victims' details, usually to obtain fake
documents or steal money, has tripled in the past two years, according
to new figures. Banks, building societies and financial institutions
reported more than 40,000 cases of identity fraud in 2002 compared
with fewer than 13,000 cases in 2000.
Conmen often create new identities by trawling through bins,
collecting bills and bank statements that can be used to build up the
false identity.
A birth certificate can be obtained with no requirement to prove
identity. The name on the certificate can be entered on the electoral
roll with no checks. Utility bills and a driving licence can then be
obtained.
Henri Cash, 45, a West Sussex businessman, fell victim to a conman who
ran up 30,000 pounds of debts in his name after "stealing" his
identity.
"This person was allowed to use my credit history without any proper
checks," said Cash.
In a BBC1 investigation to be shown on Wednesday, the journalist
Paul Kenyon, who obtained the Blunkett driving licence, also managed
to get a licence and bank account in the name of Frederick Forsyth.
The Day of the Jackal, Forsyth's novel that was made into a film in
1973, featured an assassin who assumed the identity of a dead child.
misc. IETF e-commerce announcements (from IOTP working group)
From: Lynn Wheeler
Date: 01/21/2003 01:15 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: misc. IETF e-commerce announcements (from IOTP working group)
From: The IESG <iesg-secretary@xxxxxxxx>
Subject: Document Action Electronic Commerce Modeling Language (ECML) Version 2 Requirements to Informational
Date: Tue, 21 Jan 2003 133520 -0500
The IESG has approved the Internet-Draft 'Electronic Commerce Modeling
Language (ECML)Version 2 Requirements'
<draft-ietf-trade-ecml2-req-05.txt> as an Informational RFC. This
document is the product of the Internet Open Trading Protocol Working
Group. The IESG contact persons are Ned Freed and Patrik Faltstrom.
From: The IESG <iesg-secretary@xxxxxxxx>
Subject Document Action Internet Open Trading Protocol (IOTP) Version 1, Errata to Informational
Date: Tue, 21 Jan 2003 133547 -0500
The IESG has approved the Internet-Draft 'Internet Open Trading
Protocol (IOTP) Version 1, Errata'
<draft-ietf-trade-iotp-v1-errata-01.txt> as an Informational RFC.
This document is the product of the Internet Open Trading Protocol
Working Group. The IESG contact persons are Ned Freed and Patrik
Faltstrom.
From: The IESG <iesg-secretary@xxxxxxxx>
Subject: Document Action Requirements and Design for Voucher Trading System (VTS) to Informational
Date: Tue, 21 Jan 2003 133421 -0500
The IESG has approved the Internet-Draft 'Requirements and Design for
Voucher Trading System (VTS)'
<draft-ietf-trade-drt-requirements-04.txt> as an Informational RFC.
This document is the product of the Internet Open Trading Protocol
Working Group. The IESG contact persons are Ned Freed and Patrik
Faltstrom.
Self-Regulating SSL Certificate Authority
From: Lynn Wheeler
Date: 01/22/2003 07:13 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Self-Regulating SSL Certificate Authority
somewhat related to SSL certificate threads from last month:
https://www.garlic.com/~lynn/aepay10.htm#78
https://www.garlic.com/~lynn/aepay10.htm#79
https://www.garlic.com/~lynn/aepay10.htm#81
https://www.garlic.com/~lynn/aepay10.htm#82
https://www.garlic.com/~lynn/aepay10.htm#83
http://ask.slashdot.org/askslashdot/03/01/21/207244.shtml?tid=93
Posted by Cliff on Tuesday January 21, @05:05PM from the doing-it-on-our-own dept.
bcg asks: "It has come that time again to renew some of my SSL
certificates and part with substantial amounts of cash. This has got
me thinking - why should we pay large amounts of cash for authorized
certs when so little is done by the companies issuing them? Sure they
get you to send them a copy of a business certificate but how does
this prove the character of those running the SSL server? What ideas
can we come up with for a self-regulating certification authority?
Could we set something up along the lines of the many free DNS servers
around but use it to authenticate SSL certs?" We last touched on this
subject in October, when someone was searching for cheap SSL
certs. We've also discussed why certs are so expensive. Why not take
it one step further and discuss ways of making and authenticating our
own certs for free...or as close to free as possible?
A Look into Banking Trends for 2003
From: Lynn Wheeler
Date: 01/22/2003 08:30 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: A Look into Banking Trends for 2003
http://www.banktech.com/story/BSTeNews/BNK20030117S0002
A Look into Banking Trends for 2003
Alenka Grealish, Celent Communications
Jan 17, 2003
Heightened competition from non-banks, a persistent bearish market,
and a general erosion of consumer confidence will continue to
influence banks' IT decisions in 2003. In particular, Celent expects
banks to step up their privacy, security, and risk management
efforts. In addition, banks will tackle two daunting areas in need of
an overhaul: check processing and core processing. Within retail
banking, we predict that investment in multi-channel integration and
customer knowledge will continue to expand and that these projects
will come to fruition within the next three years. In wholesale
banking, banks will further harness Internet-enabled technologies to
improve customer offerings and service.
Banks will pay more attention to privacy and identity theft concerns
... snip ...
FTC says incidence of ID theft jumped in 2002
Refed: **, - **, - **
From: Lynn Wheeler
Date: 01/22/2003 09:00 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: FTC says incidence of ID theft jumped in 2002
http://www.computerworld.com/securitytopics/security/privacy/story/0,10801,77792,00.html
FTC says incidence of ID theft jumped in 2002
By PATRICK THIBODEAU
JANUARY 22, 2003
Content Type: Story
Source: Computerworld
WASHINGTON -- The Federal Trade Commission today said that reported cases
of identity theft increased nearly 88% last year. But some experts say the
numbers may only be disclosing a fraction of the overall problem.
The FTC last year received 161,800 identity theft complaints, up from
86,200 in 2001, according to its annual report on consumer fraud.
ID theft accounted for 43% of all fraud complaints the FTC received last
year, the agency said in a statement. The number of fraud complaints
overall increased by nearly 73%, from 220,000 to 380,000. The cost for all
fraud reached $343 million.
FTC officials said the increase may be due in part to agency efforts to
encourage victims to file complaints, as well as increased participation
from public and private agencies that report fraud. Those agencies include
the Social Security Administration's Office of Inspector General and many
Better Business Bureaus in the U.S.
But one private survey released earlier this month by Maitland, Fla.-based
Star Systems, a Concord EFS Inc. subsidiary, found that one in 20 adults,
or about 11.8 million people in the U.S., have been victims of identity
theft. Those results came from an independent, third-party telephone
survey.
... snip ...
Internet Consumer Fraud Continues to Rise
From: Lynn Wheeler
Date: 01/23/2003 05:20 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Internet Consumer Fraud Continues to Rise
http://itmanagement.earthweb.com/ecom/article.php/1573071
Internet Consumer Fraud Continues to Rise
January 22, 2003
By Roy Mark
The Internet tops the list of the Federal Trade Commission's (FTC)
annual report detailing consumer complaints about identity theft and
listing the top 10 fraud complaint categories reported by
consumers. According to the FTC, 47 percent of non-identity theft
complaints were Internet-related, a 31 percent increase since 2000.
As in 2000 and 2001, identity theft topped the list, accounting for 43
percent of the complaints lodged in the FTC's Consumer Sentinel
database. The number of fraud complaints jumped from 220,000 in 2001
to 380,000 in 2002, and the dollar loss consumers attributed to the
fraud they reported grew from $160 million in 2001 to $343 million in
2002.
Bank of America ATMs Disrupted by Virus
From: Lynn Wheeler
Date: 01/25/2003 06:11 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Bank of America ATMs Disrupted by Virus
http://www.washingtonpost.com/wp-dyn/articles/A43267-2003Jan25.html
Bank of America ATMs Disrupted by Virus
Saturday, January 25, 2003; 5:33 PM
SEATTLE (Reuters) - Bank of America Corp. said on Saturday that customers
at a majority of its 13,000 automatic teller machines were unable to
process customer transactions after a malicious computer worm nearly froze
Internet traffic worldwide.
Bank of America spokeswoman Lisa Gagnon said by phone from the company's
headquarters in Charlotte, North Carolina, that many, if not a majority of
the No. 3 U.S. bank's ATMs were back online and that their automated
banking network would recover by late Saturday.
.. snip ...
E-Commerce Standard Plans Made Public
From: Lynn Wheeler
Date: 01/28/2003 12:15 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: E-Commerce Standard Plans Made Public
http://itmanagement.earthweb.com/ecom/article.php/1575471
E-Commerce Standard Plans Made Public
January 28, 2003
By Thor Olavsrud
E-business interoperability consortium OASIS Tuesday said the first
draft of a royalty-free data method for international electronic
commerce has been released by one of its technical groups.
The new OASIS schemas encompass the Universal Business Language
(UBL). UBL is a standard for XML (define) document formats that encode
business messages, such as purchase orders and invoices. UBL treats
business-to-business (B2B) communication across all industry sectors
and domains for all types of organizations, including small- and
medium-sized enterprises.
..snip..
Bank of America ATMs Disrupted by Virus
From: Lynn Wheeler
Date: 01/29/2003 11:21 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Bank of America ATMs Disrupted by Virus
aka
https://www.garlic.com/~lynn/aepay11.htm#9
http://www.washingtonpost.com/wp-dyn/articles/A43267-2003Jan25.html
somewhat related thread in comp.security.misc thread
https://www.garlic.com/~lynn/2003b.html#53 Microsoft worm affecting Automatic Teller Machines
https://www.garlic.com/~lynn/2003b.html#54 Microsoft worm affecting Automatic Teller Machines
https://www.garlic.com/~lynn/2003b.html#55 Microsoft worm affecting Automatic Teller Machines
Star study: Identity Theft In The United States: An Update
From: Lynn Wheeler
Date: 01/29/2003 04:46 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Star study: Identity Theft In The United States: An Update
http://www.star-systems.com/news-industryresearch.html
Microsoft Fixes Passport to Meet EU Privacy Rules
From: Lynn Wheeler
Date: 01/30/2003 08:36 AM
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Microsoft Fixes Passport to Meet EU Privacy Rules
http://story.news.yahoo.com/news?tmpl=story2&cid=569&ncid=738&e=1&u=/nm/20030130/tc_nm/tech_microsoft_eu_dc
Microsoft Fixes Passport to Meet EU Privacy Rules
1 hour, 2 minutes ago
By Lisa Jucca and Tom Miles
BRUSSELS (Reuters) - The European Commission (news - web sites) said
on Thursday that software giant Microsoft had agreed to make "radical"
changes to its .NET Passport system to ease concerns about data
privacy posed by Internet identity systems.
The agreement settles a half-year long examination by European Union
(news - web sites) privacy watchdogs into on-line authentication
systems such as Passport.
"Microsoft has agreed to implement a comprehensive package of data
protection measures, which will mean making substantial changes to the
existing .NET passport system," the Commission said in a statement. No
details were given.
Jonathan Todd, a spokesman for the European Union's executive body,
said it was now unlikely that the Passport system, used to identify
Internet users, would fall foul of government data protection rules in
the 15-country bloc.
..snip..
More Identity Theft ... Security Stands in Line Behind Other Priorities
From: Lynn Wheeler
Date: 02/03/2003 11:09 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: More Identity Theft ... Security Stands in Line Behind Other Priorities
http://www.informationweek.com/story/IWK20030131S0001
Security Stands In Line Behind Other Priorities
Feb. 3, 2003
By George V. Hulme
What's a company to do? The Federal Trade Commission reports that
identity theft is skyrocketing, and the 2002 CSI/FBI Computer Crime
and Security survey places the average loss to financial fraud at $4.6
million and the average cost of a virus attack at $283,000. For the
most part, short-sighted priorities get in the way of effective
security efforts.
Half of the business-technology executives in Gartner's U.S. Security
Services 2002 survey report that other projects take precedence over
IT security. When IT security is a low priority, those charged with
establishing and enforcing its policies lose leverage, and security
managers aren't able to convince budget holders to pay for the cost of
security products.
..snip..
NIST recommends dual biometrics for visas
From: Lynn Wheeler
Date: 02/12/2003 03:14 PM
To: epay@xxxxxxxx
Subject: NIST recommends dual biometrics for visas
http://www.washingtontechnology.com/news/1_1/daily_news/20069-1.html
http://www.gcn.com/vol1_no1/daily-updates/21141-1.html
02/12/03
NIST recommends dual biometrics for visas
By Kevin McCaney
GCN Staff
The National Institute of Standards and Technology is recommending a
dual biometric system of fingerprint and facial recognition, possibly
stored on smart cards, to identify visa holders at the nationÂ’s
borders.
"With two fingerprints and a face, youÂ’d have quite a secure
system," said Charles Wilson, manager of the Imaging Group in
NISTÂ’s Information Technology Laboratory.
NIST delivered its recommendations in a report to Congress after
conducting a study last year as mandated by the USA Patriot Act of
2001 and the Enhanced Border Security and Visa Entry Reform Act of
2002.
The report recommended placing two fingerprints on each card "noting
that thumbs produce the highest accuracy rates, followed by the index
and middle fingers" combined with facial scanning. NIST said each
image, whether of a fingerprint or face, would take up 10K or less of
storage, for a total within the capacity of many smart cards.
... snip ...
E-Authentication gateway draws interest outside of e-gov projects
From: Lynn Wheeler
Date: 02/12/2003 03:17 PM
To: epay@xxxxxxxx
Subject: E-Authentication gateway draws interest outside of e-gov projects
http://www.gcn.com/vol1_no1/daily-updates/21143-1.html
2/12/03
E-Authentication gateway draws interest outside of e-gov projects
By Jason Miller
GCN Staff
While the E-Authentication project, considered a main cog in the
e-government wheel, is having trouble getting funds from partner
agencies, IT leaders outside of the 24 Quicksilver projects are
clamoring to use the gateway. But those project leaders might have to
wait because funding problems have pushed back the timetable for a
full launch of the system.
Adrian Fish, deputy project manager for E-Authentication, yesterday
said agency partners have been slow to pony up funding for the gateway
because some agencies havenÂ’t realized the benefits.
"We have been working with our partner agencies so they see the
value of the gateway. But I think as they see applications come on and
the money [the gateway] is saving them, the value is being
demonstrated," she said. "We are going back to drawing board to
try to get more money from partner agencies."
Agencies requested $8.1 million for E-Authentication in the fiscal
2004 budget the administration submitted to Capitol Hill last
week. That is down from the $12.1 million agencies requested in 2003.
While some E-Authentication partners are reticent, other government
project leaders have been keeping her phone busy with interest in the
gateway, Fish said.
.. snip ...
Criminals using high-tech methods for old-style crimes
From: Lynn Wheeler
Date: 02/14/2003 08:56 AM
To: epay@xxxxxxxx
Subject: Criminals using high-tech methods for old-style crimes
http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,78531,00.html
Criminals using high-tech methods for old-style crimes
By DAN VERTON
FEBRUARY 13, 2003
MASHANTUCKET, Conn. -- Organized crime rings that employ people with
violent criminal records are increasingly trading their automatic
weapons for automatic software tools that enable them to conduct a
wide array of white-collar crimes such as identity theft and fraud.
As many as 700,000 people fall victim to identity theft and other
forms of Internet fraud every year, but vast differences among the
methods and perpetrators of such crimes can make investigating them
difficult, said James Doyle, president of Madison, Conn.-based
Internet Crimes Inc. Doyle, a co-founder of the New York Police
Department's Computer Investigation and Technology Unit, spoke at the
Cybercrime 2003 conference here this week.
.. snip ...
Hacker accesses 2.2 million credit cards
From: Lynn Wheeler
Date: 02/17/2003 09:59 PM
To: epay@xxxxxxxx
Subject: Hacker accesses 2.2 million credit cards
http://www.cnn.com/2003/TECH/02/17/creditcard.hack/index.html
Japan seeks smarter ideas for smart cards
From: Lynn Wheeler
Date: 02/17/2003 10:00 PM
To: epay@xxxxxxxx
Subject: Japan seeks smarter ideas for smart cards
http://www.cnn.com/2003/TECH/ptech/02/17/japan.smart.cards.ap/index.html
XACML Access Control Markup Language Ratified as OASIS Open Standard
From: Lynn Wheeler
Date: 02/18/2003 03:36 PM
To: epay@xxxxxxxx
Subject: XACML Access Control Markup Language Ratified as OASIS Open Standard
Universal Language for Authorization Policy Enables Secure Web Services
http://www.oasis-open.org/news/oasis_news_02_18_03.shtml
Solving the problem of micropayments
From: Lynn Wheeler
Date: 02/19/2003 12:05 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Solving the problem of micropayments
http://www.peppercoin.com/
http://www.boston.com/dailyglobe2/048/business/Solving_the_problem_of_micropayments+.shtml
Solving the problem of micropayments
By Hiawatha Bray, Globe Staff, 2/17/2003
IT professor Ron Rivest has come up with a new way to throw away money
on the Internet. With luck, it'll make him a fortune. Rivest is one of
the three people who devised the encryption system that allows us to
transmit our credit- card information safely over the Internet. The
company that grew out of this work, Bedford-based RSA Security Inc.,
is one of the leaders in the field. He's a fellow of the American
Academy of Arts and Sciences and the Association of Computing
Machinery. Put it this way: Rivest knows what he's doing. So what's
all this about throwing away money?
... snip ...
FBI Probing Theft of 8 Million Credit Card Numbers
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 02/20/2003 08:17 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: FBI Probing Theft of 8 Million Credit Card Numbers
... up from earlier reports of 2.2 million
http://story.news.yahoo.com/news?tmpl=story&u=/nm/20030220/wr_nm/crime_creditcards_dc_3
general vulnerability threads
https://www.garlic.com/~lynn/subintegrity.html#fraud
threads specific mention of harvesting credit card numbers
https://www.garlic.com/~lynn/aadsm5.htm#asrn4 assurance, X9.59, etc
https://www.garlic.com/~lynn/aadsm6.htm#websecure merchant web server security
https://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror8 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aepay6.htm#harvest harvesting of credit card numbers
https://www.garlic.com/~lynn/aepay6.htm#harvest2 shared-secrets, CC#, & harvesting CC#
https://www.garlic.com/~lynn/aepay6.htm#erictalk Announce: Eric Hughes giving Stanford EE380 talk this
https://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#ssexploit Shared-Secret exploit
https://www.garlic.com/~lynn/aepay7.htm#netbank net banking, is it safe?? ... power to the consumer
https://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
https://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
https://www.garlic.com/~lynn/aadsm10.htm#bio5 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
https://www.garlic.com/~lynn/aadsm12.htm#51 Frist Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#57 eBay Customers Targetted by Credit Card Scam
https://www.garlic.com/~lynn/aadsm12.htm#60 signing & authentication (was Credit Card Scam)
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001d.html#19 [Newbie] Authentication vs. Authorisation?
https://www.garlic.com/~lynn/2001f.html#24 Question about credit card number
https://www.garlic.com/~lynn/2001f.html#25 Question about credit card number
https://www.garlic.com/~lynn/2001f.html#52 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001f.html#54 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001f.html#55 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001f.html#57 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001g.html#0 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#29 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001g.html#63 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#5 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#37 Credit Card # encryption
https://www.garlic.com/~lynn/2001h.html#53 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#58 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#66 UUCP email
https://www.garlic.com/~lynn/2001h.html#68 Net banking, is it safe???
https://www.garlic.com/~lynn/2001h.html#70 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#57 E-commerce security????
https://www.garlic.com/~lynn/2002h.html#40 [survey] Possestional Security
https://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates
https://www.garlic.com/~lynn/2002m.html#19 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
https://www.garlic.com/~lynn/2002q.html#52 Big Brother -- Re: National IDs
DOD Prepares for biometric embedded smart card pilot
From: Lynn Wheeler
Date: 02/20/2003 08:20 AM
To: epay@xxxxxxxx
Subject: DOD Prepares for biometric embedded smart card pilot
http://www.gcn.com/vol1_no1/daily-updates/21180-1.html
02/20/03
DOD prepares for biometric- embedded smart card pilot
By Dipka Bhambhani
GCN Staff
The Defense DepartmentÂ’s Biometrics Management Office plans to
complete its last proof of concept for a biometric- enabled Common
Access Card by the end of April and start a pilot as early as this
summer.
Late last month, the BMO awarded BearingPoint Inc., a systems
integration consultant of McLean, Va., a $1.2 million contract to
develop a proof of concept for a biometric-enabled contactless smart
card which includes systems and uses for the cards.
BearingPoint, the prime contractor, awarded SAFLINK Corp. of Bellevue,
Wash., developer of biometric application software $137,000 to help it
find uses for biometrics for wireless physical access control.
.. snip ...
Motorola goes with USB On-the-Go
From: Lynn Wheeler
Date: 02/20/2003 08:22 AM
To: epay@xxxxxxxx
Subject: Motorola goes with USB On-the-Go
http://news.com.com/2100-1033-985217.html?tag=fd_top
Motorola goes with USB On-the-Go
By Richard Shim
Staff Writer, CNET News.com
February 19, 2003, 5:35 PM PT
Emerging connectivity technology USB On-the-Go is gradually becoming
the de facto wired standard, gaining more momentum from a licensing
deal with chipmaker Motorola.
More than 1.3 billion devices in the market have ports for USB, which
became a widely used connectivity technology when Intel integrated it
into its chipsets in 1998. TransDimension is looking to make USB
On-the-Go as prevalent in mobile devices as USB is in PCs and PC
peripherals by striking licensing deals with manufacturers whose
chipsets are used in portable devices.
.. snip ...
CMS sets health care e-payment standards
From: Lynn Wheeler
Date: 02/22/2003 05:53 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: CMS sets health care e-payment standards
http://www.computerworld.com/governmenttopics/government/policy/story/0,10801,78722,00.html
CMS sets health care e-payment standards
By Bob Brewin
FEBRUARY 21, 2003
Source: Computerworld
The Centers for Medicare & Medicaid Services (CMS) yesterday published
its final rules for electronic health care payment transactions
(download PDF), adding what vendors and consultants see as yet another
burden to an industry scrambling to meet new privacy and electronic
security requirements (see story).
.. snip ...
CMS sets health care e-payment standards
From: Lynn Wheeler
Date: 02/23/2003 08:52 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: CMS sets health care e-payment standards
related ....
10) HIPAA Final Security Rule Summarized
Steve Weil has just completed summarizing 289 pages of HIPAA
legislation in a 6.5 page word document that we have posted at:
http://www.sans.org/projects/hipaa.php
He did a fantastic job of laying out the issues; it could serve as
an outline for a community consensus research document. If you are
interested in contributing to a short book on Implementing HIPAA Step
by Step, drop me a note, stephen@xxxxxxxx.
Solving the problem of micropayments
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 02/23/2003 10:12 AM
To: Alanslater@xxxxxxxx
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx,
rah@xxxxxxxx, tboyle@xxxxxxxx
Subject: Re: Solving the problem of micropayments
note that the industry has somewhat addressed that with the stored
value cards (that you find at video stores, coffee houses, department
stores, book stores, grocery stores, drug stores, etc). The same POS
terminals now process debit cards, credit cards, and stored value
cards .... effectively all going to the same backend merchant
processor .... and the backend merchant processor routing the
transaction as appropriate.
as previously noted .... to some extent europe went with stored-value
chip cards doing offline transactions because of the telco
infrastructure barrier in the 80s & 90s (availability and
costs). there wasn't a similar telco barrier in the US .... and
effectively the same stored-value facility was provided by online
transactions thru the existing POS infrastructure.
at 100,000 feet, the credit, debit and stored-value transaction
processing is nearly the same .... modulo various regulatory issues.
and of course ... x9.59 was designed to provided authenticated, secure
transactions .... regardless of the kind of transactions. x9.59 ref:
https://www.garlic.com/~lynn/x959.html#x959
misc. past stored-value refs:
https://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash
https://www.garlic.com/~lynn/aadsm2.htm#straw AADS Strawman
https://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
https://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
https://www.garlic.com/~lynn/aadsm7.htm#pcards4 FW: The end of P-Cards?
https://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
https://www.garlic.com/~lynn/aadsm9.htm#cfppki12 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#smallpay Small/Secure Payment Business Models
https://www.garlic.com/~lynn/aadsm11.htm#29 Proposal: A replacement for 3D Secure
https://www.garlic.com/~lynn/aadsm12.htm#31 The Bank-model Was: Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#51 Frist Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aepay10.htm#10 InfoSpace Buys ECash Technologies
https://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
https://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#24 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#36 economic trade off in a pure reader system
https://www.garlic.com/~lynn/2002d.html#41 Why?
https://www.garlic.com/~lynn/2002e.html#14 EMV cards
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#22 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#23 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002f.html#34 Security and e-commerce
https://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
https://www.garlic.com/~lynn/2002f.html#40 e-commerce future
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#19 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#14 So how does it work... (public/private key)
alanslater@xxxxxxxx on 2/23/2003 7:29 am wrote:
Unfortunately, those nice things that banks have come with a
significant cost infrastructure. It is that infrastructure that makes
micropayments cost prohibitive. For example, suppose someone decided
to compile a CD of the tunes he likes. He downloads several hundred
songs. He would have to pay for each song (post Napster) and each
song would generate a transaction. Consider what would be required to
post each micropoayment (think of lines of print on a checking account
statement -- required, the additional number of pages, additional
postage, additional disk space to support online lookups, etc.). Then
consider that the bank has to have the infrastructure to support
investigations of each of the charges. The cost adds up quickly.
The solutions we had worked on always involved aggregating
transactions to minimize the number of transactions posted to a bank
account. A nonbank company has the legal ability to do this, a bank
does not.
Alan
Solving the problem of micropayments
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/23/2003 07:58 PM
To: Todd Boyle <tboyle@xxxxxxxx>
cc: Alanslater@xxxxxxxx, epay@xxxxxxxx, internet-payments@xxxxxxxx,
rah@xxxxxxxx
Subject: Re: Solving the problem of micropayments
online magstripe stored-value cards in the US use financial
institution to load/purchase the card .... but the actual uses of the
card at the merchant don't involved financial institution
transactions.
echeck/ach x9.59-like transactions with the entity receiving the funds
being identified with something like their public key could be
done. The receiving entity then has an account at their financial
institution with their registered public key. The transaction is
"deposited" by signing it again ... and then the financial institution
can settle thru standard ACH network like a normal check.
something like the NACHA aads trials
https://www.garlic.com/~lynn/x959.html#aads
related
http://internetcouncil.nacha.org/
http://pubs.nacha.org/internet.html
also internet-payments mailing list is hosted by FSTC that originated
the echeck project
http://www.echeck.org/
note in above that echeck/fstc have patents now on digitally signed
payment authorization
also:
http://www.fstc.org/projects/echeck/pressrelease.cfm
fstc web site:
http://www.fstc.org/
universal value exchange launched 2/15/2003 of possibly some interest:
http://fstc-uvx.org/
tboyle@xxxxxxxx on 2/23/2003 5:43 pm wrote:
I have great respect for those accomplishments
but note that they invariably, provide no capability
for their owners to pay anything to anybody other
than thru banks.
Where is there a stored value system that has a P2P interface,
even if it relies on physical presence?
Where is there even a stored value system that allows
a merchant to aggregate balances, without posting
each one to transaction logs at the bank?
Perhaps they exist and I am ignorant,
Thanks
Todd
CIOs Must Be Involved In Controlling Risk In Financial Services
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 02/27/2003 07:14 PM
To: epay@xxxxxxxx
Subject: CIOs Must Be Involved In Controlling Risk In Financial Services
http://www.informationweek.com/story/IWK20030227S0017
Moved:
http://www.informationweek.com/news/global-cio/showArticle.jhtml?articleID=8700491
CIOs Must Be Involved In Controlling Risk In Financial Services
Feb. 27, 2003
Fed vice chairman says Basel II accord is moving the international
financial community in the right direction.
By Eileen Colkin Cuneo
The international financial-services community must continue to work
together to come up with standards for mitigating operational risk, and the
Basel II accord is moving the industry in that direction. So said Federal
Reserve vice chairman Roger Ferguson Jr. in testimony Thursday given before
the House Subcommittee on Domestic and International Monetary Policy,
Trade, and Technology, Committee on Financial Services.
After five years of discussion and revision, Basel II, an international
accord that will improve operational-risk standards for all financial
institutions, is about ready for the last rounds of comment, which Ferguson
expects will happen this spring and summer, with implementation beginning
in late 2006.
The core driver behind Basel II has been that banks have consolidated
internationally and therefore placed fewer large institutions in control of
more money while still operating in heterogeneous environments. That could
spell trouble in the future, Ferguson says. "Significant weakness in one of
these entities, let alone failure, has the potential for severely adverse
macroeconomic consequences. It seems clear that the regulatory framework
should encourage these banks to adopt the best possible risk-measurement
and -management techniques while allowing for the considerable differences
in their business strategies," Ferguson says. "Basel II presents an
opportunity for supervisors to encourage these banks to push their
management frontier forward."
.. snip ...
Iris recognition helps to prevent ID fraud
From: Lynn Wheeler
Date: 02/28/2003 10:39 AM
To: epay@xxxxxxxx
Subject: Iris recognition helps to prevent ID fraud
http://www.smh.com.au/articles/2003/02/27/1046064145169.html
http://slashdot.org/articles/03/02/28/1330249.shtml?tid=158
ATM Iris Recognition Coming Soon ... every ATM in Australia will have
iris recognition technology.
Privacy again a hot-button issue for legistlators
From: Lynn Wheeler
Date: 02/28/2003 11:33 AM
To: epay@xxxxxxxx
Subject: Privacy again a hot-button issue for legistlators
http://www.computerworld.com/securitytopics/security/privacy/story/0,10801,78887,00.html?SKC=security-78887
Privacy again a hot-button issue for legislators
By PATRICK THIBODEAU
FEBRUARY 27, 2003
WASHINGTON
-- Top federal and state privacy enforcement officials are promising
aggressive action against companies that, through theft or accident,
allow customer data to leak out. But there are divergent views on
whether tougher privacy legislation is actually needed to protect
customer data.
U.S. Rep. Clifford Stearns (R-Fla.), the leading advocate of privacy
legislation in the House of Representatives, said he plans to
reintroduce within a few days privacy legislation that would set an
"opt-out" standard for consumers. That would give consumers some way
to limit the sharing of data, but it would also protect businesses
from private lawsuits and leave enforcement to federal and state
authorities.
... snip ...
Don't-Ask-Don't-Tell E-commerce
From: Lynn Wheeler
Date: 03/14/2003 07:59 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Don't-Ask-Don't-Tell E-commerce
http://www.computerworld.com/securitytopics/security/story/0,10801,78873,00.html?SKC=security-78873
Don't-Ask-Don't-Tell E-Commerce
By ROBERT L. MITCHELL
MARCH 03, 2003
Content Type: Opinion
Source: Computerworld
Dealing With Credit Card Fraud
If e-commerce is to flourish, policies need to change now.
When it comes to IT security, good technology can't protect an
organization against bad policy. Judging from the way the banking
industry handled the recent theft of more than 8 million credit card
account numbers [QuickLink 36530], that's a lesson that major
U.S. credit card associations and issuers have yet to learn.
The situation is unlikely to improve in the near term because the
financial services firms that control most credit cards see little
economic incentive to change their ways. Those most at risk of
incurring losses include consumers (through identity theft), and
merchants that accept "card-not-present" transactions.
... snip ...
Spam's Being Used For Identity Theft And Blackmail, Symantec Says
From: Lynn Wheeler
Date: 03/14/2003 08:02 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Spam's Being Used For Identity Theft And Blackmail, Symantec Says
http://www.internetweek.com/security02/showArticle.jhtml?articleID=7800052
Spam's Being Used For Identity Theft And Blackmail, Symantec Says
By Mitch Wagner
Crooks are sending spam using the Symantec Corp. name to sell
counterfeit software, engage in identity theft, steal credit card
numbers, and even blackmail victims through the use of pornography,
Symantec officials said.
... snip ...
Recent IOTP and ECML publications
From: Lynn Wheeler
Date: 03/14/2003 01:56 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Recent IOTP and ECML publications
3506 I
Requirements and Design for Voucher Trading System (VTS), Eastlake D.,
Fujimura K., 3/132003 (15pp) (.txt=30945) (was
draft-ietf-trade-drt-requirements-04.txt)
3505 I
Electronic Commerce Modeling Language (ECML): Version 2 Requirements,
Eastlake D., 3/132003 (8pp) (.txt=13915) (was
draft-ietf-trade-ecml2-req-05.txt)
3504 I
Internet Open Trading Protocol (IOTP) Version 1, Errata, Eastlake D.,
3/3132003 (6pp) (.txt=8655) (See Also 2801, 2802, 2803) (was
draft-ietf-trade-iotp-v1-errata-01.txt)
reference URL at rfcindex:
https://www.garlic.com/~lynn/rfcidx11.htm#3504
https://www.garlic.com/~lynn/rfcidx11.htm#3505
https://www.garlic.com/~lynn/rfcidx11.htm#3506
X9/03 LB#8 - Formation of a New Subcommittee - X9C
From: Lynn Wheeler
Date: 03/21/2003 02:25 PM
To: epay@xxxxxxxx
Subject: X9/03 LB#8 - Formation of a New Subcommittee - X9C
possibly of some interest, fyi .... note that some of the ietf iotp
working group is slight overlap
new X9 working group:
New Work Item: Consumer Credit: Electronic contracting, chattel paper
and promissory notes - X9C1
misc. from ietf rfc index ... aka
https://www.garlic.com/~lynn/rfcietff.htm
3506 I
Requirements and Design for Voucher Trading System (VTS), Eastlake D.,
Fujimura K., 2003/03/13 (15pp) (.txt=30945) (was
draft-ietf-trade-drt-requirements-04.txt)
3505 I
Electronic Commerce Modeling Language (ECML): Version 2 Requirements,
Eastlake D., 2003/03/13 (8pp) (.txt=13915) (was
draft-ietf-trade-ecml2-req-05.txt)
3504 I
Internet Open Trading Protocol (IOTP) Version 1, Errata, Eastlake D.,
2003/03/13 (6pp) (.txt=8655) (See Also 2801, 2802, 2803) (was
draft-ietf-trade-iotp-v1-errata-01.txt)
Amazon/Bezos: web advertising patent
From: Lynn Wheeler
Date: 03/21/2003 02:56 PM
To: epay@xxxxxxxx
Subject: Amazon/Bezos web advertizing patent
Patent application for adding advertisements to web pages
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=/netahtml/PTO/srchnum.html&r=1&f=G&l=50&s1='20030055729'.PGNR.&OS=DN/20030055729&RS=DN/20030055729
Who's afraid of Mallory Wolf?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/24/2003 10:42 AM
To: epay@xxxxxxxx
Subject: Re: Who's afraid of Mallory Wolf?
forwarded from thread on crypto mailing list .... Mallory Wolf is
colloquialism for man-in-the-middle attack. discussion is why are some
hundred thousand merchants paying $100 (or more) for SSL certificates
as a MITM countermeasure ... when they haven't actually been any
reported in the wild ... and would self-signed certificates be
sufficient.
a similar question about self-signed certificates in same mailing
list:
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?
----- Forwarded by Lynn Wheeler on 03/24/2003 10:15 AM -----
lynn@xxxxxxxx on 3/24/2003 10:10 am wrote:
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)
Card Technology Forecast: 2004-2009
From: Lynn Wheeler
Date: 03/24/2003 01:57 PM
To: epay@xxxxxxxx
Subject: Card Technology Forecast: 2004-2009
fyi ....
http://www.efta.org/
----- Forwarded by Lynn Wheeler on 03/24/2003 01:52 PM -----
March 24, 2003
Dear Colleague:
I am pleased to invite you to an upcoming conference entitled "Card
Technology Forecast: 2004-2009." This event, sponsored by the
Electronic Funds Transfer Association and its EBT Industry Council,
will take place May 6, 2003 at the Hilton Crystal City near
Washington, DC.Â
The purpose of the one-day summit meeting is to analyze the future of
electronic card technology for the delivery of government services or
payments. The conference will bridge the gap between where card
technology is headed over the next 5 years and where government needs
that technology to be for such applications as security, defense and
human services.
The all-day program will feature presentations designed to drill down
to the issues that card technologists are working on now for future
enhancements. These include standards and practices, infrastructure
trends and constraints, and program expansion.
Expect senior-level presenters, including keynote, speaker George
Wallner, chief strategist and founder of Hypercom Corporation, from
such companies as VeriFone, Inc. Citicorp EFS, Visa U.S.A., Fujitsu
and Hypercom. They will be joined in an interactive format by veteran
program managers from a variety of federal agencies.
related to electronic contracting (new X9C group)
From: Lynn Wheeler
Date: 03/25/2003 08:28 AM
To: epay@xxxxxxxx
Subject: related to electronic contracting (new X9C group)
Microsoft breaks with standards effort
http://news.com.com/2100-1008-993949.html?tag=fd_lede1_hed
previous ...
http://news.com.com/2100-1013-992521.html?tag=nl
W3C seeks standards accord
By Martin LaMonica
Staff Writer, CNET News.com
March 13, 2003, 1:59 PM PT
A World Wide Web Consortium committee began meetings on Thursday to
sort out an array of confusing, yet critical, Web services standards.
The WS-Choreography Working Group at the World Wide Web Consortium
(W3C) will spend the next two days considering several proposals on
how to automate business processes using Web services.
The capability, called choreography or orchestration, means that
businesses can use XML (Extensible Markup Language)-based Web services
to build software for sharing data and processes in complicated
business scenarios. For example, a business could use the choreography
specifications to model and execute a financial transaction that spans
several companies and computing systems. Web services allow developers
to build software applications that can easily communicate with one
another.
... snip ...
ID theft costs banks $1 billion a year
From: Lynn Wheeler
Date: 03/27/2003 04:23 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: ID theft costs banks $1 billion a year
ID theft costs banks $1 billion a year
Report: There's no way to positively identify new customers
By Bob Sullivan
MSNBC
March 26: Banks lost at least $1 billion to identity thieves last
year, according to a report issued Tuesday by TowerGroup Inc. While
only an estimate, it is one of the first attempts to put a detailed
price tag on what has been called the nation's fastest growing
crime. What's more, the report asserts, banks have no way of telling
whether new customers applying for a loan or credit card are actually
who they say they are.
... snip ...
Be Prepared: Gartner Outlines Top Security Risks
From: Lynn Wheeler
Date: 03/29/2003 09:12 AM
To: epay@xxxxxxxx
Subject: Be Prepared: Gartner Outlines Top Security Risks
http://www.informationweek.com/story/IWK20030328S0022
Be Prepared: Gartner Outlines Top Security Risks March 28, 2003
The research firm says companies must cut through the hype to develop
a coherent security plan
By Gregg Keizer, TechWeb News
With the war in Iraq now in its second week and with security a global
worry, what better time to delve into the defensive and protection
issues enterprises will face through the end of the year?
Market research firm Gartner obviously thinks so. It released a report
that leverages the news to put corporate security front and center. At
the just-concluded Gartner Symposium/ITxpo in San Diego, where Gartner
brought together thousands of IT professionals from companies both in
the United States and overseas, analyst Victor Wheatman outlined a
top-10-plus-one list of security issues businesses will confront
during 2003.
... snip ...
- Wireless LAN security: Although progress is being made to secure
wireless networks, rushing to deploy wireless poses a major threat of
information theft, Wheatman said. In addition, he noted the ongoing
underground movement to tap into hot spots, including those maintained
by businesses, opening up the potential for service and bandwidth
shoplifting.
- Identity management: Identity theft is rampant, and is mostly
accomplished by mundane means such as "dumpster diving." It's crucial
that companies have identity management and provisioning plans in
place to prevent workplace identity theft, and educate workers on the
dangers of the crime, Wheatman said. And although some vulnerabilities
exposed by poor identity management are rarely hyped, they've simply
been around too long and remain potent threats.
... snip ...
Bank Float May Sink
Refed: **, - **, - **
From: Lynn Wheeler
Date: 03/29/2003 11:30 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Bank Float May Sink
one of the implementation issues in fstc e-check had to do with float.
http://dc.internet.com/news/article.php/2171621
March 28, 2003
Bank Float May Sink
By Roy Mark
The traditional consumer "float" -- the time between writing a check
and when it actually clears the bank -- will be shrinking if Congress
approves legislation introduced Thursday that would permit banks to
exchange checks by electronic image.
The banking industry says the bill will benefit consumers by speeding
up check clearing and making the electronic images -- front and back
-- quickly available to customers. Most banks currently physically
move the paper checks through intermediaries before actually drawing
on the funds, a process that can take several days or longer.
... snip ...
Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/02/2003 07:33 AM
To: epay@xxxxxxxx
Subject: Re: Mockapetris agrees w/ Lynn on DNS security - (April Fool's day??)
and some topic drift .... the other co-inventer was the rfc-editor,
jon postel ... who was located at ISI.
For a number of years, I provided Jon with section 6.10 in the
regularly issued internet standard STD1 .... as well as misc. other
consistency checking about the rfc standards process. It was part of
the process that I also used for generating the RFC index at:
https://www.garlic.com/~lynn/rfcietff.htm
example of what section 6.10 used to look like:
https://www.garlic.com/~lynn/rfcietf.htm#obsol
one of the tribute's to Jon is at:
http://wwwvms.utexas.edu/~glen/postel/
There is a hallowed Internet standard RFC tradition for April 1st ....
reference
https://www.garlic.com/~lynn/rfcietff.htm
and select Term (term->RFC#),
and then scroll down to:
April1
3252 3251 3093 3092 3091 2795 2551 2550 2549 2325 2324 2323 2322 2321
2100 1927 1926 1925 1924 1776 1607 1606 1605 1437 1313 1217 1149 1097
852 748
clicking on any of the RFC numbers will bring up a summary of that RFC
in the lower frame. Clicking on the ".txt=nnnn" field in the RFC
summary, will fetch the actual RFC.
raise one for Jon ... and one for April 1st.
As an aside ... during the X9 meeting at the Marina Del Rey Ritz in
Oct '97, we walked down to ISI and talk to the RFC editor people.
Also the first presentation on AADS was at ISI to a USC graduate
student seminar of about 60 people:
https://www.garlic.com/~lynn/x959.html#aads
also at:
http://www.isi.edu/
This past Monday (3/31), Paul is named Visiting Scholar
http://www.usc.edu/isinews/stories/89.html
and another dedication to Jon:
http://www.isi.edu/div7/people/postel.home/
t.c.jones@xxxxxxxx on 4/1/2003 4:44 pm wrote:
Tuesday, April 1, 2003
DNS pioneer warns of Internet security
(6:01 p.m. EST, 04/01/03)
The Internet community can ill afford to rest on its laurels as far as
DNS security is concerned. When it comes to the Domain Name System,
the database architecture at the heart of the Internet infrastructure
for the last 20 years, "the majority of the work to be done still lies
ahead of us," said Paul V. Mockapetris who co-invented DNS.
http://www.commsdesign.com/story/OEG20030401S0048
First Data buying Concord EFS
From: Lynn Wheeler
Date: 04/02/2003 08:27 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: First Data buying Concord EFS
http://cbs.marketwatch.com/news/story.asp?guid=%7BEFFF452F-37D9-489C-BC85-DAB5EC729B4C%7D&siteid=google&dist=google
First Data buying Concord EFS
$7 billion stock deal will combine transaction firms
By CBS.MarketWatch.com
Last Update: 8:33 AM ET April 2, 2003
NEW YORK (CBS.MW) - Shares of Concord
EFS rallied in pre-market trades Wednesday after First Data said it'll buy the Memphis, Tenn. transaction specialist in a $7 billion stock deal.
... snip ...
Mockapetris agrees w/Lynn on DNS security - (April Fool's day??)
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/02/2003 11:19 AM
To: epay@xxxxxxxx
Subject: Re: Mockapetris agrees w/ Lynn on DNS security - (April Fool's day??)
and a little cross-over:
https://www.garlic.com/~lynn/2003f.html#24 New RFC 3514 addresses malicious network traffic
https://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic
Bank of America's Trade Finance Strategy
From: Lynn Wheeler
Date: 04/08/2003 03:40 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Bank of America's Trade Finance Strategy
http://www.financetech.com/story/enews/BNK20030407S0003
Date: Apr 7, 2003
Publication: BankTech
By: Ivan Schneider
Bank of America's Trade Finance Strategy
If transforming paper checks into electronic documents seems tricky,
just consider the problem of foreign trade.
Trade finance includes not just the buyer and the seller, but also the
insurance companies, freight forwarders, shipping companies,
consolidators, inspection companies, and government bureaus involved
with each shipment. Also, recent homeland security initiatives in the
U.S. have made timely access to information about a shipment more
important than ever before.
.. snip ...
Actual Losses To Identity Fraud Top $1 Billion
From: Lynn Wheeler
Date: 04/16/2003 10:11 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Actual Losses To Identity Fraud Top $1 Billion
http://www.banktech.com/story/BNK20030416S0001
Annual Losses To Identity Fraud Top $1 billion
Paul Doocey
Apr 16, 2003
United States-based lending institutions are losing more than $1
billion each year to identity theft, a figure that is likely to grow
short-term, according to a report recently released by TowerGroup.
... snip ...
Blackboard Gets Gag Order Against Smart-Card Hackers
From: Lynn Wheeler
Date: 04/18/2003 09:15 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Blackboard Gets Gag Order Against Smart-Card Hackers
http://www.washingtonpost.com/wp-dyn/articles/A48214-2003Apr17.html
Blackboard Gets Gag Order Against Smart-Card Hackers
Georgia Tech computer science student Billy Hoffman has spoken about
flaws in Blackboard's card system at several hacker conventions in the
past two years. (Tim Cailloux -- Technique Via AP)
By Anitha Reddy
Washington Post Staff Writer
Friday, April 18, 2003; Page E01
A D.C.-based company that sells a "smart card" network used on more
than 200 college campuses has blocked two students from publicly
describing how to override the system to circumvent building security,
obtain free soft drinks and avoid paying for laundry.
Blackboard Inc. obtained a court order last weekend preventing Billy
Hoffman, a computer science major at Georgia Tech, and Virgil
Griffith, a student at the University of Alabama, from discussing
vulnerabilities in the card system at a hacker convention in Atlanta.
.. snip ...
A More Anonymous Internet
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/18/2003 09:42 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: A More Anonymous Internet
Note, the other approach by X9.59 ... was to remove account numbers
from the category of shared-secrets and therefor usable in fraud
situations. It is the use of account numbers of fraudulent
transactions that gets them lumped into the overall identity theft
category.
The issue addressed by X9.59 is that account numbers can be only used
in authenticated transactions, that just having knowledge of the
account number is not sufficient to perform fraud. Parts of the
problem is that account numbers tend to be used in a number of
business processes, not just the initial authorization transaction.
I'm not aware of evesdropping and/or man-in-the-middle exploits
related to payment card transactions flowing over the internet (either
with or w/o SSL). The major exploits that make the press is when a
merchant account file with tens or hundreds of thousands of
transactions get snarfed by some process.
It fraud issue isn't directly that credit card number has to be
revealed ... it is that currently with just knowledge of the credit
card number, it is possible to perform fraud. The X9.59 solution is to
allow knowledge of the credit card number (since it is required in a
number of business processes), and to eliminate the ability to perform
fraud given just given the knowledge of the number with the use of
authenticated transactions.
misc. privacy, identity, authentication & x9.59
https://www.garlic.com/~lynn/subpubkey.html#privacy
http://www.technologyreview.com/articles/innovation40503.asp
A More Anonymous Internet
By Tracy Staedter
Innovation
May 2003
Identity theft and credit card fraud are surging international
problems, fueled partly by the need to reveal credit card and Social
Security numbers in the course of common Internet
transactions. Although most businesses immediately encrypt such
numbers, researchers at IBM’s Zurich Research Laboratory and elsewhere
are devising ways to avoid having to submit the numbers in the first
place.
Concern Grows About ID Theft
Refed: **, - **
From: lynn.weeler@xxxxxxxx
Date: 04/18/2003 01:08 PM
To: epay@xxxxxxxx
cc: internet-payments@xxxxxxxx
Subject: Re: Concern Grows About ID Theft
from the article ... there isn't any real indication what words were
used in the meeting and what, if any translation was provided by the
reporter.
as in the x9.59 discussions ... one might observe that there have been
a lot of parties working on hiding shared-secrets .... requiring ever
increasing amounts of cryptography. the x9.59 observation is that the
existing paradigm with the existing account number being a
shared-secret ... and sufficient for fradulent transactions .... is also used
in a number of transaction processing business processes ... requiring
direct availability of the account number. millions of dollars of
cryptography hiding the account number would still not be sufficient
to close all the loop-holes.
the x9.59 approach was to change the paradigm and eliminate the
account number as a direct fraud vulnerability.
somewhat related discussion as to security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe?
egerck@xxxxxxxx wrote:
;-) in an attorney's meeting, the word should be "impersonation" --
there is no such thing as an "identity theft". Using such
awe-inspiring expression as "identity theft" may help get public
attention but is, IMO, not productive in terms of understanding what
is happening and how to solve it. Perhaps, it is this dumbed down
choice of words that is making the solutions so elusive -- and so
"justifiably" hard to provide.
Cheers,
Ed Gerck
Nokia, MasterCard test wireless payment
From: Lynn Wheeler
Date: 05/17/2003 04:00 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Nokia, MasterCard test wireless payment
http://www.infoworld.com/article/03/05/14/HNmasternokia_1.html
Nokia, MasterCard test wireless payment
PayPass technology puts credit card info on mobile phones
By John Blau
May 14, 2003
Imagine waving your mobile phone at a filling pump to pay for gas
or tapping it on some tiny gadget to buy a bag of doughnuts. That's
the vision of Nokia and MasterCard International. The two companies
have teamed to test technology that they hope will someday give mobile
phones new wireless credit card capabilities.
... snip ...
Visa, Philips team to promote 'contactless' credit card
From: Lynn Wheeler
Date: 05/29/2003 02:37 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Visa, Philips team to promote 'contactless' credit card
http://www.eetimes.com/sys/news/OEG20030528S0030
Visa, Philips team to promote 'contactless' credit card
by Junko Yoshida
EE Times
May 28, 2003 (5:03 p.m. ET)
PARIS - Visa International and Royal Philips Electronics have
unveiled an exclusive partnership agreement under which the two
companies will jointly develop and promote the application of
contactless chip technology for payment transactions.
... snip ...
Authentication white paper
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/08/2003 01:23 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Authentication white paper
I'm in the process of finishing up an authentication white paper for
an international financial "best practices" security book. Much of it
reflects the various deliberations that went on in the x9a10 committee
for the x9.59 standard (requirement given the x9a10 committee to
preserve the integrity of the financial infrastructure for ALL
electronic retail payments; aka ALL as in not just internet, not just
point-of-sale, not just credit, not just ACH, etc). Some specific
issues related to the X9A10 committee work:
A taxonomy for security is PAIN
P ... privacy
A ... authentication
I ... identification
N ... non-repudiation
A taxonomy for authentication is 3-factor authentication:
• something you have (aka hardware token)
* something you know (either shared-secret or non-shared-secret)
* something you are (biometrics, again either shared-secret or
non-shared-secret)
While x9.59 primarily deals with strong authentication for financial
transactions, the original chair (Tom Jones) of X9A10, put a lot of
early work into non-repudiation for financial transactions. This
effectively took the form of cosigning .... the early X9.59 work went
on contemporary with the fstc/echeck work on people authentication
cosigning (and FSML encoding, a lot of which has been folded into XML
digital signature work). While neither kind of cosigning actually show
up in the x9.59 standard, the standard was carefully written in such a
way as to not preclude either form of cosigning.
The concept behind Tom's work on consigning is synergistic with the EU
FINREAD (financial reader) standard. In the past, there had been quite
a bit of confusion generated somewhat assuming that non-repudiation
and authentication could possibly be equivalent. This was possibly
something of semantic confusion with the term "digital signature"
somehow taken to be the equivalent of a human physical signature and
all that it implies with respect to intention, agreement and
non-repudiation.
The FINREAD standard has a token acceptor device that is certified to
display the value of the financial transactions followed by the entry
of the hardware token PIN/Password (prior to the token performing
authentication; as well as guaranteeing the value displayed is what is
sent to the token for authentication).
The simple design of a two-factor authentication system involves a
PIN/Password that activates a hardware token performing a digital
signature for authentication. The hardware token has been certified to
not perform a signature unless the correct PIN has been entered. The
existence of a digital signature then demonstrates possession of
something you have token and implies that the correct something you
know PIN was entered.
However, just because two-factor authentication was demonstrated, it
hasn't demonstrated that a person has read and agreed with
something. Intention and non-repudiation becomes a process that
includes some human interaction. The EU FINREAD standard certifies a
token acceptor device that implements a process that provides some
degree of assurance that the process for non-repudiation/intention has
been met, aka the correct amount was presented on the display,
followed by explicit human interaction (typing the correct PIN on the
pad immediately below the display), and that the value presented to
the token for signing matched what was on the display.
In the case of a certified token, two-factor authentication can
be inferred because the token will not have been performed correctly
w/o the correct PIN having been entered. In the case of certified
FINREAD terminal, non-repudiation process can be inferred because the
FINREAD terminal requires the PIN (human physical action) to be
entered after the transaction has been displayed, and the FINREAD
terminal guarantees what was sent to the token for signing is what is
displayed and is sent after then PIN has been entered.
The big difference between the current EU FINREAD standard (certified
terminal attempting to establish the basis for inferring intention
and/or non-repudiation) and the early X9A10 work by Tom Jones, was
that Tom wanted the certified terminal/environment to cosign the
transaction .... thereby proving that the signing actually took place
using a certified terminal/environment. The existing FINREAD standard
establishes the criteria for a certified signing environment/terminal
(required for inferring intention/non-repudiation) but doesn't (yet)
require proof that the signature actually occurred using such a
certified terminal/environment.
The cosigning for X9.59 transactions was different than the FSTC
e-check cosigning. The FSTC e-check cosigning wanted two (or more)
entities authenticating the transaction. The X9.59 cosigning work
wanted proof that a certified signing environment (process required
for inferring intention and/or non-repudiation) was used (by the
environment/terminal cosigning the transaction).
aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads
regarding trusted token acceptor device for ACH transactions:
http://www.asuretee.com/company/releases/030513_hagenuk.shtm
.... and as an aside the merged security taxonomy and glossary is at
https://www.garlic.com/~lynn/index.html#glossary
Note that otherwise similar tokens may come with three different types
of personalities:
1) no PIN required .... frequently found in low-value, high traffic
transit locations. Single factor (something you have) authentication
is sufficient
2) PIN required after power up ..... frequently found in two-factor
authentication access applications, the token is powered up, the
correct PIN entered, and the token may digitally sign an arbitrary
number of authentication messages while powered up. The operation of
the hardware token implies correct something you know PIN as part of
two-factor authentication.
3) PIN required for every message .... found in financial transaction
applications and typically assumed to be used in an authentication
environment that allows intention and/or non-repudiation to be
inferred. The PIN, in addition to implying something you know
authentication also implies some human physical event (entering the
PIN) occurred as part of a non-repudiation process.
Note that there is a significant difference in the
shared-secret paradigm and the non-shared-secret
paradigm. In the shared-secret paradigm, the something you
know is recorded at some central location and used to establish
authentication. In the non-shared-secret paradigm, the secret
can be recorded in a private hardware token, and the knowledge of the
secret can be inferred from the operation of the token; w/o actually
requiring the secret to ever be divulged.
As a footnote, X9.59 doesn't (directly) address the privacy part of
security. There is current situation where credit-card transaction
have encrypted transmission on the internet using SSL; in part because
the account numbers are a form of shared-secret (divulging the account
number can result in fraudulent transactions). X9.59 as part of the
original requirement preserve the integrity of the financial
infrastructure for all retail payments, specifies 1) authenticated
transactions and 2) account numbers that can only be used in
authenticated transactions. As a result, X9.59 account numbers by
themselves can't be used in fraudulent transactions and therefor no
longer have to be treated as shared-secrets. It was observed, that in
any transition, financial institutions could use existing business
processes that map multiple different account numbers to the same
account.
Furthermore, the claim is that with strong two-factor
authentication (something you have and something you
know) operation, it would be possible to remove names from tokens
and as part of transactions. While X9.59 doesn't directly address
financial privacy issues (via specifying mechanisms like encryption),
it indirectly aids privacy by eliminating account numbers as
shared-secrets and significantly minimizing any requirement for
identification information as part of transactions (aka even better
than protecting the information is the information not being there
at all).
FINREAD was. Authentication white paper
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/08/2003 03:03 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: FINREAD was. Authentication white paper
anders rundgren on 6/8/2003 1:54 pm wrote:
regarding the references to FINREAD I believe the vision as
represented by the following document
http://www.finread.com/pages/finread_initiatives/ec_funded_projects/02_embedded.html
has little foundation in reality. I.e. reading current "king-sized"
smart credit cards in mobile phones or PDAs seems like a rather
complex idea taking in consideration the proliferation in the card
sector.
makes reference to a finread compliant terminal ...
http://www.hagenukscs.com/
FINREAD ... and as an aside
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn.wheeeler@xxxxxxxx
Date: 06/08/2003 03:48 PM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: FINREAD ... and as an aside
with regard to finread operation for inferring intention and/or
non-repudiation from previous posts:
https://www.garlic.com/~lynn/aepay11.htm#53
https://www.garlic.com/~lynn/aepay11.htm#54
is a characteristic of the disconnect between the something you have
token and the technology needed for secure display and input.
there has been quite a bit of work translating the requirements for
inferring intention and/or non-repudiation into a something you have
device that integrates the attributes of personal token with secure
display and input (aka some form of PDA or cellphone).
This somewhat reflects the claim that (7816) smartcards went thru a
period where there was some thought that they would be the PDAs of the
1980s i.e. the technology didn't yet exist to integrate portable
computing that fit in a pocket along with portable display and
input. The solution was to have ubiquitous input/output stations with
people carrying the portable computer (smartcard) in their pocket. In
the early 90s, there was advances in technology that allowed that the
portable computing devices (aka smartcards) and input/output
capability to be integrated into a single device (evidence PDAs and
cellphones). This effectively began the obsoleting of that target
market for smartcards.
embedding an aads chip in a personal portable computing device
with integrated input/output (aka PDA/cellphone) can provide both the
indication of something you have authentication along with proof of
a business process that supports intention and/or non-repudiation. Of
course the specific personal, portable computing device with
integrated input/output will need to be appropriately certified as
meeting the (equivalent finread) security requirements in support of
demonstrating intention and/or non-repudiation. This requires a high
level of assurance that the value of the transaction that is
displayed, is in fact the value that a digital signature is applied to
... and that there is some sort of human input in conjunction with the
value displayed that can be taken as representing human intention and
agreement.
this is similar to past threads relating to the asuretee chip being
the equivalent of the trusted computing platform module. Depending on
the business process followed and the exact certification, an embedded
asuretee chip could be taken as
1) authenticating a hardware device,
2) authentication as part of something you have paradigm,
3) authentication in conjunction with other inferred events supporting
two/three factor authentication and/or intention and non-repudiation.
The original references to FINREAD wasn't whether or not it was
applicable to PDAs and cellphones, but what were the characteristics
of the requirements in the FINREAD standard necessary for establishing
intention and/or non-repudiation. Using the implementation details of
a FINREAD terminal as an example along with the original requirements,
it is then possible to translate the requirements to other
implementations. I relatize that the specifics of the FINREAD terminal
represent the 80s disconnect between technology available for a
personal, pocket-sized portable computing device and the 1980s
input/output technology needed to support a pocket-sized portable
computing device. However, it is also possible to translate
requirements for supporting "intention" into 1990s technology where
the personal pocket-sized portable computing device has its own
integrated input/output technology.
lots of past threads related to FINREAD and/or intention.
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)
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/aadsm12.htm#30 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#59 e-Government uses "Authority-stamp-signatures"
https://www.garlic.com/~lynn/aepay10.htm#53 First International Conference On Trust Management
https://www.garlic.com/~lynn/2000f.html#79 Cryptogram Newsletter is off the wall?
https://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking
https://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#51 future of e-commerce
https://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible?
https://www.garlic.com/~lynn/2001j.html#46 Big black helicopters
https://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection?
https://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2001n.html#70 CM-5 Thinking Machines, Supercomputers
https://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2002h.html#13 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing
https://www.garlic.com/~lynn/2002l.html#28 Two questions on HMACs and hashing
https://www.garlic.com/~lynn/2002m.html#38 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#26 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#67 smartcard+fingerprint
https://www.garlic.com/~lynn/2002p.html#52 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003h.html#25 HELP, Vulnerability in Debit PIN Encryption security, possibly
https://www.garlic.com/~lynn/2003h.html#29 application of unique signature
https://www.garlic.com/~lynn/2003h.html#38 entity authentication with non-repudiation
FINREAD was. Authentication white paper
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/08/2003 05:13 PM
To: "Scott Guthery" <sguthery@xxxxxxxx>
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>,
epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: RE: FINREAD was. Authentication white paper
scott guthery on 6/8/2003 4:29 pm wrote:
Yep, everybody's going to instantly stop doing business
on the Internet until they can rent a $150 card reader
from a bank that uses the device to block transactions
with businesses that won't pay it PIN handling fee and
use their network and clearing services.
there seems to be a little exaggeration. none of the finread terminals
i've seen come anywhere close to $150/terminal.
also, in most cases, the issue is security/integrity proportional to
the risk. the specific example quoted in the original posting was a
terminal for secure ACH transactions, not something that you currently
find being done on the internet. the original posting also gave the
example of single-factor something you have authentication (as
in transit, not requiring two-factor authentication) .... aka
internet-payments doesn't necessarily limit things to consideration
for only existing consumer/merchant e-commerce operations.
the existing consumer internet based infrastructure is heavily based
on the original work that my wife and I were involved with for payment
gateway with a small client/server startup (originally in menlo park,
subsequently moved to mountain view and since been bought by AOL):
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
the current, existing infrastructure is oriented to
shared-secrets and single-factor something you know
authentication that has been heavily exploited for fraud. One case
would be to look at the various cost/benefit trade-offs for improving
the existing fraud situation (past postings to these mailing lists
have it at 30-50 times higher than similar transactions not done on
the internet). Also the existing scenario makes little or no attempt
at non-repudiation .... it is assumed that the consumer can readily
and easily repudiate all internet-originated transactions.
Non-repudiation may not be a requirement for internet transactions;
something you have and something you know, two-factor
authentication may be sufficient.
Presumably, the PIN handling fee refers to the transition from
shared-secret based infrastructure (aka PIN) to
non-shared-secret digital signature based infrastructure
... where the public key is registered in lieu of the PIN and a
digital signature authentication is done in lieu of a PIN comparison.
A possible X9.59 cost/benefit then potentially is the possible
significantly reduced fraud-related fees to the merchant being
significantly larger than the PIN (or digital signature) handling fee.
Somewhat as a total aside .... in the case of X9.59 standard, the
protocol specification is the same regardless of whether or not a
token is used. Any requirement for a token becomes a business process
assurance issue, not a protocol issue. The requirement for signing
environment that supports intention also is a business process
assurance issue, not a protocol issue. It is possible to use the same
x9.59 protocol standard across a broad range of varying business
process assurance and integrity implementations.
US warns banks about virus
From: Lynn Wheeler
Date: 06/10/2003 09:10 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: US warns banks about virus
http://www.smh.com.au/articles/2003/06/10/1055010959747.html
Washington
June 10 2003
The US government is warning financial institutions about a virus-like
infection that has targeted computers at roughly 1200 banks worldwide,
trying to steal corporate passwords.
The FBI is investigating what private security experts believe to be
the first internet attack aimed primarily at a single economic sector.
... snip ...
PKI's not working
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/12/2003 01:57 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: PKI's not working
note in this cross posting from ietf pkix, cross-posted from bar
association mailing list ... mentions banks being able to attest to
some assertion.
https://www.garlic.com/~lynn/aadsm14.htm#43 PKI's not working
that effectively what an x9.59 transaction is ... the financial
institution providing real-time confirmation about some assertion
regarding payment.
this was generalized quite a bit in the FSTC FAST project .... which
effectively took the 8583 payment transaction model and extended it to
other types of assertions; aka zip-code, >21 years old, <16years old,
etc. Some generalized assertion was made (not just about payment) and
the financial institution either affirmed it or didn't affirm it. it
wasn't a case somewhat outlined in
https://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
where huge amounts of identity and privacy information could be
overloaded into a certificate ... which then could be sprayed all
around the world.
x9.59 refs:
https://www.garlic.com/~lynn/x959.html#x959
http://www.ca0.net/
some past FSTC FAST discussions:
https://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
https://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
https://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads
https://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
https://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
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
https://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
US warns banks about virus ... another ref:
From: Lynn Wheeler
Date: 06/12/2003 04:33 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: US warns banks about virus ... another ref:
http://itmanagement.earthweb.com/secu/article.php/2221131
Feds Investigate Virus Attack on Financial Industry
June 12, 2003
By Sharon Gaudin
The security community and the federal government are on alert for
what could be another evolution in computer viruses. The newest
variant of the Bugbear virus -- W32.Bugbear.B@mm -- is designed to
specifically target financial institutions. When it infects a computer
in the financial community, the virus logs keystrokes, steals
passwords and sets up backdoor Trojans.
... snip ...
PKI's not working
Refed: **, - **, - **, - **
From: Lynn Wheeler
Date: 06/12/2003 04:48 PM
To: Todd Boyle <tboyle@xxxxxxxx>
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: PKI's not working
careful, somebody might think you are playing ringer for aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads
slight quibble .... establish authentication with public key
cryptography ... mixing up identification and authentication can get
really messy.
todd boyle on 6/12/2003 4:26 pm wrote:
Public key cryptography is quite usable for the problem of enabling
competent, willful individuals to prove their identity and other
assertions over networks. Of course there are no secure devices in
common use that can't be hacked in seconds by hackers of sufficient
skill. But that is another problem.
Public key cryptography is much less useful in addressing the problem
of organizations and governments to positively identify unwilling,
recalcitrant citizens at the other end of a network connection.
PKI's not working for that, and neither will anything else ever work
for that. You cannot control what is at the other end of an electric
wire. Only the other person can control that.
Oh, you can win their cooperation in some interaction they decide to
participate in. And you can even make them "an offer they cannot
refuse." But you're never really going to achieve net gain with a
machine with a network, with customers tethered to the network.
Organizations are accustomed to earning long term, recurring cash
flows from physical buildings, physical employees watched over by
managers, and procedures of internal control, that's not going to
happen when the "organization" is a supreme computer with no
employees. There is no magic protocol, no crypto, that will achieve
this. Accordingly banks should put in hands of their customers, an
honest signing device and forget their dreams of pki empire,
Todd
HIPAA, privacy, identity theft
From: Lynn Wheeler
Date: 06/16/2003 09:52 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: HIPAA, privacy, identity theft
some past studies have found that driving factors behind privacy
regulation & legislation are 1) denial of service (by institutions)
and 2) identity theft
http://www.computerworld.com/securitytopics/security/privacy/story/0,10801,82051,00.html
By Marne Gordan
JUNE 12, 2003
Computerworld
With the Health Insurance Portability and Accountability Act (HIPAA)
privacy deadline recently passed, most health care providers and plan
companies are preparing to implement the final rule for security.
While many of these organizations are focused on the lack of budgetary
and staff resources necessary to fulfill another unfunded federal
mandate, most have lost sight of why this level of protection is
necessary.
As organizations (known in the legal jargon as "covered entities")
begin their risk assessments and risk management planning, it's
important to remember one of the key principles of the regulations,
and that is patient protection. The standard clearly states that the
organization must ensure the confidentiality, integrity and
availability of protected health information (PHI) and safeguard it
from threats, hazards and unauthorized disclosure, but the act
neglects to underscore why it's important to do so.
... snip ...
HIPAA, privacy, identity theft (addenda)
From: Lynn Wheeler
Date: 06/16/2003 12:05 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: HIPAA, privacy, identity theft (addenda)
further down in the computerworld HIPAA article they have an example
(examples seem to be everywhere) of some master file harvesting that
includes credit card numbers ... and the resulting fraud and identity
theft.
one of the issues is that if privacy related vulnerabilities continue
to occur, there will continue to be additional regulatory and
legislative actions.
and from some other report:
"ID theft is growing at 300% per year. The Aberdeen Group estimates
that the Global Economy will sustain $221 Billion in losses related to
Identity Theft by the end of 2003."
and of course, some x9.59 standards objectives: 1) authenticated
transactions, 2) cc# by itself is no longer sufficient for fraud and
therefor doesn't have to be treated as a shared-secret or privacy
issue, and 3) with strongly authentication transactions .... weaker
authentication forms involving indentity information (like name,
address, zip-code, etc) can be eliminated as part of the financial
transaction.
past postings related to x9.59 &/or privacy:
https://www.garlic.com/~lynn/subpubkey.html#privacy
past postings related to vulnerabilities, exploits, and/or fraud:
https://www.garlic.com/~lynn/subintegrity.html#fraud
E-merchants Turn Fraud-busters
From: Lynn Wheeler
Date: 06/16/2003 02:59 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: E-merchants Turn Fraud-busters
related:
http://www.computerworld.com/managementtopics/ebusiness/story/0,10801,82072,00.html
http://www.computerworld.com/managementtopics/ebusiness/story/0,10801,82079,00.html
http://www.computerworld.com/managementtopics/ebusiness/story/0,10801,82073,00.html?SKC=home82073
E-merchants Turn Fraud-busters
Web retailers are teaming up to fight online credit card fraud and
take back the e-neighborhood.
By Alan R. Earls
JUNE 16, 2003
Nobody likes being ripped off. But for online retailers, the pain of
being ripped off by unethical consumers, identity thieves and
bogus-card gangs has been magnified by what they consider to be the
not-my-problem attitude of credit card issuers and card associations
like Visa and MasterCard.
Tom Mahoney, a network administrator at Franklin & Marshall College in
Lancaster, Pa., recalls vividly the shock he and his wife felt shortly
after they launched their own mom-and-pop e-business in 1997 and
discovered not only the threat of fraud but also the double whammy
from the credit card companies.
... snip ...
EFTA to Adaopt ATM Ant-Fraud Measures
From: Lynn Wheeler
Date: 06/18/2003 12:16 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: EFTA to Adaopt ATM Ant-Fraud Measures
In Brief: EFTA to Adopt ATM Anti-Fraud Measures
American Banker Wednesday, June 18, 2003
By David Breitkopf
The Electronic Funds Transfer Association's board of directors voted
unanimously on June 11 to adopt a set of recommendations to combat
fraud using automated teller machines.
The recommendations were written by the Washington group's ATM
Integrity Task Force, which was formed last year to come up with ways
to thwart the skimming of financial data from debit cards at teller
machines.
Suggested measures included improving PIN security and upgrading older
machines to modern encryption standards and having ATM deployers check
the credentials of the company operating the machines on their behalf.
The EFTA seems poised to make the ATM Integrity Task Force a permanent
council. An August meeting will probably address point of sale
security, executives of the association said.
E-merchants Turn Fraud-busters (somewhat related)
Refed: **, - **, - **
From: Lynn Wheeler
Date: 06/18/2003 02:20 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: E-merchants Turn Fraud-busters (somewhat related)
An earlier NACHA report may bear repeat ref from Feb:
https://web.archive.org/web/20070706004855/http://internetcouncil.nacha.org/News/news.html
as an aside, the above URL also contains pointer to the results of the NACHA AADS trials
https://www.garlic.com/~lynn/x959.html#aads
Internet Payments Fraud: A Primer for Merchants and Financial Institutions
http://internetcouncil.nacha.org/docs/Fraud%20Paper%20Final%20%20Jan%20%2703.pdf
table of contents for above:
INTERNET PAYMENTS FRAUD: A PRIMER FOR MERCHANTS AND FINANCIAL INSTITUTIONS
1.0 INTRODUCTION
1.1 OVERVIEW OF INTERNET FRAUD
1.2 SCOPE
1.3 ORGANIZATION AND USE OF THIS DOCUMENT
2.0 ACH-SPECIFIC FRAUD..
2.1 INTRODUCTION
2.2 ACH FRAUD CATEGORIES
2.2.1 Unauthorized
2.2.2 Returns/60-day Right of Recredit
2.2.3 Real-time Online Account Number Verification
2.2.4 Account Numbers
2.2.5 Non-Sufficient Funds
2.3 CASE STUDIES/EXAMPLES
2.3.1 Case 1 - Fraudulent Use of Stolen Bank Account
2.3.2 Case 2 - Buyer Beware” Fraud
2.3.3 Case 3 - Fraudulent Use of a Corporate Account
3.0 TRANSACTION-LEVEL FRAUD
3.1 INTRODUCTION
3.2 TRANSACTION-LEVEL FRAUD CATEGORIES
3.2.1 Transport Vuln
3.2.2 Price Changing
3.2.3 Login ID, Username and Password Crackers
3.2.1 Case 1 - Insecure File Transmission
3.3.2 Case 2 - Price Changing
4.0 IDENTITY THEFT
4.1 DESCRIPTION
4.2 IDENTITY THEFT CATEGORIES
4.2.1 Types
4.2.2 Methods
4.3 CASE STUDIES/EXAMPLES
4.3.1 Case One - GAO Identity Theft Case
4.3.2 Case Two - Corporate Executives as ID Theft Victims
4.3.3 Case Three - Internet ID Theft
4.3.4 Case Four - Establishment of New Accounts
4.3.5 Case Five - Systematic Theft of Social Security Numbers
5.0 MERCHANT-LEVEL FRAUD
5.1 INTRODUCTION
5.2 MERCHANT-LEVEL FRAUD CATEGORIES
5.2.1 Employee-Initiated Fraud
5.2.2 Fraudulent Auction Sellers
5.2.3 Spoofing
5.2.4 Merchant Non-Delivery/Bankruptcy-Related Fraud
5.2.5 Hacking into a Legitimate Merchant Site
5.3 CASE STUDIES/EXAMPLES
5.3.1 Case 1 - Triangulation
5.3.2 Case 2 - Corporate Payroll Check Number
5.3.3 Case 3 - PayPal Website Spoof
5.3.4 Case 4 - Last Minute Address Changes
6.0 STAKEHOLDER IMPACT
6.1 CONSUMERS
6.2 MERCHANTS
6.3 FINANCIAL INSTITUTIONS
6.3.1 Merchant Financial Institutions
6.3.2 Consumer Financial Institutions
6.4 PAYMENT SYSTEMS
7.0 TIPS FOR MANAGING FRAUD RISK
7.1 FINANCIAL INSTITUTIONS
7.1.1 Verification and Authentication Procedures
7.1.2. Secure Data Management
7.1.3 Real-time Fraud Detection Capabilities
7.1.4 Internal Audit and Control Procedures
7.1.5 Remediation Activities
7.2 MERCHANTS
7.2.1 Verification and Authentication Procedures
7.2.2 Internal Data Security
7.2.3 Order Screening...
7.2.4 Fraud Detection Capabilities
7.2.5 Internal Audit/Control Policies
7.2.6 Non-Sufficient Funds (NSFs)
7.3 CONSUMERS
7.3.1 Information Protection
7.3.2 Fraud Detection..
7.3.3 Fraud Remediation
8.0 CONCLUSION
9.0 FRAUD MANAGEMENT REFERENCES
9.1 U.S. GOVERNMENT RESOURCES
9.2 INDUSTRY RESOURCES...
9.3 PRIVATE RESOURCES
9.4 OTHER RESOURCES
10.0 APPENDICES
10.1 GLOSSARY
10.2 APPENDIX - GENERAL SECURITY CHALLENGES
10.2.1 Generalized Hacking
10.2.2 DOS- Denial of Service
10.2.3 Trojan Horse Attacks (And Worms and Viruses)
10.2.4 Transport Vulnuerabilities
10.2.5 Many to One Logins
10.2.6 Buffer Overflows
10.2.7 Cross-site Scripting
10.2.8 Outsourcing
10.2.9 Script-Based Attacks
10.2.10 Incorrect Coding
10.2.11 Authentication-only
10.2.12 HTTP Secure Form Post
10.2.13 Credit Balance Refund
Confusing Authentication and Identiification?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/21/2003 11:31 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Confusing Authentication and Identiification?
Does identity management clash with privacy
http://www.infoworld.com/reports/SRidmgmtandprivacy.html
Frequently it seems that it isn't an identity management issue, but
confusing identification and authentication.
One of the things in X9.59 was rather than trying to blanket the world with
deep layers of encryption (in order to protect credit card numbers, which
still had to appear in the clear because of numerous business process
issues) was to convert the information from shared-secret (needing hiding,
privacy, confidentiality and encryption) to a non-shared-secret with
authentication.
In the existing process with non-authenticated transactions, just learning
a credit card number is sufficient for somebody to generate a fraudulent
transaction (effectively making the credit card number a shared-secret and
classified as one of the identity theft items). x9.59 changes the
transactions from non-authenticated to authenticated and eliminates the
ability to use an (x9.59) account number in fraudulent transactions. Not
being able to use the account number for fraudulent transactions eliminates
it as being classified as shared-secret or target of identity theft. In the
non-authenticatted paradigm, it was not possible to bury the earth under
deep enough layer of encryption to really protect it, since it was required
to be in the clear as part of so many business processes.
Part of the issue is being able to strongly characterize and differentiate
authentication from identification. Changing a paradigm from
identification-basd to authentication-based goes much further to protecting
individuals, aka extermely strong encryption for protecting shared-secret,
sensitive, and confidential information may be good, but not having
shared-secret, sensitive, and confidential information is even better.
Electronic transactions tend to involve authentication and permissions (or
authorizations). Permissions and authorizations may also be considered as
class of sensitive and confidential information (say like printing the
current credit limit). Good protocols might be considered to be some simple
authenticated request or assertion with simple yes/no response. This was
the paradigm followed in X9.59 protocol work as well in the FSTC FAST work
(effectively a debit-like transactions but instead of making an assertion
about payment that was approved or not, the FAST assertions were about
other facts like age limit, local liqueur/gambling regulations, etc). In
the FAST scenario, it wasn't necessary to divulge a person's birth date, it
was sufficient to assert that they were over 21 (or 18) and validate the
assertion.
misc past authentication/identification threads:
https://www.garlic.com/~lynn/aepay10.htm#5 I-P: WHY I LOVE BIOMETRICS BY DOROTHY E. DENNING
https://www.garlic.com/~lynn/aepay10.htm#77 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#58 PKI's not working
https://www.garlic.com/~lynn/aepay11.htm#60 PKI's not working
https://www.garlic.com/~lynn/aadsm10.htm#cfppki15 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#cfppki18 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm10.htm#paiin PAIIN security glossary & taxonomy
https://www.garlic.com/~lynn/aadsm10.htm#anonpay Crypto Winter (Re: Looking back ten years: Another Cypherpunks failure)
https://www.garlic.com/~lynn/aadsm10.htm#bio3 biometrics (addenda)
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
https://www.garlic.com/~lynn/aadsm12.htm#32 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction?
https://www.garlic.com/~lynn/aadsm12.htm#53 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm13.htm#12 Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
https://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
https://www.garlic.com/~lynn/aadsm14.htm#13 A Trial Balloon to Ban Email?
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#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#41 certificates & the alternative view
https://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy
https://www.garlic.com/~lynn/99.html#224 X9.59/AADS announcement at BAI this week
https://www.garlic.com/~lynn/99.html#226 Attacks on a PKI
https://www.garlic.com/~lynn/2001c.html#8 Server authentication
https://www.garlic.com/~lynn/2001f.html#31 Remove the name from credit cards!
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#1 Are client certificates really secure?
https://www.garlic.com/~lynn/2002.html#39 Buffer overflow
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/2002f.html#22 Biometric Encryption: the solution for network intruders?
https://www.garlic.com/~lynn/2002g.html#66 Formal Classification for Security Topics
https://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
https://www.garlic.com/~lynn/2002m.html#19 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#53 Authentication of others is a privilege, not a right
https://www.garlic.com/~lynn/2002n.html#13 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#19 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002n.html#25 Help! Good protocol for national ID card?
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
https://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003f.html#35 Public Encryption Key
https://www.garlic.com/~lynn/2003f.html#37 unix
https://www.garlic.com/~lynn/2003h.html#18 Authentication protocol
https://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
Confusing Authentication and Identiification?
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/21/2003 02:29 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Confusing Authentication and Identiification?
Early in the x9.59 process there were a number of blatently erroneous
assertions that account-based represented a closed infrastructure
while certificate-based repesented an open infrastructure.
Basically, in both account-based and certificate-based infrastructures
... there can be public key owners, relying parties, and certification
bodies. An account-based infrastructure tends to provide online
certification while a certificate-based infrastructure tends to create
stale, static copies of information (kept in accounts by the
certification authority) that can be used in offline scenarios.
In both account-based and certificate-based operations, you could have
the same exact information being certified, the same exact public key
owners, the same exact relying parties and the same exact certifying
authorities.
An account-based and certificate-based operation can be equally closed
or open based on the type of information being authenticated and the
degree of trust that the certifying bodies have among the population
of relying parties. The blatently erroneuous statement about
account/certificate operations differing by being closed/opened wasn't
the differentiator; the differentiator between account/certificate
operations tends to be whether it is an online operation vis-a-vis
offline operation.
The other scenario, was that some x.509 identity certiificate
operations fell into the trap of thinking that they could grossly
overload certificates with large amounts of identity and privacy
information and widely publish and distribute the information all over
the world. As it began to dawn on them that this probably wasn't a
good thing, there was a significant reduction in the types of
information that might be published in a certificate (many financial
institutions retreating to a relying-party-only certificate containing
a public key and a customer account number). As the types of identity
and privacy information that might be globally published became more &
more restricted, effectively certificates became more and more of a
closed environment. In that sense, the FSTC FAST paradigm actually
represents more of an open infrastructure than any of the privacy
tainted certificate paradigms, since it is possible for FSTC FAST to
provide online response to an "over 21" assertion w/o divulging the
birth date, or to provide an online response to "pay $100" assertion
w/o divulging the account balance or the person's name or address.
The issue regarding account-based vis-a-vis certificate-based is one
of online vis-a-vis offline. However, a online infrastructure has some
degree additional latitude in validating various kinds of
authenticated assertions w/o unnecessarily divulging identity and/or
privacy information which would typically be found in a
certificate-based implementation.
In that sense, given any concern over not wanting wide-spread
publication and distribution of large amounts of identity and privacy
information, an online certification operation might be considered to
be somewhat more open than a certificate based information .... since
it could perform more types of (online) validations w/o unnecessarily
widely publishing identity and privacy information. The online
paradigm tends to also deal with much more dynamic data (like current
account balance) which can be of much more value compared to the
offline paradigm (like whether or not a person did or didn't have a
specific bank account at some time in the past).
somewhat related, the IETF AAA working group just published a new RFC
3539 PS
Authentication, Authorization and Accounting (AAA) Transport Profile,
Aboba B., Wood J., 2003/06/20 (41pp) (.txt=93110) (was
draft-ietf-aaa-transport-12.txt)
for a complete list of AAA working group RFCs go to
https://www.garlic.com/~lynn/rfcietff.htm
and select Term (term->RFC#) and then scroll down to
"Authentication, Authorization, and Accounting"
Authentication, Authorization and Accounting
see also accounting , authentication , authorization
3539 3127 2989 2977 2906 2905 2904 2903
past discussions of relying-party-only certificates:
https://www.garlic.com/~lynn/subpubkey.html#rpo
misc. past threads with open/closed & aads/cads:
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#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die
https://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop
https://www.garlic.com/~lynn/aepay4.htm#privis privacy issues
https://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards
https://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
https://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
https://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
https://www.garlic.com/~lynn/aadsm14.htm#16 Payments as an answer to spam
https://www.garlic.com/~lynn/2001d.html#41 solicit advice on purchase of digital certificate
https://www.garlic.com/~lynn/2001g.html#55 Using a self-signed certificate on a private network
https://www.garlic.com/~lynn/2002j.html#40 Beginner question on Security
Confusing Authentication and Identiification?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/23/2003 12:04 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Confusing Authentication and Identiification?
anders.rundgren@xxxxxxxx on 6/22/2003 1:01 pm wrote:
Lynn,
May I interrupt your crusade against X.509?
I would like to know what you consider redundant in an
X.509 certificate.
Is it the account number (Subject DN)?
Is it the public key?
Is it the extension pointing to an OCSP responder?
Or is rather the CA signature and associated
path-validation (and build) that you consider a problem?
Anyway, disregarding the fact that account-based infrastructures have
little support in current SW platforms, how would an account-based
infrastructure be implemented for an e-government scenario where
several millions of citizens (having a state- defined "account
number") are served by thousands of independent "e-services"? The
X.509 version of this is running in Sweden and uses a number of
independent TTP CAs (mostly banks) to provide certificates with the
proper "account number".
Anders
============================================================
In the relying-party-only certificates that the financial institutions
went to in the mid '90s after the retreat from the forey into identify
certificates from the early 90s .... the certificate contained an
account number and a public key. In the business process analysis, a
relying-party-only certificate is appended to a digitally signed
transaction that is sent back to the relying party. Doing an
end-to-end business process analysis:
1) the relying-party had the original copy of the relying-party-only
certificate stored in the account record
2) for 8583 financial transactions, it was realized that the payload
of a typically certificate was 10 to 100 times larger than the
transaction itself (aka a certificate containing only an account
number and a public key was ten to one hundred times larger than the
base transaction payload) 3) the typical signed transaction already
contained the account number, making the account number also in the
relying-party-only certificate redundant and superfluous
4) since this was a relying-party-only certificate, and only the
account number was present, it was necessary to retrieve the
actual account record in order to perform any processing (the
certificate just contained a redundant index, i.e. the account number,
to retrieve the actual information that was either a) a serious
privacy violation to include in the certificate and/or real-time
and/or aggregated information that could be loaded into a stale,
static certificate built at some point in the past
5) the account record contained the original copy of the certificate,
including the public key. so the only other piece of information in a
relying-party-only certificate was the public key .... but for
relying-party-only transactions with relying-party-only certificates,
it was necessary to read the account record that contains the original
of the relying-party-only certificate, including the public key. That
made transmitting the other piece of information in the certificate,
the public key also redundant and superfluous (since it could be found
in the account record).
So tt was trivial to show that for relying-party-only certificate that
is was possoble to either
1) compress the relying-party-only certificate to zero bytes since it
only contained redundant and superfluous information that was easily
found elsewhere
or
2) recognized that the relying-party had the original copy of the
relying-party-only certificate that would be read with the account
record. sending a copy of the relying-party-only certificate to the
public key owner so the public key onwer could return the copy of the
relying-party-only certificate to the relying-party on every
transactions (especially in cases where the size of the
relying-party-only certificate was ten to hundred times larger than
the size of the base transaction) when the relying-party had the
original of the relying-party-only certificate. This could be treated
that the relying-party always had the original of the
relying-party-only certificate (if you will, effectively cached)
.... so it was redundant and superfluous for the public key owner to
return a copy of the relying-party-only certificate to the
relying-party which had the original of the relying-party-only
certificate.
so the issue is that the vast majority of electronic transactions that
occur in the financial infrastructure (well over 90%) have SW support
for account-based infrastrcutre. There is some amount of internet
related SW that aren't well integrated into the fundamental
core-infrastructure that tend to be offline PKI oriented rather than
online, account, core-business process oriented; possibly since a lot
of the internet related SW have been produced by PKI oriented vendors
that are interested in pushing their products.
lots of past descriptions of the relying-party-only certificate
end-to-end business process scenario
https://www.garlic.com/~lynn/subpubkey.html#rpo
specific past threads regarding relying-party-only certificate
end-to-end business process description which you participated in:
https://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
https://www.garlic.com/~lynn/aepay6.htm#dsdebate Digital Signatures Spark Debate
https://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aadsm11.htm#19 IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm11.htm#21 IBM alternative to PKI?
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#26 I-D ACTION:draft-ietf-pkix-usergroup-01.txt
https://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#28 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
https://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories
Confusing Authentication and Identiification?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/23/2003 01:51 PM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Confusing Authentication and Identiification?
anders.rundgren@xxxxxxxx on 6/23/2003 1:15 pm wrote:
Lynn,
Relying-party certificates applied to the described scenario would
add a $5-$20 RA cost per user and add extreme user-inconvenience
in the [very likely] case a user would need to go to multiple
e-government portals. That is, relying-party-only PK schemes, be
it account or certificate-based, are not candidates for e-governments
communicating with citizens.
In your earlier posting you claimed that account-based schemes
could do the same thing as certificate-based dittos; Could you
please provide some more data to support this view by applying
your thinking to the described TTP-based scenario?
Anders
ok, the previous reference was to three business entities:
1) public key owner ... that sends a self-signed message off to a
registration authority
2) a certification authority (CA) that includes a registration
authority (RA) that certifies something about the public-key owner's
public key (the public-key is basically some form of authentication
material that is certified by the CA as being associated with the
public key owner). This information is recorded by a CA in some
account record
3) the relying party which relies on the CA for validating some
assertion by the public key owner.
My assertion is that the above description applies to all of the
business models .... whether it is certificate-based or
certificate-less based or online or offline.
An example of an online version of the above (modulo the issue of
whether public key is the authentication material) is the world-wide
debit and credit networks. Another example is the Kerberos which is
the basic authentication infrastructure for a multitiude of
platforms. Another example is RADIUS which is the majority of the ISPs
in the world today.
Modulo the issue of public key issue, the X9.59 standard provides the
definition for switching to public key based authentication
infrastructure for all electronic retail payments (debit, credit,
stored-value, ach, internet, non-internet, point-of-sale, etc)
Modulo the issue of public key issue, the PK-INIT draft for Kerberos
defines initial public key authorization for Kerberos.
Modulo the issue of public key issue, there have been several RADIUS
implementations that add account-based digital signature
authentication to the suite of authentication protocols supported by
RADIUS infrastructure.
So the assertion is that the majority of authentication events (even
internet) that occur in the world today are fundamentally
account-based (modulo some SSL that are primarily certificate
manufacturing based, not PKI).
Now back to the original description, even for PKI infrastructures
that choose to issue stale, static certificates for situations where
the relying-party can't directly contact the certification authority
... as happens in credit transactions, debit transactions, kerberos
login and authorization transactions as well as ISP login RADIUS
transactions. Fundamentally, a certificate represents some stale,
static subset of information that is recorded at the certification
authority account record. The purpose of issueing the certificate is
to support relying parties that would have no direct or online access
to certification authority (as per credit network, debit network,
kerberos implementations, radius implementations, etc).
So the fundamental assertion is the reason for the existance of
stale, static certificate is to cover situation where the relying
party hasn't online and/or realtime connectivity.
A possible issue is that lots of PKI documentation grossly confuse the
issue of certifications with certificates. For at least 30 years with
online systems, there have been certifications w/o certificates
because of the availability of online, realtime connectivity between
the relying party and the certification body. Certificates are purely
a representation of the certification for use in offline environment.
So a dozen e-government websites could be totally implemented using an
account-based, online infrastructure supporting digital signature
RADIUS. A RADIUS-based implementation then opens up for selective
support of authentication, authorization, permissions, and accounting
on a website by website basis.
Confusing Authentication and Identiification? (addenda)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/24/2003 11:10 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
cc: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
Subject: Re: Confusing Authentication and Identiification? (addenda)
slightly related reference to the discussion about differentiating
certification from certificates .... where certification can be either
online or offline ... it is the business process .... and certificates
is a specific delivery mechanism for an offline environment/paradigm.
https://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
so an extremely widely deployed internet online authentication
mechanism ... that is sort of a subset of online credit/debit is
the age verification mechanism in use by the adult entertainment
business. Baiscally, having a valid credit card is assumed to be
equivalent to a being of age to sign a valid contract. So the online
age authentication asks for sign-up/registration by filling in credit
card information .... with a disclaimer that nothing shows up on your
bill. Basically, they take the credit card information and do whats
called a one dollar auth. If there is a positive response from the
credit card transaction, the online age authentication service then
creates its own account record as to the validity of the entity. In
the future, when visiting an adult website, there is a request to do
an online transaction with one of the age authentication services
.... which then does an online lookup and provides a response to the adult
website. FSTC's FAST would have been able to provide something similar
directly from the financial institution rather than going through a
two-level authentication infrastructure.
note that intrinsicly the 8583 network isn't necessarily a
high-overhead transaction. There is wide deployment in the US of
magstripe online stored-value mechanism that use the same
point-of-sale terminal & network as the credit & debit card
transactions; modulo the issue of fraud management, an internet 8583
payment gateway could also handle internet debit and stored-value
transactions as easily as it handles internet credit transactions (it
isn't a technology issue, it is a business management issue).
another one of the examples is RADIUS authentication server for a
multitude of widely deployed relying-parties. An example is some of
the large US ISPs that have either their own POPs (point of present);
local telephone numbers or contract with other vendors for POPs. This
can involve hundreds, if not thousands of routers distributed thru-out
the US (and the world). ISP customers may have on the order of a thousand local
telephone numbers around the world that they can call and connect to
their ISP. Each one of these POPs tends to have local ROUTERs that
performs the initial authentication of the incoming call before
allowing connection to the ISP services. As mentioned, the numerous
POPs may actually belong to the ISP, or belong to some other
organization that the ISP has a contractual relationship
with. Basically these thousands of routers around the world have
direct connection to the ISP's RADIUS server in order to obtain the
authentication information as well as various authorization and
accounting information. While the extensive use of RADIUS as the
fundamental authentication mechanism on the internet is used by PPP
for client to ISP connection, the RADIUS service is a generalized
facility that can be called by a large number of different
operations. For instance, there are typically RADIUS plugins for many
of the available webservers that support client authentication via
RADIUS service. The use by ISPs of RADIUS for account-based
authentication, authorization, and accounting control spanning the
world and thousands of servers .... easily exceeds the requirements
and demands of any existing e-gov webserver infrastructures.
In fact, given that ISPs supported account-based digital signature
RADIUS authentication, and some contractual relationship between a
collection of e-gov servers .... it would be possible for e-gov server
to directly rely on the ISPs' authentication process w/o requiring a
separate e-gov portal authentication service.
Many of the existing e-gov authentication portals basically implement
the KERBEROS model with proprietary technology. An e-gov
authentication portal could implement a PK-INIT Kerberos digital
signature authentication and provide KERBEROS authentication for all
the other webservers in a particular e-gov infrastructure. This
basically allows for adoptation of standard distributed authentication
infrastructure using existing factilities already available on the
base platforms that any of the e-gov initiatives are deployed on.
Not only is account-based authentication the dominant and most widely
used authentication paradigm in the world today .... but some flavor
is built into most of the base platforms.
misc. past descriptions of the one dollar auth scenario
https://www.garlic.com/~lynn/aepay3.htm#x959risk2 Risk Management in AA / draft X9.59
https://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda)
https://www.garlic.com/~lynn/aadsm3.htm#cstech8 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die
https://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt
https://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/2003h.html#18 Authentication protocol
https://www.garlic.com/~lynn/2003h.html#23 Authentication protocol
misc. past RADIUS threads:
https://www.garlic.com/~lynn/subpubkey.html#radius
misc. past Kerberos threads:
https://www.garlic.com/~lynn/subpubkey.html#kerberos
Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/25/2003 08:53 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
this is grossly confusing, dynamic, realtime paradigm with the stale,
static, certificate offline paradigm. the credit/debit 8583 online
network has worked with multiple "handles" for 30 years or so. You can
have dozen of cards ... and each card can actually have one or more
account numbers .... you do a transaction and the handle/account
number gets filled in appropriately in real time. RADIUS works for
corporate accounts and all the ISP accounts. I have multiple accounts
and all the appropriate handle/account information is filled in
dynamically, its gets correctly routed and processed w/o anybody
worrying that it can't work unless I have the same username on my
corporate login as well as every last one of my multiple ISP accounts.
The problem with stale, static, certificates that were manufactured at
some point way in the past with no real good idea what future purposes
that the certificate might be used for. The problem isn't so much that
the same certificate wants to be used with huge number of different
relying parties .... it was at the time that the certificate was
manufactured that a one and only one stale, static account
number/handle had to be selected. The issue in the certificate
business ... is that certification is somewhat expensive .... and to
work with stale, static information ... that can be globally used
.... you have to convert the whole-world to a single handle/account
number .... or have multiple relying-party-only certificates, one for
each environment.
There are at least tens of thousands of financial institutions all
issuing account numbers and all getting routed accordingly. It turns
out the account numbers are partly routing code and partly individual
unique
Extended outside of the financial infrastructure .... to all the ISPs
in the world .... frequently you have to configure your TCP/IP client
to have a prefix like:
XXXX/username
this in part directs the routers by 3rd party POP operators to deal
with the appropriate RADIUS server for the authentication
information. So not only does it work for 99.999999999 percent of the
online financial trransactions ... but it also works for 99.9999999
percent of the people accessing the internet around the world.
The issue of a globally unique identifier is not a requirement of an
online authentication infrastructure. The issue of a globally unique
identifier is a requirement for stale, static certificate paradigm
with regards to not needing to issue a unique relying-party-only
certificate (for every environment) and allowing a single stale,
static certificate to used in multiple environments.
Now, for an online environment ... there is context in the type of
authorization and the type of message. Now, if i was inventing a
single transaction protocol and message interface ... where the same
exact message format was used for all contexts .... i.e. a
x9.59/iso8583 financial message had the same format as a radius
connect to the internet message; then i could hypothosize overloading
the entity handle with type of message, type of transaction, type of
entity, routing information, and personal information. That way ... I
could use the same account number and same message format and same
network interface for logging in via RADIUS as I used for performing a
credit operation. The network interface could figure out what i
intended to do.
anders.rundgren@xxxxxxxx on 6/25/2003 12:53 am wrote:
A problem in this area is the all-over-the-map representation
of entities when you go outside of the original (bank) account
number. Well, even these show some variances, don't they?
So when Lynn claims that the account number is redudant in
for example certificates as it is already in the transaction payload,
this is by no means a universal truth if you extend transactions
outside of the financial area.
In order to actually eliminate certficates or just be able to match
the "account number" (the entity's identity) as expressed in a
certificate with transaction payloads we need to have a universal
naming method. Currently we don't have that. Even major B2B
efforts like ebXML still have not solved this in an non-ambigous
way. I.e, it is hard for many people to leave (or rather reduce the
importance of) the attribute style of describing an entity's identity
like: Locality, Common Name, Phone number etc. That hardly
any business system in the world uses anything but a customer ID
(account number) is still not generally recognized.
I'm am plotting with an Internet Draft which defines a universal
globally unique "account number" consisting of a 2-dimensional
structure like the following:
NameSpace : LocalID
NameSpace is a Universal Resource Identifier (URI) that identifies
the owner of the "namespace". Samples:
urn:visa:cc
http://xmlns.ibm.com/employees
LocalID is just a string that is guaranteed to uniquely identify the entity
in the associated NameSpace. Samples matching the previous sample:
46566777555556766
35467
For X.509 certificates there is a specific extension in preparation that
enables the inclusion of such account numbers without disrupting
the current use of Subject DN:
____
/ \
| CA | Naming Domain: http://sample-registry.org/members
\____/ PI Attribute: serialNumber
/ \
/ \
/ _\__
| / \
| | EE | Subject: CN=John Doe, serialNumber=43155, C=US
| \____/
_|__
/ \
| EE | Subject: CN=Marion Anderson, serialNumber=43566, C=US
\____/
That is, Marion's ID could using PI be expressed like:
"http://sample-registry.org/members" : "43566"
As an option the permanent identifier descriptor MAY declare a
separate PI naming domain.
Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/26/2003 10:28 AM
To: Anders Rundgren <anders.rundgren@xxxxxxxx>
cc: internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
As previously outlined, the process used in the financial
infrastructure is exactly what the ISPs do for user login. The POPs
typically either:
1) a specific phone number select specific router that have a static
binding to a specific RADIUS server (this is like walking into your
local branch). the selection of the RADIUS server (and the userid
selects the appropriate account record) is basically performed by what
phone number the client dialed. The phone number used for dialing the
ISP service has effectively done the routing specific selection.
2) the client has their PPP software configured with a prefix in front
of the userid, something of the form: XXXX/userid. The router then
selects the appropriate RADIUS server based on the XXXX prefix. The
XXXX prefix has then the equivalent of the routing number part of a
financial account number.
In the financial industry, the account number contains both the
institutional context (routing number) and account specific
information in a single number.
In the ISP industry, the routing context (how to get to the correct
RADIUS server account record) is either determined statically by the
(initial) physical connection or the routing value for the correct
context (XXXX prefix) is supplied as part of the connection
transaction.
So we have instance examples of both the financial industry and the
world-wide-internet-service-provider industry working exactly the
same.
In some past descriptions regarding bilaterial business contracts, a
company may do a background check with credit bureau, D&B, and the
other company's bank. They then set up an account with various pieces
of information regarding the agreed upon business relationship, T&Cs,
etc. That account information traditionally shows up on things like
purchase orders, etc. Even in the case of past descriptions of SSL
domain name certificates, the TTPs are doing D&B checks.
The purpose of a certificate is to carry stale, static subset of
information from some account record someplace so that a relying-party
can complete a transaction without recourse to the real copy of the
information (since if they had recourse to the master account record,
the stale, static subset of the information obviously becomes
redundant and superfluous).
So lets look at the relying-party-only certificate scenario for
performing a transaction w/o recourse to the real, online information:
A transaction is created with the financial account number or ISP
login userid (aka some sort of business context specific handle,
specific to that environment and transaction). It is digitally signed
The relying-party-only certificate is appended and all three pieces
(triple) are transmitted. The relying-party receives the transmission
and first tries to figure out if they can perform the business process
based on only having the triple (again the whole point of a
stale, static certificate as a subset/copy of the account information when
there isn't recourse to the real information). Lets keep it simple and
say that it is only ISP login. The relying-party (ISP) validates the
certificate, and then validates that the digital signature with the
public key. Everything works. The vulnerability/exploit is that the
userid in the LOGIN transaction and some "handle" in the certificate
have to match. If the process doesn't require that the two items have
some matching value, then theoretically I could sign up for a any
random userid at that ISP, get a certificate, and use a valid
certificate to login into every userid at the ISP.
This is the traditional chain of trust scenario that is described in
almost every description of a certificate-based TTP operation. The
relying-party has a table (or set of account records) of trusted TTP
public keys. It uses the approprirate TTP public key to verify a
presented certificate, it then uses the public key in the certificate
to verify the digital signature on some transaction. It then typically
uses some information in the certificate (that is bound to the public
key) to connect the certificate to the contents of the
transaction. This is how financial relying-parties make sure that a
person only does withdrawals from bank accounts that they are actually
entitled to withdraw from. Just having some random valid certificate
doesn't mean that you can perform operations on all accounts at that
financial institution.
So the redundant and superfluous scenario is that any present day
operation of almost any value typically has the relying-party
resorting to real-time access to real-time and/or aggregated
information in some account type record. As previously described,
financial transactions started 30 some years ago having realtime
access to the existing account balance. ISPs do it to have access to
currently valid accounts. The transaction specifies necessary and
sufficient information to specify the requested operation (including
the handle or account number) and the account provides all the
information necessary to correctly complete the transaction. Upgrading
existing shared-secret based operations to non-shared-secret, replaces
a password or PIN on the transaction with a digital signature and
replaces the PIN/password in the account record with a public key.
stale, static certificates are superfluous in online environment where
the relying-party has direct access to the original of the information
that provides the context for performing the business process
(purchase order, credit card transaction, ISP login). The account
record contains all the information necessary to do real-time
operation on the business process, including things like
authentication information, aggregated information (transactions done
to date), real-time information (remaining balance, which could
represent a sequence of aggregated operations). In the real-time
chain-of-trust scenario, the account number or userid in the
transaction indexes the account record, the digital signature on the
transaction is validated with the public key in the account record,
and the account record provides all the real-time information
necessary for the relying-party to complete the transaction.
So, how do you translate that from a relying-party-only certificate
operation to a single certificate operation? The traditional
chain-of-trust scenario says the transaction contains some handle or
identifier; that handle or identifier can be matched in the
certificate which shows that the transaction and the certificate
relate to the same operation. If it isn't a relying-party-only
certificate, but some certificate that has a globally unique
identifier ... then has does a single certificate with a globally
unique identifier provide the necessary and sufficient trust for a
broad range of business transactions from credit card transactions to
ISP loging to business purchase order across a broad range of
different entities.
The design point (purpose) of (stale, static) certificates was to
provide chain-of-trust for performing operations when the
relying-party didn't have real-time and/or direct access to the real
information. The stale, static certificates were desgned as a sort of
stand-in/substitute when the relying-party couldn't directly access
the real information.
So instead of authentication, the single stale, static certificate
with globally unique identifier would appear to be heading in the
direction of identification in place of authentication. Rather than
authenticating the public key owner as being authorized to perform a
specific operation in a specific business operation .... it would
appear that the single, stale, static certificate paradigm with a
globally unique identifier is heading in the direction of
identification of the public key owner as opposed to authentication of
the public key owner (just the semantics of globally unique identifier
seems to carry with it the conotation of identification).
Now it is difficult to see how a single, stale, static certificate
with a globally unique identifier would provide the necessary business
process context (and chain of trust) to indicate that a specific
person is authorized to do arbritrary credit card transactions as well
as arbritrary ISP logins (where the relying-party is performing this
determination in an offline manner w/o access to the real account
record).
One might imagine a world of where every valid citizen is
authomatically authorized to do everything, once they are
identified. All possible transactions only require
identification. There are no individual business process that are
relying-party specific as to whether a citizen is authorized or
not. The global (government?) authority gets forwarded all citizen
transactions that occured during the month for the aggregated
activities of their identified citizens and reconciles each citizens
monthly balance sheet.
Which somewhat gets back to the original subject line regarding is
authentication and identification being confused.
anders.rundgren@xxxxxxxx on 6/26/2003 6:27 am wrote:
Global account numbers (entity IDs) are redundant?
Well, that means that business entities must use their partners' unique local account ID
when they send for instance a purchase order. It also means that you must keep
records of all your business parties local ID of _your_ entity. Having global
account numbers you can safely ignore your business partners' account IDs
of your business except when you get something in return like an invoice. In
those situations it is nice to have the partner's local ID of you, as call-
centers usually look on local IDs which are the index in the databases
as well.
Only in a relying party PK-model global account numbers become redudant.
In such systems you not only need to have the unique local ID but also
unique private keys depending on the verifiers policy.
Further advantages with global account IDs is that TTPs can provide
services like credit status. This is one of the reasons D U N S is
often required in the states. But are D U N S globally unique?
In fact they are, it is just that you currently have to _know_ that
it is a D&B-assigned number and not some other registry. The
described IETF-draft in preparation is designed to solve this by
adding a universal "account authority" solution.
My conclusion is that the mechanisms used in the financial industry
does not perfectly match the needs of non-payment "transactions".
For list-usage reasons I will though refrain from further discussions
on this particular subject.
/ar
Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/26/2003 06:54 PM
To: Todd Boyle <tboyle@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
internet-payments@xxxxxxxx, epay@xxxxxxxx
Subject: Re: Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
the repeated claim in this (and other threads) is that X9.59
eliminates secrecy as requirement to guarantee the integrity of the
financial infrastructure (the requirement given the X9A10 working
group for the X9.59 standard for all electronic retail payments).
the authentication requirement with x9.59 turns all retail payments
into authenticated transactions, eliminates any requirement for any
identification information and removes the characteristics of the
account number from being a shared-secret (i.e. the account number is
currently has the status of a shared-secret, since just by learning
the account-number it is possible to execute fraudulent transactions).
The business process issues are
1) is authentication or identification required (as per the original
subject line). this can be carefully considered. using the same basic
technology, it is fundamentally possible to implement either. it is
not an either/or possibility. the government could choose to reliably
make your digital signature equivalent to your identity. that is a
government and business process choice. however, it is not intrinsicly
part of digital signatures. It is possible to create a digital
signature infrastructure and protocols that are agnostic to whether
the government has created an infrastructure making digital signatures
and identity equivalent. The issue that the original subject line
highlighted is that frequently the technology of authentication and
the implementation choice regarding authentication vis-a-vis
identification can be grossly confused and lead to inappropriate
implementations. This is one of the reasons that most institutions
backed away from the original x.509 identification certificate
paradigm, the inclusion of huge amounts of privacy information and
indescrimently spraying it all over the world was concluded to not be
a good thing.
2) certification is basically a business process that is independent
of whether it is deployed as a online process (with online
transactions) or manufacturing a stale, static certificate at some
time in the past as part of an offline paradigm. The certification
body and business reliance can be exactly the same in both cases. The
difference is whether the relying-party relies on a stale, static
certificate or relies on a real-time, online transaction. It can be
trivially shown that in almost all cases the online, realtime
responses is both higher quality and more valuable than reliance on
stale, static certificates. The absolutely worst case scenario
is that the high quality, realtime response is the same as stale,
static certificates. So one issue, is does the business justificy
the cost of the higher quality operation with an online, realtime
response vis-a-vis the possibly lower cost of the stale, static
certificate information. Certificates were original targeted in the
early '80s when there was not ubiquitous, inexpensive, easily
available online infrastructure. As the alternative to having no
certification (having NOTHING), certificates were better than
NOTHING. However, the trade-off has significantly changed with the
technologies of the later 90s with the penetration of inexpensive,
ubiquitous, pervasive online infrastructure. This is essentially the
transition that the online financial infrastructure made in the '70s
(offline to online).
In numerous past discussions, it turned
out that many of the issues with a global infrastructure didn't truely
require identification, but it for a specific business processes that
strong authentication was sufficient and identification was mostly
unrelated. For instance, it isn't necessary for all parties even
remotely involved in a financial transaction to absolutely know who
you are (aka identification) if strong authentication is sufficient to
establish that you are the entity entitled to withdraw funds from a
specific account (authentication). In fact, one of the additional
inducements for financial institutions to retrench to
relying-party-only certificates with absolutely no
identification information was an EU directive that said that retail
electronic transactions should be as anonymous as cash; specifically
that at the point of sale, the retail financial transaction needed to
be agnostic with respect to identity. That didn't preclude the
government from creating some identification procedure but it did
direct that the actual financial transaction was agnostic with respect
to identity.
As per the original subject line,
authentication is about determining is the entity entitled to perform
the operation .... without necessarily requiring that the entity also
be identified. It doesn't necessarily preclude there being some
process for establishing identification, the authentication process
can be agnostic with respect to identification.
There are
large groups of people on both sides of the argument with regard to
having authentication processes that absolutely prevent any
identification vis-a-vis the authentication process doesn't preclude
establishing identification under specific guidelines. When given a
requirement to guarantee transaction integrity, strong authentication
is sufficient and KISS to meet the requirement. Again that is the
original subject line; confusing authentication and identification.
However, the issue of offline, stale, static
certificates as a certification business process mechanism vis-a-vis
online realtime (account-based) certification is totally orthogonal to
authentication vis-a-vis identification issues.
The business
issue for authorizing a transaction in conjunction with an
authentication mechanism does come into play a little. I've frequently
facetiously referred to an authentication retail store; you walk in
authenticate (or even possibly identify) yourself and walk out. The
purpose of the retail store is not to actual sell anything, it solely
does authentication (possibly identification) operations. This is
opposed to retail stores that are there to sell some item,
authentication only comes into play when performing a financial
transaction (as part of paying for an item to buy). There is nothing
that is intrinsicly part of the run-of-the-mill financial retail
transaction that mandates identification (there may be other aspects
of some retail transactions that mandate identification, but with
regard to integrity of the financial transaction, strong
authentication is sufficient).
Now, each one of these
environments tend to have a specific business context which can be
taken into account with regard to an online, realtime
certification. The certification authority can examine what is the
context of the business process and make the appropriate
authentication with respect to that context; aka rights regarding
logging as a specific userid, rights to doing financial transactions
on a specific account, etc. There could be possibly hundreds of
contexts that an online, realtime certification authority could be
agile enough to adapt to.
The issue with a stale,
static certificates that are manufactured at some time in the past
with little or no fore-knowledge as to the business contexts is quite
a bit more problematic. There are basically three choices
1)
relying-party specific certificates, one for each possible business
context, each one providing the specific authentication context
(i.e. is the entity entitled to perform that specific operation).
2) we periodically run across things jokingly referred to as
GBD ... Great Big Database in the sky ... the mother of all databases
that contains all possible pieces of information. This is a
certificate that contains the necessary authentication information for
every possible business context (is the entity entitled to do the
specific operation in every individual business context).
3) switch from an authentication (whether or not the entity is entitled
to perform the operation) paradigm to an identification paradigm. The
assumption is that all validly identified individuals are entitled to
do everything, possibly a log is made of their activities and there is
some settlement made by the government at the end of the month (or at
some other interval). It then isn't necessary to provide all possible
authentications for every possible business context. Everybody, once
identified, are automatically entitled. The
stale, static certificate is then reduced from having to serve any
authentication purpose and is just relegated to only having to perform
an identification role.
Trying to establish the value of a PKI stale, static
certificate-based operation gets into this muddle. Huge numbers of
certificates, one for each context means that the individual value of
any specific certificate is significantly depreciated. A single
stale, static humongous GBC (great big certificate)
gets to become unwieldily having all necessary information for
authentication in all possible business contexts (aka whether the
entity is entitled to perform the operation). The GBC is also likely
to represent more in business costs than can ever be recovered in
certificate pricing. So it quickly comes down to that any sort of
major PKI infrastructure is pretty much stuck with an identification
paradigm. It isn't so much a business characteristic of certification
(which i've repeatedly asserted is totally independent of whether it
operates as offline, stale, static certificate, or a realtime,
online, certificate-less operation). Any major effort at PKI
with stale, static certificates pretty much concludes in the
identification model (aka #3 above). It is basically what the x.509
identification certificate scenario arrived at in the '80s and the
early '90s (effectively because of the considerations outlined
above). It is also what was rejected in the mid to late '90s because
of the serious privacy issues involved in making a ubiquitous
transition from predominately authentication paradigms to a
identification only paradigm.
The identification only scenario then still faces the serious business
quandary of whether an entity is actually entitled to perform the
specific operations in the specific context (independent of
identification). GLB, HIPAA and other privacy-related legislation is
also turning identification into more and more of a business expense
(because of the similar serious privacy issues).
Finally, in normal business, there is a relationship between the
provider of something and the purchaser of something. The typical PKI
business model is almost a total violation of any existing business
infrastructure. In all of the online models, the relying party
directly pays the certification agency for the online, realtime
certification response. There is a valid, direct business relationship
between the relying party and the online certification agency. Tbis
gets to be really horrible in the traditional, stale, static
certificate scenario. The business relationship is between the PKI and
the public key owner that purchases the certificate. There is no
exchange of value between the certification authority and the
relying-party which would be the basis for a normal accepted business
process. In the normal accepted business model today involving a
public key owner purchased certificate, there is no exchange of value
between the relying party and the certification body, and therefor
there would normally be absolutely no recourse for the relying party
(based on anything the certification body did or didn't do).
So the traditional PKI paradigm with stale, static certificates left
over from the offline paradigm is faced with:
1) significant transition throughout the world from an offline
environment to a nearly ubiquitous online environment
2) the whole rejection of x.509 identity oriented stale, static
certificates in the mid 90s because of serious privacy concerns.
3) difficult to create any value proposition for a stale, static
certificate since there is no business relationship between the
relying party and the certification body (the certificate isn't for
the benefit of the certificate owner, it is for the benefit of the
relying party .... however the relying party that would benefit, isn't
paying and therefor under normal business relationships has no
recourse to whether the certified information is valid or not).
So the next muddle is since that it really is difficult to establish a
viable business model .... turn it into a governement provided
identification service. In some sense this isn't an authentication
requirement, which can be handled perfectly validly with an online
paradigm and suffers none of the shortcomings of a stale, static
certificate paradigm.
In some sense, it is a extension of the line of thought that (stale,
static) "Certificates Are The Answer" and the government provided
identification service might appear to be the only viable way to
create a role for certificates. 1) Governments can mandate things and
totally ignore issues like the world transitioning to an ubiquitous
online environment. 2) Governments can madate things and totally
rewrite what are acceptable privacy guidelines and what are not. 3)
Governments can mandate things and totally dictate what relying
parties will accept.
So lets say we have a government mandated provided identification
service based on stale, static certificates. As outlined in the
previous post:
https://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identification? (addenda)
we have the case of doing ISP login using digital signatures. With the
stale, static certificate model, the router on receving the triple
(login transaction, digital signature, certificate) should have all
the necessary and sufficient information to establish the login
operation. The certificate gets validated as a valid, government
identification certificate and the public key from the certificate
validates the digital sginature; voila the person is connected w/o
needing to find out if the entity is entitiled or not
(authentication). There is absolutely no requirement for
authentication since the government identification certificate is
sufficient in establishing the right for service.
So we are led into this muddle that now has both 1) giveronment
identification stale, static certificates, and 2) a government
identification stale, static certificate is sufficient for
authorizing all operations w/o requiring any additional effort.
Now, unless we have created a totally government supplied world for
all possible services; there typically are business entities and they
establish some sort of business operation for services or
products. Today these business relationships are represented by
account records. People having contracted for ISP internet service
have a RADIUS account record. The logical account record (which may be
partitioned into several physical records) typically contains the T&Cs
of the business relationship as well as the necessary information to
authenticate the entity that is entitiled to use the contracted for
service. In the traditional business authentication-based scenario,
the entity creates a login transaction with the appropriate
authentication information (which I assert can be a digital signature)
and the double (aka transaction plus digital signature; not the triple
as in the stale, static certificate based scenario) is
transmitted. The receiving router gets the username (or other) handle
and retrieves the corresponding RADIUS record. The transaction is
authenticated with the information in the RADIUS record and then the
rest of the information from the RADIUS record indicates the entitled
to service. Lack of the appropriate RADIUS record or lack of
authentication is an indication that the requesting entity has not
contracted for the requested service.
In the offline, stale, static identification certificate
scenario, it is sufficient to identify the requesting entity, it isn't
actually necessary to establishing that the requesting entity is
entitled to the requested service (or is entitled to the explicit or
implicit permissions).
so back to the original subject line about 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?
https://www.garlic.com/~lynn/aepay11.htm#70 Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#71 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
tboyle@xxxxxxxx on 6/26/2003 12:31 pm wrote:
In the purest sense, an individual is a discrete entity
and why should their identifier be a topic of discussion?
In every advanced country we already have a name and
a government-maintained UID.
The financial industry (and others) needs to end their
reliance on secrecy of the UID and associated information
per se.
I am uneasy with Lynn's criticism of "stale" digital credentials,
since, how else is the individual ever to achieve the
capability to identify ourselves over networks?
At times I feel the internet may be truly, fundamentally useless
until there is a global and publicly accessible registry of
individuals and their public keys. As parties are not strongly
identified then, communication about things of consequence
is proving to be impractical. Everywhere I look, I see
large efforts and investments at the server side, to garner
some profit for (increasingly larger) central hosts. I see
nothing intended to give the economic benefits of the global
internet to individuals or endpoints on the internet.
With great reluctance I am beginning to agree with the
European governments' notions of providing a PKI for
their citizens. In the US, I believe it would be a good thing
if the federal government maintained a network interface
where anybody could submit a SSN, and receive in
return, the name, address, and public key of the individual.
Todd
x959 Postings and Posting Index,
next, previous
- home