Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
previous
- next
- home
- Flaw in RFID-enabled passports (part 2?)
- Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
- Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
- Citibank e-mail looks phishy
- Citibank e-mail looks phishy
- ATMs hacked using MP3 player
- Citibank e-mail looks phishy
- Citibank e-mail looks phishy
- What is the point of encrypting information that is publicly visible?
- Who has a Core Competency in Security?
- Who has a Core Competency in Security?
- What is the point of encrypting information that is publicly visible?
- Who has a Core Competency in Security?
- Who has a Core Competency in Security?
- Who has a Core Competency in Security?
- Who has a Core Competency in Security?
- Security Implications of Using the Data Encryption Standard (DES)
- Changing the Mantra -- RFC 4732 on rethinking DOS
- SSL (https, really) accelerators for Linux/Apache?
- Non-repudiation, Evidence and TLS: another fine mess I've got you into :-(
- Tamperproof, yet playing Tetris
- FC07 Preliminary Programme - Leaving Room for the Bad Guys
- Tamperproof, yet playing Tetris
- It's a Presidential Mandate, Feds use it. How come you are not using FDE?
- News.com: IBM donates new privacy tool to open-source Higgins
- EV - what was the reason, again?
- man in the middle, SSL
- man in the middle, SSL ... addenda
- man in the middle, SSL
- News.com: IBM donates new privacy tool to open-source Higgins
- man in the middle, SSL
- man in the middle, SSL ... addenda 2
- Failure of PKI in messaging
- Failure of PKI in messaging ... addenda
- Failure of PKI in messaging
- Failure of PKI in messaging
- New Credit Cards May Leak Personal Information
- Threatwatch: $400 to 'own' your account
- Usable Security 2007
- Usable Security 2007
- PKI: The terrorists' secret weapon
- PKI: The terrorists' secret weapon (part II)
- "Dilemmas of Privacy and Surveillance" report launched
- Cost of an identity
- Governance of anonymous financial services
- Cost of an identity
- The Founder Paradox
- SSL MITM-attacks make the news
- Governance of anonymous financial services
- Governance of anonymous financial services
- DNSSEC to be strangled at birth
- The One True Identity -- cracks being examined, filled, and rotted out from the inside
- The One True Identity -- cracks being examined, filled, and rotted out from the inside
- The One True Identity -- cracks being examined, filled, and rotted out from the inside
- What to do about responsible disclosure?
- The One True Identity -- cracks being examined, filled, and rotted out from the inside
- Threatwatch: MITB spotted: MITM over SSL from within the browser
- Our security sucks. Why can't we change? What's wrong with us?
- Our security sucks. Why can't we change? What's wrong with us?
- On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?
- crypto component services - is there a market?
- crypto component services - is there a market?
- Public key encrypt-then-sign or sign-then-encrypt?
- Public key encrypt-then-sign or sign-then-encrypt?
- Dr Geer goes to Washington
- Public key encrypt-then-sign or sign-then-encrypt?
- More Tipping Point evidence - POS vendors sued
- survey of RFC S/MIME signature handling
- H6.1: Designing (Security) Without Requirements is like Building a Road Without a Route Map to a Destination You've Never Seen
- survey of RFC S/MIME signature handling
- WSJ: Soft evidence on a crypto-related breach
Flaw in RFID-enabled passports (part 2?)
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Flaw in RFID-enabled passports (part 2?)
Date: Thu, 09 Nov 2006 12:20:31 -0700
To: cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm25.htm#46 Flaw exploited in RFID-enabled passports
Budapest Declaration on Machine Readable Travel Documents (MRTDs)
http://www.fidis.net/home/single-news/article/budapest-declaration-on-machine-readable-travel-documents-mrtds-2/?tx_ttnews%5BbackPid%5D=4&cHash=fe8718735f
from above:
By failing to implement an appropriate security architecture, European
governments have effectively forced citizens to adopt new
international Machine Readable Travel Documents which dramatically
decrease their security and privacy and increases risk of identity
theft. Simply put, the current implementation of the European passport
utilises technologies and standards that are poorly conceived for its
purpose. In this declaration, researchers on Identity and Identity
Management (supported by a unanimous move in the September 2006
Budapest meeting of the FIDIS "Future of Identity in the Information
Society" Network of Excellence) summarise findings from an analysis of
MRTDs and recommend corrective measures which need to be adopted by
stakeholders in governments and industry to ameliorate outstanding
issues.
... snip ...
and
RFID Passport Security 'Poorly Conceived'
http://it.slashdot.org/it/06/11/09/1757202.shtml
the above also references
Feds Leapfrog RFID Privacy Study
http://www.wired.com/news/technology/1,72019-0.html
from above:
The story seems simple enough. An outside privacy and security
advisory committee to the Department of Homeland Security penned a
tough report concluding the government should not use chips that can
be read remotely in identification documents. But the report remains
stuck in draft mode, even as new identification cards with the chips
are being announced.
... snip ...
The Use of RFID for Human Identification; A DRAFT REPORT from DHS
Emerging Applications and Technology Subcommittee
http://www.dhs.gov/xlibrary/assets/privacy/privacy_advcom_rpt_rfid_draft.pdf
Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 12, 2006 05:42 PM
Subject: Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000835.html
there are several other disconnects between ssl domain name
certificates and the infrastructure .... the primary use of ssl
and e-commerce
https://www.garlic.com/~lynn/subpubkey.html#sslcert
1) one of the things that ssl domain name certificates were
countermeasure to ip-address hijacking ... namely that the URL that
the user entered got them to the correct web site ... and the website
they thought they were talking to, was in fact, the website they were
talking to.
the chain of trust then had certification authorities, certifying that
the certified public key actually belonged to the owner of the
specific domain name (that would be used in the url).
the first disconnect came when e-commerce sites figured out that using
SSL consumed 80-90 percent of their capacity and started relegating
SSL to purely check-out/purchase phase. The user now clicks on a
button (from the website) that automatically supplies a URL ... which
is then verified by a certificate (also supplied by the website). This
creates a break in the chain of trust, since the URL originally
provided by the user is no longer being verified.
the next disconnect came with the wide-spread adoption of users purely
clicking on all sorts of buttons and field ... hardly ever actually
manually entering a URL themselves. this has shown up in various kinds
of phishing and spam attacks where users are requested to click on an
email field that purports to represent some URL ... but in fact, may
take the user to a fraudulent website (which can include
man-in-the-middle attacks).
part of the financial disconnect has been that e-commerce has been
extremely skewed. the large sites are extremely well known as are their
URL(s); and they do the majority of the transactions. its is the
millions of merchants that only do a few transactions where there is
the greatest risk (but they can't justify a costly extraneous
expense).
the merchants are also already paying premium to insure consumer
credit card transactions. the issue for SSL domain name certificates
is what additional benefit would they provide to anybody, that would
justify paying a lot more money (other than well publicized campaign
where consumers feel greater comfort when SSL is used, aka the
merchant comfort certificates). To some extent certificate authorities
are competing with credit card interchange fees that is already
covering fraud exposure to consumers (bad things happening).
2) another issue with the ssl domain name certificates, is that the
certification authorities have to resort to verifying the domain name
owner with the authoritative agency for domain name ownership, which
turns out to be the domain name infrastructure ... the agency that
also has various possible integrity issues ... like ip-address
hijacking, which is one of the original justifications for having ssl
domain name certificates.
another integrity issue with domain name infrastructure is domain name
hijacking vulnerabilities. having various vulnerabilities with the
authoritative agencies responsible for the information that
certification authorities are certifying ... can result in the
certification authorities performing one hundred percent and still
certifying erroneous information.
so, somewhat with the backing of the certification authority industry,
there is proposal that all domain name owners register a public key as
part of their domain name registration. this can close some number of
vulnerabilities for domain name infrastructure (like ip-address and
domain name hijacking), improving the integrity of the domain name
infrastructure.
the certification authorities currently have an expensive,
time-consuming and error prone process where they require a SSL domain
name application to provide a lot of identification which they then
have to try and match with the identification information on file (for
the domain name owner) with the domain name infrastructure. going to
onfile public keys, the certification authorities can require that SSL
domain name certificate applications be digitally sign. Then the
certification authority can do a real-time retrieval of the onfile
public key to verify the digital signature (replacing an expensive,
time-consuming and error prone identification process with a much
simpler, less expensive, and reliable authentication process).
the problem is that the onfile public keys represent a catch-22 for the
certification authorities. improving the integrity of the domain name
infrastructure, decreases the original justification for having ssl
domain name certificates. also allowing anybody to do real-time
retrieval of onfile public keys means that general public could
authenticate websites directly without requiring digital certificates
at all.
https://www.garlic.com/~lynn/subpubkey.html#catch22
3) business model that is out of synch with traditional business
processes. normally a relying party has a contract with an
authoritative party where they pay directly for the services they
receive (exchange of value). in the standard 3rd party certification
authority business operation, the certification authority sells a
certificate to an key-owner/end-user (and NOT the relying
party). The relying party then has absolutely no relationship
contractual, implied, or any other way) with the certification
authority and/or any obligations related to the certification
authorities duties.
The Federal PKI project somewhat dealt with this aspect by having the
GSA (acting on behalf of the federal gov. agencies that would be
relying parties) sign a contract with all "authorized" certification
authorities (creating a contractual obligation between the relying
parties and the certification authorities).
in the ssl domain name certificate infrastructure scenario, this would
imply having every possible consumer/client (hundreds of millions or
even billions) sign a contract with every possible certification
authority (at least tens). the business plan of selling ssl domain
name certificates to a few million merchant sites would be totally
swamped by the costs of having to deal with tens of billions of
individual consumer contracts (with the consumer as a relying party).
4) advent of ubiquitous online connectivity. the primary design point
for digital certificates were in offline environments, analogous to
letters of credit/introduction from sailing ship (and earlier) days
... where the relying party lacked any ability to directly access the
responsible or authoritative agency. digital certificates designed for
offline operation can become quickly obsoleted when the relying
parties have direct, real-time access to the responsible authoritative
agencies (like possibly being able to do real-time retrieval of onfile
public keys from the domain name infrastructure OR real-time payment
card authorization).
this has somewhat pushed digital certificates into the low/no value
market segment where relying parties can't justify the expense of
real-time operation for whatever business operation they are involved
in. however, with the rapidly declining costs of data processing and
online access, the places where relying parties can't justify
real-time, online operation is also shrinking/declining. it is quickly
becoming an extremely small no-value operation that can't justify
real-time, online access.
lots of past posts about certification authorities being manuvered
into low/no value market segment (and if you are dealing with no-value
operations, its hard to justify charging a lot)
https://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
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#52 First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
https://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP
https://www.garlic.com/~lynn/aadsm13.htm#5 OCSP and LDAP
https://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)
https://www.garlic.com/~lynn/aadsm16.htm#22 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
https://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
https://www.garlic.com/~lynn/aadsm17.htm#53 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm19.htm#8 GeoTrust says existing PKI practices are worthless
https://www.garlic.com/~lynn/aadsm20.htm#33 How many wrongs do you need to make a right?
https://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on high-assurance certificates
https://www.garlic.com/~lynn/aadsm21.htm#36 browser vendors and CAs agreeing on high-assurance certificates
https://www.garlic.com/~lynn/aadsm23.htm#1 RSA Adaptive Authentication
https://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
https://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
https://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
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/2003b.html#50 Authentication w/o user ids and passwords
https://www.garlic.com/~lynn/2003l.html#33 RSA vs AES
https://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2004b.html#25 Who is the most likely to use PK?
https://www.garlic.com/~lynn/2004b.html#52 The SOB that helped IT jobs move to India is dead!
https://www.garlic.com/~lynn/2004e.html#20 Soft signatures
https://www.garlic.com/~lynn/2004h.html#52 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#2 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
https://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2005e.html#62 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
https://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#13 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#24 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005k.html#29 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#1 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#11 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#21 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#23 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
https://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
https://www.garlic.com/~lynn/2005l.html#33 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005o.html#40 Certificate Authority of a secured P2P network
https://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
https://www.garlic.com/~lynn/2005t.html#0 TTP and KCM
https://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#39 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh
https://www.garlic.com/~lynn/2006h.html#28 confidence in CA
https://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation
Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 13, 2006 11:00 AM
Subject: Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates...
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000819.html
https://www.garlic.com/~lynn/aadsm25.htm#43
a cross over postings mentioning sox
https://www.garlic.com/~lynn/2006u.html#22 AOS: The next big thing in data storage
and other recent items:
Cheney Expresses Doubts About Sarbanes-Oxley
http://www.informationweek.com/showArticle.jhtml?articleID=193500718
Democrat Says Sarbanes-Oxley Already Being Thinned
http://www.baselinemag.com/article2/0,1540,2050437,00.asp
NY leaders see city's financial position threatened
http://money.cnn.com/2006/11/01/markets/bc.financial.newyork.politicians.reut/
Sarbanes-Oxley overkill, bankers say
http://www.newsobserver.com/104/story/504970.html
Lights Dimming On The Sarbanes Oxley Act?
http://www.crn.com/showArticle.jhtml?articleID=193700543
Greenspan calls SarBox a nightmare
http://weblog.infoworld.com/techwatch/archives/008823.html
Citibank e-mail looks phishy
Subject: Re: Citibank e-mail looks phishy
Date: Mon, 13 Nov 2006 12:36:22 -0700
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Perry E. Metzger <perry@xxxxxxxx>
CC: Peter Gutmann <pgut001@xxxxxxxx>,
Carlos.Cid@xxxxxxxx, cryptography@xxxxxxxx
... and the situation can in turn be aggravated by ....
NatWest shuns ID fraud victims
http://business.timesonline.co.uk/article/0,,9558-2449436,00.html
from above ...
Other types of fraud are on the rise, too. New figures from Apacs show
a dramatic rise in the number of 'phishing' incidents, where scammers
send out an e-mail purporting to be from a consumer's bank and asking
them to type in their account details.
... snip ...
Citibank e-mail looks phishy
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: James A. Donald <jamesd@xxxxxxxx>
Subject: Re: Citibank e-mail looks phishy
Date: Wed, 15 Nov 2006 16:15:12 -0700
CC: Leichter, Jerry <leichter_jerrold@xxxxxxxx>,
Perry E. Metzger <perry@xxxxxxxx>, cryptography@xxxxxxxx
James A. Donald wrote
The failures of high finance are more subtle. They push
the boundaries of what people can easily comprehend. Not
one person in a thousand - no regulators, and not many
accountants, understand what went wrong with Enron,
though quite a lot of investors and creditors
understand.
the straight-forward ones are not too bad ... they just require
somebody to understand the infrastructure and to do a detailed
vulnerability analysis. the more complex ones are systemic failures
... which can happen in complex, interconnected infrastructures
.... whether it is financial infrastructure or the power grid ... or
some of the PKI-based scenarios (things that might be considered
relatively minor failures, cascade and pull down the whole
infrastructure).
some of the straight-forward ones can also happen because of
infrastructure and/or paradigm changes ... and there wasn't any
forward thinking.
recent thread today in sci.crypt
https://www.garlic.com/~lynn/2006u.html#40 New attack on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#43 New attack on the financial PIN processing
there is reference to chip&pin and the YES CARD exploit
https://www.garlic.com/~lynn/subintegrity.html#yescard
as referenced, the x9a10 financial standard group was formed to work
on x9.59 standard (and given the requirement to preserve the integrity
of the financial infrastructure for all retail payments) in the same
time frame that work started on chip&pin. chip&pin appeared to come
out with a solution that addressed lost/stolen (magstripe)
card. however, in the decade preceding that work, there was a big
increase in skimming/harvesting static authentication data for the
production of counterfeit cards.
there was already a partial countermeasure for lost/stolen card
... that was notifying the issuer and getting the account
flagged. however, skimming, harvesting, and/or data breaches involving
static authentication information was a much more difficult problem
... since it typically wasn't evident to the card owner that it has
happened (and most indications would only be there when the fraudulent
transactions started showing up)
so not too long after chip&pin deployments in the 90s, YES CARD
exploits started appearing. some have even claimed that chip&pin
actually made the situation worse vis-a-vis magstripe card ... because
a chip was allowed to tell a terminal to do offline transactions
(which a counterfeit YES CARD would always do) ... which negated the
countermeasure of flagging the account (since a real time transaction
wasn't being done, by the time a terminal found out that an account
was flagged, it was way too late).
ATMs hacked using MP3 player
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: ATMs hacked using MP3 player
Date: Wed, 15 Nov 2006 16:51:40 -0700
To: cryptography@xxxxxxxx
and one more skimming attack
ATMs hacked using MP3 player
http://news.com.com/2061-10789_3-6135905.html
from above:
The gang targeted freestanding cash dispensers and would tap the phone
line between the ATM and a wall socket by placing a two-way adaptor on
it and connecting an MP3 player, according to the newspaper.
... snip ...
just another in long history of skimming/harvesting of static
authentication information
somewhat related:
https://www.garlic.com/~lynn/aadsm26.htm#4 Citibank e-mail looks phishy
and as referred to here
https://www.garlic.com/~lynn/2006u.html#42 New attacks on the financial PIN processing
x9.59 protocol
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
attempted to address the whole problem of attackers acquiring
(sensitive) static authentication information ... regardless of
method, harvesting, skimming, data breaches, phishing, whatever
... effectively for use in any form of replay attack.
the design of the x9.59 protocol also attempted to address numerous
possible man-in-the-middle attacks ... which still might occur even
when switching from static authentication data to dynamic
authentication data i.e. the authentication has to be part of the
transaction itself ... as opposed to any separate operation (which
could possibly open up cracks for man-in-the-middle attacks).
https://www.garlic.com/~lynn/subintegrity.html#mitm
Citibank e-mail looks phishy
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Citibank e-mail looks phishy
Date: Thu, 16 Nov 2006 07:45:08 -0700
To: cryptography@xxxxxxxx
CC: James A. Donald <jamesd@xxxxxxxx>,
Leichter, Jerry <leichter_jerrold@xxxxxxxx>,
Perry E. Metzger <perry@xxxxxxxx>,
Anne & Lynn Wheeler wrote
some of the straight-forward ones can also happen because of
infrastructure and/or paradigm changes ... and there wasn't any forward
thinking.
recent thread today in sci.crypt
https://www.garlic.com/~lynn/2006u.html#40 New attack on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#43 New attack on the financial PIN processing
past posts in this thread
https://www.garlic.com/~lynn/aadsm26.htm#3 Citibank e-mail looks phishy
https://www.garlic.com/~lynn/aadsm26.htm#4 Citibank e-mail looks phishy
https://www.garlic.com/~lynn/aadsm26.htm#5 ATMs harcked using MP3 player
couple more in sci.crypt thread:
https://www.garlic.com/~lynn/2006u.html#47 New attack on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#48 New attack on the financial PIN processing
elsewhere in the "PIN processing" thread somebody mentions that ATM
standards require encryption for the PIN but not the rest of the
message. This could be considered sufficient prior to the introduction
of signature-debit ... since up until that time, all debit transactions
required the associated PIN.
However, the introduction of signature-debit makes the rest of the
(unencrypted) message attractive targets, since attackers can skim the
information and create counterfeit cards and use them in (PINless)
signature-debit transactions.
or can you say security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
or using the "naked payments" metaphor, consistent requirement for a
debit transaction to have a PIN ... and the PIN was given at least
some level of protection ... would imply that the payment transaction
had some degree of armoring ... which eliminated the rest of the
transaction as useful to the attacker (and therefor didn't need
encryption since it wasn't sufficient to perform fraudulent
transactions). With the introduction of signature-debit, it removes
the transaction armoring and creates a vulnerability for the rest of
the transaction information (the armoring of the transaction
information was removed, leaving it naked and exposed, making the
information vulnerable to skimming, harvesting, data breach, etc
attacks).
as mentioned numerous times in the past, the x9a10 financial
standard working group was given the requirement to preserve the
integrity of the financial infrastructure for all retail payments
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
part of the standard was to specify an environment were the
transactions were always consistently armored and never left naked
and vulnerable. misc. past posts mentioning the naked
payment/transaction metaphor
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
https://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
https://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
https://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
https://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
https://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt
https://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication
Citibank e-mail looks phishy
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Citibank e-mail looks phishy
Date: Thu, 23 Nov 2006 09:23:51 -0700
To: cryptography@xxxxxxxx
and now for some different threat vector:
Banks face growing threat of identity theft from insiders
http://news.com.com/Banks+face+growing+threat+of+identity+theft+from+insiders/2100-1029_3-6137940.html
from above:
Banks are pouring money into building formidable defenses against
computer hackers, but are only just waking up to what may be a bigger
threat--the physical theft of client information by people in the
office.
.... snip ...
it isn't exactly new news ... insiders have always been considered the
major threat ... whether it is physical theft or various kinds of
electronic data breaches and/or security breaches.
misc. past items ...
Study: ID theft usually an inside job
https://www.garlic.com/~lynn/aadsm17.htm#38
Leading Cause of Data Security breaches Are Due to Insiders
https://www.garlic.com/~lynn/aadsm18.htm#49
Bank workers biggest ID theft threat
https://www.garlic.com/~lynn/2005l.html#35
other insider threat
https://www.garlic.com/~lynn/2006p.html#9
i've frequently commented in the past that the stuff about external
threats that make the popular press has frequently obfuscated the
source of the major threats (for all i know, insider attacks may even
take advantage of the added confusion and ambiguity introduced by the
prospect of internet-based attacks).
What is the point of encrypting information that is publicly visible?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 24, 2006 05:36 PM
Subject: What is the point of encrypting information that is publicly visible?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000839.html
PAIN security acronym:
P ... privacy (sometimes CAIN & confidentiality)
A ... authentication
I ... integrity
N ... non-repudiation
original (and possibly still one of the major) use for SSL was hiding
account numbers as part of e-commerce ... long winded archeological
reference
https://www.garlic.com/~lynn/2006u.html#56
a large part of the issue with account numbers is diametrically
opposing requirements.
frequently, just knowledge of account numbers can effectively be used
in various kinds of replay attacks for fraudulent transactions
... resulting in the requirement for account numbers to be kept
confidential and never divulged.
at the same time, account numbers are required in scores of business
processes, and as such, are required to be readily available. my oft
repeated comment is that as a result of the diametrically opposing
requirements, the planet could be buried under miles of encryption and
still be unable to prevent account number leakage.
somewhat related thread
https://www.garlic.com/~lynn/aadsm26.htm#6
https://www.garlic.com/~lynn/2006v.html#1
https://www.garlic.com/~lynn/2006v.html#2
as mentioned in the above, the x9.59 financial standard changed the
paradigm ... eliminating the requirement for keeping account number
confidential ... effectively by using (consistently applying
end-to-end) authentication and integrity for security ... as part of
"armoring" all transactions (instead of privacy/confidentiality to
achieve security, authentication and integrity was used for security).
of course, part of this was studying what the threats were and why
... and creating countermeasures for the actual threats.
Who has a Core Competency in Security?
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 25, 2006 11:41 AM
Subject: Who has a Core Competency in Security?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000840.html
byte my tongue? ... well it has been 10plus years
IBM was/is a very large company with a very broad range of people.
for instance this archeological reference
https://www.garlic.com/~lynn/2006u.html#56
in this post
https://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible
or this archeological reference
https://www.garlic.com/~lynn/2006v.html#10
in various discussions from the mid-90s ... pointing out significant
issues ... the eventual response (by numerous parties) was that they
were taking the lead from visa and mastercard. For instance, the
people that i dealt with on des and public key in the mid-80s weren't
participating in this particular activity in the mid-90s ... another
archeological reference from the mid-80s
https://www.garlic.com/~lynn/2006u.html#45
and then a few items referencing what went on in the mid-90s
https://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#7 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm20.htm#9 the limits of crypto and authentication
and then old public key archeological reference from mid-80s
https://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications a
nd even this older public key archeological reference form 1981
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
Who has a Core Competency in Security?
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 25, 2006 02:48 PM
Subject: Who has a Core Competency in Security?
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visiable?
https://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
misc. (other archeological) posts to/referencing set-discuss forum
https://www.garlic.com/~lynn/aadsm2.htm#storage Storage of Certificates
https://www.garlic.com/~lynn/aadsmore.htm#setjava javasoft SET - NO!
https://www.garlic.com/~lynn/aepay3.htm#disputes Half of Visa's disputes, fraud result from I-commerce (more)
https://www.garlic.com/~lynn/aepay4.htm#comcert3 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#3dssl VISA 3D-SSL
https://www.garlic.com/~lynn/aepay6.htm#ecomich call for new measures: ICH would be glad to help
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#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aepay10.htm#26 Definese Dept Criticised on Internal Credit Card Fraud
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm20.htm#12 the limits of crypto and authentication
and even more archeological background
for much of the 80s, i reported to yorktown (but lived in san
jose). yorktown was where the person responsible for des worked and
one of the two people responsible for ecc worked.
i had office in bldg. 28 (san jose research on the main plant site)
... until they built the new building up the hill and then i had
office in almaden research. I also had a block of offices and labs out
in bldg. 29, the los gatos vlsi lab.
i still made the east coast trip a couple times a month (leaving on
the monday night red-eye out of sfo for kennedy and returning on
friday). when i started the habit, i would take twa#44 monday night,
and return friday on the last leg of the twa tel aviv, rome, kennedy,
sfo flight. twa went bankrupt and i switched to panam. then panam sold
its pacific routes to united (to concentrate on atlantic routes), and
i switched to american.
What is the point of encrypting information that is publicly visible?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 25, 2006 03:53 PM
Subject: What is the point of encrypting information that is publicly visible?
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
somewhat related news item, hot off the presses
Michigan Credit Card Mystery Deepens
http://www.consumeraffairs.com/news04/2006/11/mi_card_fraud.html
from above:
Numerous incidents involving breaches of bank security also
demonstrate that there are major vulnerabilities at every level of a
plastic transaction, from withdrawing money to buying goods online.
... snip ...
and/or can you say security proportional to risk?
https://www.garlic.com/~lynn/2001h.html#61
and then there are a couple recent posts about insider threats
https://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/aadsm26.htm#7 Citibank e-mail looks phishy
related posts:
Citibank's Cards Mysteriously Shut Down
http://www.consumeraffairs.com/news04/2006/03/citibank_cards.html
The 'Worst Hack Ever:' Debit Card Security Crisis Continues
http://www.consumeraffairs.com/news04/2006/03/worst_hack.html
Visa Admits To Problem In Mysterious Data Breach
http://www.consumeraffairs.com/news04/2006/06/visa_data_breach.html
ATM, Bank Card Security Getting Worse
http://www.consumeraffairs.com/news04/2006/11/atm_security.html
Who has a Core Competency in Security?
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 27, 2006 10:04 AM
Subject: Who has a Core Competency in Security?
Blog: Financial Cryptography
and now for something completely different
Defeating Virtual Keyboards and Phishing Banks
http://it.slashdot.org/it/06/11/27/0546230.shtml
Defeating Image-Based Virtual Keyboards and Phishing Banks
http://blogs.securiteam.com/index.php/archives/678
Who has a Core Competency in Security?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 28, 2006 07:00 PM
Subject: Who has a Core Competency in Security?
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
https://www.garlic.com/~lynn/aadsm26.htm#10 Who has a Core Competency in Security?
https://www.garlic.com/~lynn/aadsm26.htm#12 Who has a Core Competency in Security?
Fighting Fraudulent Transactions (from yesterday's blog)
http://www.schneier.com/blog/archives/2006/11/fighting_fraudu.html
... from above ....
The solution is not to better authenticate the person, but to
authenticate the transaction. (Think credit cards. No one checks your
signature. They really don't care if you're you. They maintain
security by authenticating the transactions.)
... snip ...
authenticate the transaction sounds quite a bit like x9.59 financial
industry standard from the work by the x9a10 financial standard
working group started in the mid-90s
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
and some of the posts in this blog on YES CARD exploits
https://www.garlic.com/~lynn/subintegrity.html#yescard
or the naked payments (and related) threads
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#21 Use of TPM chip for RNG?
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#37 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
https://www.garlic.com/~lynn/aadsm24.htm#43 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
https://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#9 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
https://www.garlic.com/~lynn/aadsm25.htm#25 RSA SecurID SID800 Token vulnerable by design
https://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
https://www.garlic.com/~lynn/aadsm25.htm#38 How the Classical Scholars dropped security from the canon of Computer Science
https://www.garlic.com/~lynn/aadsm26.htm#6 Citibank e-mail looks phishy
Who has a Core Competency in Security?
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 30, 2006 11:21 AM
Subject: Who has a Core Competency in Security?
Blog: Financial Cryptography
several related items from hackinthtebox.org ... somewhat related to
my old post on the thread between information security and risk
management
https://www.garlic.com/~lynn/aepay3.htm#riskm
https://www.garlic.com/~lynn/aepay3.htm#riskaads
......
Information Security Fundamentally Broken
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=21854&mode=thread&order=0&thold=0
Information Security Fundamentally Broken
http://www.webpronews.com/expertarticles/expertarticles/wpn-62-20061130InformationSecurityFundamentallyBroken.html
Community Comments & Feedback to Security Absurdity Article
http://www.securityabsurdity.com/comments.php
IT industry looks to human behaviour experts to improve security
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=21852
IT industry looks to human behaviour experts to improve security
http://www.innovations-report.de/html/berichte/informationstechnologie/bericht-75125.html
Hackers take aim at financial institutions
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=21851
Hackers take aim at financial institutions
http://www.vnunet.com/vnunet/news/2169953/hackers-aim-financial
Who has a Core Competency in Security?
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: December 10, 2006 10:50 AM
Subject: Who has a Core Competency in Security?
Blog: Financial Cryptography
and a recent thread with a few more archeological references
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network
Security Implications of Using the Data Encryption Standard (DES)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Security Implications of Using the Data Encryption Standard (DES)
Date: Sat, 23 Dec 2006 13:37:30 -0700
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
from rfc-editor announcement today
4772 I
Security Implications of Using the Data Encryption Standard (DES),
Kelly S., 2006/12/22 (28pp) (.txt=68524) (was
draft-kelly-saag-des-implications-06.txt)
...
The Data Encryption Standard (DES) is susceptible to brute-force
attacks, which are well within the reach of a modestly financed
adversary. As a result, DES has been deprecated, and replaced by the
Advanced Encryption Standard (AES). Nonetheless, many applications
continue to rely on DES for security, and designers and implementers
continue to support it in new applications. While this is not always
inappropriate, it frequently is. This note discusses DES security
implications in detail, so that designers and implementers have all
the information they need to make judicious decisions regarding its
use.
... snip ...
rfc 4772 summary
https://www.garlic.com/~lynn/rfcidx15.htm#4772
from
https://www.garlic.com/~lynn/rfcietff.htm
and in the rfc summery, clicking on the ".txt=" field retrieves the actual RFC.
note that there have been (at least) two countermeasures to DES brute-force attacks ... one is 3DES ... and the other ... mandated for some ATM networks, has been DUKPT. while DUKPT doesn't change the difficulty of brute-force attack on single key ... it creates a derived unique key per transaction and bounds the life-time use of that key to relatively small window (typically significantly less than what even existing brute-force attacks would take). The attractiveness of doing such a brute-force attack is further limited because the typical transaction value is much less than the cost of typical brute-force attack.
... and a little extra in the same announcement:
4732 I
Internet Denial-of-Service Considerations, Handley M., IAB, Rescorla
E., 2006/12/22 (38pp) (.txt=91844) (Refs 1058, 1075, 1112, 2349, 2385,
2439, 2827, 2918, 3261, 3411, 3550, 3618, 3682, 3768, 4251, 4271,
4346, 4566, 4601) (was draft-iab-dos-05.txt)
....
This document provides an overview of possible avenues for
denial-of-service (DoS) attack on Internet systems. The aim is to
encourage protocol designers and network engineers towards designs
that are more robust. We discuss partial solutions that reduce the
effectiveness of attacks, and how some solutions might inadvertently
open up alternative vulnerabilities.
... snip ...
rfc 4732 summary
https://www.garlic.com/~lynn/rfcidx15.htm#4732
Changing the Mantra -- RFC 4732 on rethinking DOS
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: December 26, 2006 02:49 PM
Subject: Changing the Mantra -- RFC 4732 on rethinking DOS
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000844.html
original post mentioned two RFCs, the other was
https://www.garlic.com/~lynn/aadsm26.htm#16 Security Implications of Using the Data Encryption Standard (DES)
we had done detailed vulnerability study when we were doing our high
availability product (ha/cmp) ... including tcp/ip (both RFCs and
code)
https://www.garlic.com/~lynn/subtopic.html#hacmp
i.e. availability might be considered part of integrity and from the
security acronym PAIN
P - privacy (or sometimes CAIN and confidentiality)
A - authentication
I - integrity
N - non-repudiation
later when we had been called in to consult on payments transactions
... for something that has since come to be called e-commerce
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
there was also an incident where the largest online service provider
was starting to have internet server crash ... storage exhaustion with
a lot of half-open sessions. this started the middle of june and
continued thru the middle of august (during that period they had wide
variety of different people to come in and look at the problem).
Finally one of the people flew out to the west coast and bought me a
hamburger after work. He described the problem while I ate the
hamburger. Then i gave him a quick&dirty fix which he applied later
that night.
Almost exactly a year later ... there was a whole lot of press with
similar kind of system failures at an ISP in manhatten (i.e. I talked
to most of the major product providers the previous year about
addressing the problem ... but none were interested until the problem
got a whole lot of press).
misc. past references to the incident:
https://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
https://www.garlic.com/~lynn/99.html#48 Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
https://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2006e.html#11 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006i.html#6 The Pankian Metaphor
for some topic drift ... recent post having to do with ha/cmp scale-up
and distributed lock manager (DLM) being able to meet database ACID
properties
https://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?
and other references mentioning distributed operation
https://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006y.html#6 The Future of CPUs: What's After Multi-Core?
SSL (https, really) accelerators for Linux/Apache?
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: SSL (https, really) accelerators for Linux/Apache?
Date: Thu, 04 Jan 2007 13:13:51 -0700
To: cryptography@xxxxxxxx
for lots of topic drift about fast transactions and lightweight SSL
(somewhat related to past assertions that majority of SSL use has been
e-commerce related)... recent post in thread on secure financial
transactions
https://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
having some discussion about this news URL from today:
Faster payments should not result in weaker authentication
http://www.securitypark.co.uk/article.asp?articleid=26294&CategoryID=1
... other posts in the same thread:
https://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
so having done a lot of optimization on the original payment gateway
and some other SSL uses ... some of it mentioned in this thread (to
help minimize payment transaction elapsed time):
https://www.garlic.com/~lynn/2007.html#7 SSL info
https://www.garlic.com/~lynn/2007.html#15 SSL info
https://www.garlic.com/~lynn/2007.html#17 SSL info
now, in the above thread, I've discussed the possible catch-22 for
the SSL domain name certification industry
https://www.garlic.com/~lynn/subpubkey.html#catch22
however, in the past, I've also discussed leveraging the catch-22
to implement a really lightweight SSL ... somewhat similar proposal
mentioned here in old email from 1981
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
and a couple past posts discussing really lightweight SSL in the
context of the catch-22 scenario:
https://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh
So after the initial e-commerce activity ... there were some number of
efforts in the mid-90s to improve the internet payment technologies
... two such activities were SET and X9A10. The financial standards
X9A10 working group had been given the requirement to preserve the
integrity of the financial infrastructure for all retail payments (not
just internet) ... resulting X9.59
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
I had gotten ahold of the SET specification when it was first
available and did a crypto-op profile and calculated some crypto-op
performance for typical SET transactions. Some number of people
associated with SET claimed that my numbers were off by two orders of
magnitude (too large by a factor of one hundred times) ... however
when they eventually had running code ... my profile numbers were
within a couple percent of the measured numbers. On an otherwise idle
dedicated test infrastructure, a simple SET transaction was over 30
seconds elapsed time ... nearly all of that crypto-op processing. In
a loaded infrastructure, contention and queueing delays could stretch
that out to several minutes (or longer). Besides the enormous
processing bloat ... there was also a lot of protocol chatter and
enormous payload bloat. misc. posts:
https://www.garlic.com/~lynn/subpubkey.html#bloat
by comparison, X9.59 had to be a lightweight payload, lightweight
processing, and fast transaction that was applicable to all
environments (not just the internet).
x9.59 went for lightweight payload transaction that could complete in
a single transaction roundtrip, with strong end-to-end security
(applicable whether the transaction was "in-transit" or "at-rest").
It effectively substituted end-to-end strong authentication and strong
integrity for information hiding encryption. X9.59 also eliminated
knowledge of the account number as a fraud exploit
https://www.garlic.com/~lynn/subintegrity.html#harvest
and therefor eliminated the need for the most common use of SSL for
hiding account numbers in e-commerce transactions (i.e. for really
high performance and lightweight SSL is when you don't have to do it
at all).
Non-repudiation, Evidence and TLS: another fine mess I've got you into :-(
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 5, 2007 10:42 AM
Subject: Non-repudiation, Evidence and TLS: another fine mess I've got you into :-(
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000848.html
old post where i pulled some sc27 definitions and added them
to my merged security taxonomy and glossary
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation
- non-repudiation
- non-repudiation exchange
- non-repudiation information
- non-repudiation of creation
- non-repudiation of delivery
- non-repudiation of knowledge
- non-repudiation of origin
- non-repudiation of receipt
- non-repudiation of sending
- non-repudiation of submission
- non-repudiation of transport
non-repudiation shares same issues surrounding "human signature"
... where a "human" signature is indication that somebody is
demonstrating intent and has read, understood, agrees, approves,
and/or authorizes something ... requiring some sort of indication that
holds for each specific operation. "digital signature" carries NONE of
those characteristics (other than the terms happen to share the word
"signature"). lots of past posts discussing "human signature" (and
having been brought in to help word-smith the california and federal
electronic signature legislation)
https://www.garlic.com/~lynn/subpubkey.html#signature
non-repudiation requires something similar ... and as such,
many of the definitions have morphed into involving a service that
provides some indication as to some specific occurance ... rather than
trying to demonstrate non-repudiation of intent,
demonstrate non-repudiation (actually proof) of some
specific event or activity having occured.
a couple of (lengthy) past threads discussing "meaning" of non-repudiation:
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#nonrep2 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/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation
Tamperproof, yet playing Tetris
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Tamperproof, yet playing Tetris.
Date: Sat, 06 Jan 2007 13:43:33 -0700
To: cryptography@xxxxxxxx
Perry E. Metzger wrote
Handheld "Chip & Pin" terminals for reading credit cards in the UK are
required to be tamperproof to avoid the possibility of people
suborning them. Here is a report from a group that has not merely
tampered with such a terminal, but has (as a demo) converted it into a
tetris game to demonstrate that they can make it do whatever they
like.
http://www.lightbluetouchpaper.org/2006/12/24/chip-pin-terminal-playing-tetris/
a couple mentions of the same
Game over for Chip and PIN?
http://www.finextra.com/fullstory.asp?id=16332
Hacked Chip and PIN terminal plays Tetris
http://www.astalavista.com/?section=news&cmd=details&newsid=3160
Chip and Pin fraud alert
http://www.thisismoney.co.uk/saving-and-banking/article.html?in_article_id=416139&in_page_id=7&ct=5
misc. past posts on related vulnerabilities and exploits
https://www.garlic.com/~lynn/subintegrity.html#yescard
as an aside ... some of the "overlay" type of exploits that make the
news about automatic teller machines have also been used with
point-of-sale terminals ... somewhat a man-in-the-middle attack
... even if it is only being used for skimming information (as in most
of the automatic teller machine scenarios) .... aka how does the
consumer know they are dealing with the real-terminal ... or an
MITM/middle-man terminal? various past posts mentioning MITM-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitmattack
the EU finread standard attempted to address some of the same issues
... providing tamper resistant personal-use terminals (addressing some
of the same tamper resistant characteristics as point-of-sale
terminals)
https://www.garlic.com/~lynn/subintegrity.html#finread
two of the issues
- is the transaction you "see", the same as the transaction you "approve"
- independent pin-entry ... as countermeasure to the numerous
PC-based keylogging vulnerabilities
there is somewhat reduced concern that a terminal (that you always
have physical possession of) ... being subverted with some sort of
overlay technology (i.e. there isn't an actual attack the
tamper-resistant characteristics of the operating point-of-sale
terminal ... but there is a MITM overlay). Cellphone and PDAs use at
POS have also been suggested as countermeasure to the variety of
point-of-sale terminal exploits.
In X9A10 financial standards working group .... recent mention in this
post
https://www.garlic.com/~lynn/aadsm26.htm#18 SSL (https, really) accelerators for Linux/Apache?
one of the things looked at for X9.59 standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
was how can the relying/authorizing party really know the integrity
characteristics of the transaction environment. so x9.59 allowed for
the transaction environment (point-of-sale terminal, finread terminal,
etc) to also digitally (co-)sign the transaction. the authorizing
party can look-up the integrity characteristics of the terminal used
in the transaction environment (and also have some assurance that
terminal was actually used for the transaction based on verifying its
digital signature with onfile public key).
FC07 Preliminary Programme - Leaving Room for the Bad Guys
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 8, 2007 09:59 AM
Subject: FC07 Preliminary Programme - Leaving Room for the Bad Guys
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000850.html
i would contend that a lot of vulnerabiilties raised by YES CARD
exploit ... misc. past posts
https://www.garlic.com/~lynn/subintegrity.html#yescard
was looking at a very narrow set of threats ... specifically
lost/stolen card threats ... and concentrating on countermeasures for
attacks on the cards. the YES CARD exploits effectively turn out to
be attacks on the terminals, not attacks on the cards.
the basis for the YES in the YES CARD reference comes somewhat
from the standpoint that once it was assumed that the card had been
secured, then a system could be deployed where the terminal could rely
on business rules implemented in the card.
the issue was that skimming type of attacks (typically a terminal
attack) ... recent reference
https://www.garlic.com/~lynn/aadsm26.htm#20
predated work on infrastructure that gave rise to YES CARDs. a
(terminal) skimming attack then could be used to produce a counterfeit
YES CARD ... and letting the terminal rely on "judgement" of the
card for offline transactions severely aggravated the risk exposure
(somewhat blindly assuming that there wouldn't be countefeit
cards). It wasn't even necessary to skim the PIN ... since the
terminal would ask the (potentially counterfeit) card, if the
entered PIN was correct, and of course, a counterfeit YES CARD would
always answer YES.
So, another maxim would be to include the full end-to-end analysis of
all the components when designing high integrity infrastructure..
However, the guideline that there is always possibility that something
has been overlooked (the bad guys are so ingenious), either
purposefully or not ... would promote design of security in-depth with
multiple layers/levels of countermeasures (even when you may have
otherwised believed all bases have been covered).
Tamperproof, yet playing Tetris
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Tamperproof, yet playing Tetris.
Date: Mon, 08 Jan 2007 11:41:36 -0700
To: cryptography@xxxxxxxx
... and has now made slashdot ....
Chip & PIN Terminal Playing Tetris
http://hardware.slashdot.org/hardware/07/01/08/1355221.shtml
previous post
https://www.garlic.com/~lynn/aadsm26.htm#20 Tamperproof, yet playing Tetris
recent related comments
https://www.garlic.com/~lynn/aadsm26.htm#21 FC07 Preliminary Programme - Leaving Room for the Bad Guys
and a whole lot of past comments
https://www.garlic.com/~lynn/subintegrity.html#yescard
It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Date: Wed, 17 Jan 2007 19:07:01 -0700
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: cryptography@xxxxxxxx
Steven M. Bellovin wrote:
Not necessarily -- many of my systems have multiple disk drives and
file systems, some of which are on removable media. Apart from that,
though, this is reinforcing my point -- what is the threat model?
PC/RT had external scsi disk drive housing ... with scsi disk drive
"bricks" that could be removed from the housing and locked in safes
(when the owner wasn't physical present). This was later part of the
'80s ... twenty some years ago.
nearly 35 yrs ago ... there was this enormous corporate project and
all the information on the project was kept strictly confidential. a
whole bunch of security features were added to prevent leakage of any
of the information. they even went so far as to claim that even I
couldn't access the information ... even if I was physical present in
the room. It was one of the few times that I actually took the bait
... I claimed it would only take me a few minutes ... I found the
location in memory of the authentication routine and patched one byte
so all returns from the routine indicated valid authentication (most
of the time was spent disabling all access to the machine from outside
the room since i didn't want a real compromise).
This is similar ... but different to more recent YES CARD
vulnerability ... where the card is asked if the correct PIN has been
entered ... and a YES CARD always responds YES. Would appear to
work not only for skimming scenario and counterfeit card .... but also
as a MITM-attack with valid card. misc. past posts mentioning yes
card
https://www.garlic.com/~lynn/subintegrity.html#yescard
In any case, my claim way back then (nearly 35yrs ago) was that the
only countermeasure to such physical access was encrypting the
data. Later, I even did prototype filesystem as example ... but at the
time ... the processor load was excessive (would typically only be
justified for small subset of extremely sensitive information).
The project back then was called Future System
https://www.garlic.com/~lynn/submain.html#futuresys
and was canceled w/o ever being announced. However there were some
comments that the amount spent on the failed future system project
would have bankrupted any other computer company.
misc. past posts admitted to haven once risen to the bait in my brash youth.
https://www.garlic.com/~lynn/96.html#24 old manuals
https://www.garlic.com/~lynn/2004g.html#45 command line switches
https://www.garlic.com/~lynn/2006.html#11 Some credible documented evidence that a MVS or later op sys has ever been hacked
The scenario was that if I had physical access ... there were a whole
variety of compromises that wouldn't have been possible otherwise
.... at least for these class of systems ... small footnote about some
deployments ... which i didn't find out until sometime later
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml
Note that when it started becoming common for people taking portable
terminals and later PCs on the road ... for off-site access (reading
email, etc) in the very early 80s ... there was vulnerability study
done ... and one conclusion was that one of the most weakest points is
a hotel PBX closet ... which resulted in design, build and deployment
of custom encrypting 2400baud modems for all off-site dial-in access.
I'm periodically quite dismayed by the cavalier way that many
corporations have treated off-site access over the past 20 years. For
other comparison, the corporate network, which was larger than
arpanet/internet from just about the beginning until possibly sometime
mid-85.
https://www.garlic.com/~lynn/subnetwork.html#internalnet
required link encryptors on all lines that left a corporate facility
... and sometime in the mid-80s there were comments that the internal
corporate network had over half of all the link encryptors in the
world (these are things like leased lines ... separate from the
encrypting dial-up modems).
News.com: IBM donates new privacy tool to open-source Higgins
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: News.com: IBM donates new privacy tool to open-source Higgins
Date: Tue, 30 Jan 2007 10:14:47 -0700
To: John Gilmore <gnu@xxxxxxxx>
CC: cryptography@xxxxxxxx
John Gilmore wrote:
http://news.com.com/IBM+donates+new+privacy+tool+to+open-source/2100-1029_3-6153625.html
IBM donates new privacy tool to open-source
By Joris Evers
Staff Writer, CNET News.com
Published: January 25, 2007, 9:00 PM PST
... and
For example, when making a purchase online, buyers would provide an
encrypted credential issued by their credit card company instead of
actual credit card details. The online store can't access the
credential, but passes it on to the credit card issuer, which can
verify it and make sure the retailer gets paid.
"This limits the liability that the storefront has, because they don't
have that credit card information anymore," Nadalin said. "All you hear
about is stores getting hacked."
Similarly, an agency such as the Department of Motor Vehicles could
issue an encrypted credential that could be used for age checks, for
example. A company looking for such a check won't have to know an
individual's date of birth or other driver's license details; the DMV
can simply electronically confirm that a person is of age, according to
IBM.
...
this was somewhat the issue with x.509 identity certificates from the
early 90s, they were being overloaded with personal information
... and then the proposal that everybody should then "spray" such
digital certificates frequently all over the world. in this period,
they were also being touted for use in electronic driver's licenses,
passports, etc.
In the mid-90s, with the realization of the enormous privacy exposures
of such a paradigm ... there was some parties retrenching to
relying-party-only certificates ... basically a record pointer
... which was then used as reference to the record with the necessary
information ... and only the absolutely necessary information was then
divulged.
https://www.garlic.com/~lynn/subpubkey.html#rpo
however, it was trivially possible to demonstrated that the actual
digital certificate was redundant and superfluous ... all that was
necessary was the record pointer, a digital signature ... and the
responsible agency could verify the digital signature with public key
on file ... at the same time they processed the request using the
record pointer.
This was basically the FSTC organizations
http://www.fstc.org/
model for "FAST" (financial authenticated secure transaction). The
transaction is mapped into existing ISO 8583 message and uses the
existing infrastructure operations. Rather then divulging age, a FAST
(/8583) transaction ... digital signed by the individual ... could ask
whether the person meets some age criteria, address criteria, etc
... getting YES/NO response ... w/o divulging any additional
information (like actual date of birth). This was modeled after
existing (ISO 8583, debit, credit, etc) financial transaction which
effectively asks whether the merchant gets paid or not (simply YES/NO
response).
This is also, effectively the X9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
The X9A10 financial standard working group, in the mid-90s was given
the requirement to preserve the integrity of the financial
infrastructure for all retail payments. The transaction is sent with
digital signature, the responsible agency validates the digital
signature, examines the transaction request and then responds YES/NO
regarding whether the merchant gets paid or not.
The other characteristic of X9.59 was that it included a business rule
that "X9.59" account numbers couldn't be used in non-X9.59
transaction. That made the associated account numbers (record
pointers) unusable w/o the accompanying digital signature i.e. random
people couldn't generate random (valid) transactions against the
account number/record number. This had the effect of eliminating a
lot of the existing skimming/harvesting exploits (it didn't do anything
about the skimming/harvesting ... but it made the information unusable
for exploists)
https://www.garlic.com/~lynn/subintegrity.html#harvest
It isn't necessary to have an encrypted credential ... since if it was
purely "static data" ... and simply presenting such static data
exposes the infrastructure to various kinds of replay attack. In that
sense, the static data can be any recognizable information specific to
the responsible agency handling the transaction. The "static data" is
used by the responsible party to lookup the actual information
(including, if necessary the public key) ... and the digital signature
on every transaction prevents various kinds of replay attacks ... that
might be possible in an infrastructure relying on only static data. If
the agency is going to lookup something (rather than have it carried
around in large encrypted packet ...) then it becomes immaterial
whether the actual (static data) record locator is encrypted or not.
for a little drift ... a different kind of static data exploit here
https://www.garlic.com/~lynn/subintegrity.html#yescard
somewhat related posts in this thread:
https://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#46 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007
with reference to recent news items somewhat touching on the same subject:
Latest Breach May Force a New Approach to Data Security
http://www.digitaltransactions.net/newsstory.cfm?newsid=1226
Analyst: Banks Must Make Credit Card Accounts Useless to Data Theives
http://www.informationweek.com/showArticle.jhtml;jsessionid=E34WIOTVAIIHKQSNDLPCKHSCJUNN2JVN?articleID=197000263
this is somewhat related to my periodic references that existing
infrastructure could bury the planet under miles of (information
hiding) encryption and still not prevent account number linkage
... somewhat related old post about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
misc. past posts with reference to FSTC's FAST
https://www.garlic.com/~lynn/99.html#171 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#216 Ask about Certification-less Public Key
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/ansiepay.htm#privacy more on privacy
https://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
https://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
https://www.garlic.com/~lynn/aadsm16.htm#5 DOD prepares for credentialing pilot
https://www.garlic.com/~lynn/aadsm17.htm#19 PKI International Consortium
https://www.garlic.com/~lynn/2005i.html#33 Improving Authentication on the Internet
https://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#42 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh
EV - what was the reason, again?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 2, 2007 09:33 AM
Subject: EV - what was the reason, again?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000863.html
a lot of work the past couple years has gone into countermeasures to
phishing ... original SSL was suppose to provide for both 1) is the
website you think you are talking to, really the website you are
talking to and 2) hide information that would be transmitted over the
internet.
some what related recent comment here on Extended Validation
certificates
https://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007
however, recent news items:
Phishing overtakes viruses and Trojans
http://www.astalavista.com/?section=news&cmd=details&newsid=3321
Phishing overtakes viruses and Trojans
http://news.com.com/2100-7349_3-6154716.html?part=rss&tag=2547-1_3-0-20&subj=news
Phishing overtakes viruses and Trojans
http://news.com.com/Phishing+overtakes+viruses+and+Trojans/2100-7349_3-6154716.html?tag=nefd.top
a recent comment here
https://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"
and misc. past posts mentioning mitm-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm
we had looked at the whole domain name certification process ... when
we were doing some consulting for a small client/server startup that
wanted to handle payments on servers ... and had this technology
called SSL ... old reference
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
part of the issue mentioned many times before is the economics to the
merchant related to fraud. the merchant is already paying a heavy
fraud burden effectively related to transaction insurance in form of
interchange fees. the digital certificates don't provide any
additional help in that area ... that was one of the reasons we coined
the term "comfort certificates" way back when.
start of one such tread, long ago and far away
https://www.garlic.com/~lynn/aepay4.htm#comcert Merchant Comfort Certificates
and the certificates being somewhat orthogonal to basic issues also
shows up in this old post on security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
aka merchant is already paying a hefty bill ... the certificates
provide little practical benefit to the merchant ... so it is
difficult for merchant to show any ROI for spending large amounts of
money on certificates ... which then means that certification
authorities have hard time charging a lot for certification
activities. this is my past observation that primary direction for
digital certificates left is to move into the low-value/no-value
market segment (which further reduces justification for doing a lot
related to the issurance of certificates). a few old posts on the
subject:
https://www.garlic.com/~lynn/aadsm20.htm#33 How many wrongs do you need to make a right?
https://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
and as i've frequently repeated in the past ... the miriad of
vulnerabilities and exploits was behind a lot of the x9.59 financial
industry standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
when in the mid-90s, the x9a10 financial standard working group was
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments.
it would be more logical to drop back to clients being able to get
"on-file" public keys directly from the domain name infrastructure for
providing assurance that the website that the browser things it is
talking to, is really the website the browser is talking to (and
provide for slimmed down SSL providing for information hiding while in
transits the internet) ... misc. past posts related to that subject
https://www.garlic.com/~lynn/subpubkey.html#catch22
and have the fraud and integrity issues related to types of
transactions integrated into existing infrastructure operations for
handling fraud and integrity issues.
a fundamental problem in security operations crops up trying to
address issues in adhoc and hodge-podge manner ... which leaves a lot
of openings and cracks for the attackers.
man in the middle, SSL
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: man in the middle, SSL
Date: Sat, 03 Feb 2007 10:04:18 -0700
To: James Muir <jamuir@xxxxxxxx>
CC: cryptography@xxxxxxxx
James Muir wrote:
It is my understanding that SSL is engineered to resist mitm attacks, so
I am suspicious of these claims. I wondered if someone more familiar
with SSL/TLS could comment.
Isn't in the case that the application doing SSL on the client should
detect what this proxy server is doing and display a warning to the user?
My oft repeated comment about when we were asked to consult with this
small client/server startup that wanted to do payments on servers
.... and had this technology called SSL ...
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
The browser was to check that what the person typed in ... matched the
domain name in the digital certificate that the server provided (that
the server that the client thot they were talking to was the server
that they were talking to).
There was some other ancillary things that we were interested in
... that the digital certificate actually represented something more
... i.e. it was issued by the acquiring financial institution that
financially stood behind the merchant .... since the merchant was
already paying a lot of money to cover doing business. however, that
never happened ... so the digital certificate just represents that it
belongs to the owner of the domain. this issue is somewhat touched on
in this blog posting
https://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
in this blog
https://financialcryptography.com/mt/archives/000863.html
However, early on, merchant webservers found that doing SSL for
the whole shopping experience cut their thruput by something like
80-90 percent ... so the industry fairly quickly switched to just
using SSL for the payment/checkout portion when you click on their
button. Now the URL is being provided by the server (button) ... not
by the client, as a result the effect is no longer "is the client
talking to the server that the client thinks they are talking to"
... since the server is supplying both the URL and the digital
certificate ... the result is "the server is the server that the
server claims to be" (unless it is a really dumb crook/attacker).
It isn't sufficient for there to be "ssl certificates" to be
countermeasure to MITM-attack, the security process has to include
that the server is validated against something the client supplies
... not that the server is validated against something the server
supplies (i.e. i can prove that i am whoever i claim to be ... not
that i can prove that i am who you think i am).
This is also behind a lot of the phishing stuff ... that the attacker
can claim to be something ... and provide a field/button for you to
click on ... the SSL certificate then just proves that the server
matches the URL provided by the field/button; since the attacker
supplying the field/button is producing the URL ... and not the client
... it takes advantage of the difference, for a MITM-attack
... between the opening/crack opened by what is claimed for the button
and what the URL actually is ... since only the URL is being validated
by the SSL certificate ... not what the client thinks is claimed for
the field/button. some more comments in these posts:
https://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"?
https://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007
lots of past posts mentioning MITM-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm
i.e. you have to understand the end-to-end business process (of
security) ... where all the cracks are ... and just which (of possibly
large number) MITM vulnerability ... that you have specifically
created a countermeasure for.
so one of the things that we did as part of early deployment (of this
stuff that has since come to be called electronic commerce) was go
around and do some detailed end-to-end audits of these emerging
operations that were calling themselves certification authorities and
producing these things that were being called SSL domain name digital
certificates. At the time, we coined this term certificate
manufacturing to try and differentiate what was happening
https://www.garlic.com/~lynn/subpubkey.html#manufacture
and what was in the literature about "public key infrastructure"
... for a little topic drift ... proposal from 1981 for a (small i)
infrastructure:
https://www.garlic.com/~lynn/2006w.html#12 more secure communcation over the network
Part of the "audits" was figuring out just what it was they were doing
as part of the process that they were calling certification ... as
the business process supporting the technology that produced the
actual digital certificates (i.e. a credential/certificate that is a
stand-in representation of the certification they were
performing). this gave rise to a lot of comments/observations about if
the domain name infrastructure actually provided a direct, higher
integrity operation ... it would obsolete any requirement for having
external certification operations (and therefor also could obsolete the
certificates as representations of those certification operations)
... lots of past posts mentioning such catch-22 scenario
https://www.garlic.com/~lynn/subpubkey.html#catch22
For other topic drift ... a recent post/comment about the early x.500 stuff
https://www.garlic.com/~lynn/2007b.html#31 IBMLink 2000 Finding ESO levels
and recent posts with comments about early x.509 identity certificate stuff
https://www.garlic.com/~lynn/2007.html#15 SSL info
https://www.garlic.com/~lynn/2007.html#17 SSL info
https://www.garlic.com/~lynn/2007.html#34 SSL info
https://www.garlic.com/~lynn/2007.html#42 The logic of privacy
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007d.html#10 The logic of privacy
man in the middle, SSL ... addenda
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: man in the middle, SSL ... addenda
Date: Sat, 03 Feb 2007 13:33:52 -0700
To: James Muir <jamuir@xxxxxxxx>
CC: cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
basically digital certificates were designed as the electronic
equivalent for offline distribution of information ... paradigm left
over from the "letters of credit" and "letters of introduction" out of the
sailing ship days (and earlier). as things moved into the online age
... certification authorities with digital certificates moved into
generic low-value/no-value market segment.
this is the difference between a generic employee badge for door entry
... that is identical for all employees ... vis-a-vis doing stuff
specific and tailored to each employee.
this is somewhat the x.509 identity certificate example mentioned in
the previous post ... from the early 90s ... overloaded with personal
information and paradigm that promoted repeatedly spraying the identity
certificates all over the world. by the mid-90s, it was starting to
dawn that such a paradigm wasn't such a good idea ... and there was
retrenchment to relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
which basically only contained public key and some sort of record
location (which holds the "real" information). however, in the
payment sector ... even these truncated relying-party-only
certificates still represented enormous payload and processing bloat
https://www.garlic.com/~lynn/subpubkey.html#bloat
especially when it was trivial to demonstrate that you could have the
public key along with all the other necessary information in the
designated record ... and that the digital certificate was therefor redundant
and superfluous. This is also somewhat the scenario raised in the
domain name infrastructure for on-file public keys .... creating a
significant catch-22 for the ssl domain name certification authority
industry
https://www.garlic.com/~lynn/subpubkey.html#catch22
... just upgrade the existing domain name infrastructure with on-file
public keys (a requirement also suggested by the ssl domain name
certification authority industry) ... but such a change could quickly result in a
certificate-free, public key infrastructure
https://www.garlic.com/~lynn/subpubkey.html#certless
.... also the reference from 1981
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
i.e. for the most part now ... SSL is just be using to prove that you
have some valid domain name ... and the domain name you claim is the
domain name you have ... this is somewhat equivalent to the low-value
door badge readers to simply check are you some valid employee ... w/o
regard to any higher value scenario requiring specific detail about
which valid employee.
so one of the points i repeatedly raise is that while digital
certificates (as representation of some certification) is part of an
offline paradigm construct ... and in the migration of the world to
online environment ... digital certificates have attempted to find
place in the no-value/low-value market niches ... that as soon as
there is some online component (real-time, online access to the
information) ... it then becomes trivial to show that such digital
certificates become redundant and superfluous.
so SSL domain name infrastructure was originally primarily being used
to support what came to be called electronic commerce (and still may
be the primary use) .... for:
1) is the browser actually talking to the webserver that the person
thinks it is talking to
and
2) hide (encrypt) the account number during transmission over the internet.
there have been some number of technical implementation
vulnerabilities with respect to SSL and things like
MITM-attacks ... but the big business process issue was that
the deployment fairly early changed from "is the browser actually
talking to the webserver the person thinks it is talking to" ... to
"the browser is talking to the webserver that the webserver claims to
be" (since the same webserver was supplying both the URL and the
digital certificate confirming the webserver supplied URL).
The second feature of ssl (encrypting to hide transmitted account
numbers) was somewhat to place the transactions flying over the
anarchy of the world-wide Internet ... on "level play field" with the
transactions that were fling over dedicated telephone wires. However, the
major vulnerability during that period ... and continuing today
... wasn't evesdropping the transaction during public transmission
... but vulnerabilities at the end-points .... which SSL does nothing
to address. The end-point webservers somewhat increased
vulnerabilities (compared to non-internet implementations) since a lot
of the transaction logs became exposed to attacks from the
internet. This matter is slightly debatable since the long term
studies ... continuing up thru at least recently, is that seventy
percent of the resulting fraudulent transactions involve some sort of
"insider".
So for SSL 1) the resulting major deployments of SSL negating much of the
original countermeasure against MITM-attacks (related to
integrity issues in the domain name infrastructure) and 2) the
encryption only slightly put internet transactions on same playing
field vis-a-vis the non-internet transactions ... and SSL did nothing to
address the major vulnerabilities (at least with regard to the fraud
related to the kind of transactions that might happen over the
internet ... whether the actually fraudulent transactions occurred
over the internet or not).
So after working on the stuff currently called electronic commerce
... we did some stuff in the x9a10 financial standard working group
... which in the mid-90s had been given the requirement to preserve
the integrity of the financial infrastructure for all retail
payments (ALL as in ALL ... and not just internet). the result was
x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
in the security PAIN acronym
P ... privacy (sometimes CAIN and confidentiality)
A ... authentication
I ... integrity
N .... non-repudiation
SSL was being used for privacy/confidentiality attempting to prevent
leakage of the account number. The x9a10 working group observation
was that the account number was needed in large number of different
business processes ... and couldn't just be simply kept hidden. This
somewhat resulted in my periodically repeated comment that the planet
could be buried under miles of encryption and still not prevent
account number leakage. This is because the account number is required
(unencrypted) in a large number of different places (and these processes
may occur over extended period of time)
So effectively ... x9.59 standard (security) could be described as
substituting "authentication" and "integrity" for
"privacy/confidentiality" in order to preserve the integrity of the
financial infrastructure. X9.59 transactions can be exposed all
over the place ... during transmission over the internet, in security
breaches involving transactions logs ... etc ... and the attackers
still wouldn't be able to use the information to perform fraudulent
transactions. It was no longer necessary to hide (encrypt) the account
number and/or the transactions to prevent fraud ... the information
could be widely publicly exposed and the crooks wouldn't be able to
use the information for fraudulent transactions.
In that sense ... x9.59 eliminates one of the primary uses of SSL for
hiding electronic commerce transactions (encrypting transactions) and some
suggested improvements in the domain name infrastructure integrity
eliminates most of the rest ... i.e. MITM-attacks.
man in the middle, SSL
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: man in the middle, SSL
Date: Mon, 05 Feb 2007 10:42:48 -0700
To: James Muir <jamuir@xxxxxxxx>
CC: cryptography@xxxxxxxx
somewhat related
Study Finds Bank of America SiteKey is Flawed
http://it.slashdot.org/it/07/02/05/1323243.shtml
Study Finds Security Flaws on Web Sites of Major Banks
http://www.nytimes.com/2007/02/05/technology/05secure.html?ref=business
The Emperor's New Security Indicators
http://www.usablesecurity.org/emperor/
from above
We evaluate website authentication measures that are designed to
protect users from man-in-the-middle, phishing, and
other site forgery attacks. We asked 67 bank customers to conduct
common online banking tasks. Each time they logged in, we presented
increasingly alarming clues that their connection was insecure. First,
we removed HTTPS indicators. Next, we removed the participant's
site-authentication image---the customer-selected image that many
websites now expect their users to verify before entering their
passwords. Finally, we replaced the bank's login page with a warning
page. After each clue, we measured whether participants entered their
passwords or withheld them.
... snip ...
somewhat the issue ... from previous posts in this thread:
https://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
and recent post/thread from early last month on the subject
https://www.garlic.com/~lynn/2007b.html#53
https://www.garlic.com/~lynn/2007b.html#54
... originally SSL was going to prevent man-in-the-middle attack
because the person knew the website that they were going to talk to
and the corresponding URL. They would enter that URL into the browser
and the browser would validate that the contacted website was in fact
the website for that URL (assuming the entered URL was HTTPS and not
HTTP)
early on, SSL was perceived to be too expensive, and so relegated it
to just checkout/payment. now the user entered URL with HTTP and the
website wasn't validated ... so could be man-in-the-middle. at some
point the user clicked on https (checkout/payment) button provided by
the website. now instead of HTTPS validating that the user was talking
to the webserver that they thot they were talking to ... HTTPS was
validating that the webserver was whatever webserver that the
webserver was claiming to be (since the webserver was providing both
the HTTPS URL and the SSL digital certificate).
so as the user convention of clicking on provided buttons proliferated
... the cracks/gaps widened between what webserver the user thot they
were talking to and the webserver they might actually be talking to
(since there was less & less a connection between what consumers
thot of as the website and the URLs that were being validated by SSL).
So one of the possible countermeasures was for a website to provide
unique something you know authentication ... i.e. something
hopefully only you knew (so you had higher degree of confidence that
you were actually talking to the website you thot you were talking to.
The problem was that if the communication was already talking to
man-in-the-middle website impersonation ... there is nothing that
would prevent the man-in-the-middle from impersonating the website to
the consumer ... and impersonating the consumer to the actual
website. Effectively, by definition for man-in-the-middle, the
man-in-the-middle transparently passes communication in both
directions (except possibly modifying URLs and internet addresses
contained in the traffic as needed).
in effect, the mechanism is a countermeasure to simple website
impersonation attacks (attacks on the consumer) ... but not to website
man-in-the-middle attacks.
other refs
https://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"?
https://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007
misc. past posts mentioning man-in-the-middle attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm
News.com: IBM donates new privacy tool to open-source Higgins
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: News.com: IBM donates new privacy tool to open-source Higgins
Date: Mon, 05 Feb 2007 11:41:28 -0700
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
Anne & Lynn Wheeler wrote:
http://news.com.com/IBM+donates+new+privacy+tool+to+open-source/2100-1029_3-6153625.html
from above:
The encrypted credentials would be for one-time use only. The next
purchase or other transaction will require a new credential. The
process is similar to the one-time-use credit card numbers that
Citigroup card holders can already generate on the bank's Web site.
... snip ...
past post:
https://www.garlic.com/~lynn/aadsm26.htm#24 News.com: IBM donates new privacy tool to open-source Higgins
... so if you had to go to the credential issuing website every time
you needed a one-time use credential (one-time use is countermeasure
to replay attacks involve static data credentials) ... what mechanism
are you using to authenticate yourself to the credential issuing
website.
if the mechanism for authentication to the credential issuing website
is of reasonably strong security ... then why don't you use that
mechanism directly in the regular transaction ... rather than having
to have an intermediary credential involved.
this is somewhat the argument used about digital certificates being
redundant and superfluous in an online environment ... whatever was
used to acquire the (x.509 identity) digital certificate
... especially a relying-party-only digital certificate
https://www.garlic.com/~lynn/subpubkey.html#rpo
to avoid repeatedly spraying personal information all over the world
... just use that interaction directly ... and avoid the superfluous
and redundant digital certificate.
this is the certificate-less public key infrastructure operation
https://www.garlic.com/~lynn/subpubkey.html#certless
in the x9.59 financial standard transaction
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
or in the similar FAST transaction (for matters other than financial
transaction authorization) done by FSTC in the 90s
http://www.fstc.org/
one might claim that this new mechanism is another approach to
addressing the enormous privacy exposure represented by the x.509
identity digital certificates from the early 90s ... but my oft
repeated claim is that the whole credentialing and certificate
paradigm is left-over from the offline era. in the online era ... if
the relying party either 1) has their own online information and/or 2)
has online, realtime access to the responsible authoritative agency or
institution ... then credentials and certificates purely represent
(redundant and superfluous) relics predating online infrastructures.
man in the middle, SSL
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: man in the middle, SSL
Date: Tue, 06 Feb 2007 08:40:18 -0700
To: Leichter, Jerry <leichter_jerrold@xxxxxxxx>
CC: James Muir <jamuir@xxxxxxxx>, cryptography@xxxxxxxx
Leichter, Jerry wrote:
Recall how SiteKey works: When you register, you pick an image (from a
large collection) and a phrase. Whenever you connect, the bank will
play back the image and phrase. You aren't supposed to enter your
password until you see your own image and phrase.
i.e. it is a countermeasure to a impersonation attack ... not a
man-in-the-middle (impersonation). all it presumably attempts to
address is "are you talking to the website you think you are talking
to" ... which is the same thing that SSL countermeasure to
man-in-the-middle is supposed to be doing.
man-in-the-middle can defeat simple impersonation countermeasures by
impersonating the server to the client and impersonating the client to
the server ... and (somewhat) transparently passing traffic in both
directions. requiring the server to present unique something you
know authentication information is then straight forward for
man-in-the-middle by having access to the "real" server.
i would contend that the issue for introducing sitekey ... was that
SSL wasn't adequately protecting against man-in-the-middle attacks
... i.e. previous posts
https://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL ... addenda
https://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle, SSL
... however, i contend that sitekey isn't even designed to be
countermeasure against man-in-the-middle attacks ... it only is a
countermeasure against simple impersonation attacks ... so it isn't
even addressing the short-comings in SSL that (my opinion) gave rise
for the need for sitekey in the first place.
the other issue is that "your own image and phrase" is a shared-secret
(and a flavor of static something you know authentication) ... so it
presumably requires similar practices required for password shared-secrets ... if it had turned out to significantly address SSL
short-comings (mitm-attacks) and saw wide deployment .... then
presumably you would need a unique flavor for every unique security
domain (ala password shared-secrets). The implication then is that it
would scale as poorly as password shared-secret paradigm.
previous post mentioning that the paradigm might scale as poorly as
other shared-secret based authentication implementations
https://www.garlic.com/~lynn/2007b.html#10 Special characters in passwords was Re: RACF - Password rules
misc. posts mentioning man-in-the-middle attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm
misc. posts mentioning shared-secret (authentication) paradigm
https://www.garlic.com/~lynn/subintegrity.html#secret
man in the middle, SSL ... addenda 2
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: man in the middle, SSL ... addenda 2
Date: Wed, 07 Feb 2007 11:44:28 -0700
To: cryptography@xxxxxxxx
so the assertion in the previous post
https://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL
was that sitekey as being introduced because of shortcomings in SSL
countermeasures to man-in-the-middle attacks .... however sitekey only
deals with simple impersonation and is easily defeated with a
man-in-the-middle attack
in earlier post
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
there was reference to SSL attempting to address man-in-the-middle
attacks and "are you really talking to the server that you think you
are talking to". however, SSL might be better characterized as
verifying that the operator of the webserver is the owner of the
corresponding domain name ... aka a digital certificate & pki
operation demonstrates that the operator of the webserver has use of
the private key that corresponds to the "public key" in the digital
certificate ... bound to the domain name. The browser than validates
that the domain name in the URL is the same as the domain name in the
(validated) digital certificate.
one of my assertions is that problems cropped up when the public
started associating webservers with buttons that they clicked on
... significantly degrading any association in most of the publics'
mind between URLs and the webserver. Since the public weren't
effectively associating URLs with webservers ... and the only function
provided by SSL (as countermeasure to man-in-the-middle attacks) was
validating the correspondence between the URL and the webserver .... a
widening security gap exists between the "buttons" that the public
associate with webservers and the URL, which is the unit of validation
by SSL
one conclusion is if countermeasures are introduced that don't
actually address the actual security vulnerabilities ... then they may
not be able to eliminate those security vulnerabilities.
so one countermeasure that has been introduced (to close some part of
the security gap) is by some of the email clients which look for
"buttons" in the content ... and if the label of the button appears to
be a url/http ... it checks if the actual url/http is the same as the
claimed url/http. if they don't match ... the email client will flag
the email as potential problem. The simple countermeasure by attackers
... is to not use a http/url label for the button (i.e. just label the
button something else, say the name of some financial institution).
Another kind of approach trying to close the gap between what the
people associate with webservers and the actual URL used ... is to
take a page out of PGP and have a list of "trusted" urls (or at least
domain names). Browsers display the assigned trust level recorded for
that domain name used in the URL (and then SSL verifies that the
webserver contacted is actually the webserver for that URL). This
would start to provide a mechanism for closing the gap between what
the public deals with and the part of the infrastructure being checked
by SSL.
(at least) two problems with this approach:
1) a repository of URL trust levels is almost identical to a trusted
public key repository (directly used by PGP). the repository could
directly record both the URL, the public key for that URL as well as
the associated trust level. this would be another demonstration of
digital certificates being redundant and superfluous in an online
world and would provide the basis for a more trusted environment than
the current SSL operation .... misc. past posts mentioning
certificate-less public key operation
https://www.garlic.com/~lynn/subpubkey.html#certless
2) so the new (old) attack is social engineering attempting to get
people to click on various buttons that change the trust level in
their local trust repository. however, that also exists today
... social engineering to get people to load certification authority
digital certificates into their local (certificate authority public
key) repository.
so number #1 doesn't eliminate all possible attacks ... however, it
actually addresses one of the identified security
vulnerabilities/attacks ... as opposed to supplying "fixes" for things
other than what is actually broken.
lots of past posts mentioning ssl domain name certificates
.... including posts in long thread about the certificates providing
more of a feeling of "comfort", as opposed to actually security,
integrity, trust, etc.
https://www.garlic.com/~lynn/subpubkey.html#sslcert
note that #1, in attempt to close the gap between what the public
associates with websites ... and what is SSL is validated for a
website (i.e. some chance that the operator of a webserver reached by
the domain name in the URL is the same as the owner of that domain
name) ... it can actually close some of the gaps ... but in doing so,
it increases the need for endpoints with some level of integrity
... and/or it leaves the end-points as possibly the weaskest link in
the trust chain. also as outlined in #1, the possibly integrity
improvement that comes from a local trust repository ... can also
result in making digital certificates even more redundant and
superfluous (doesn't reduce the need for public key operations
... just further reduces the need for digital certificates as a trust
mechanism) ... this is similar to other examples where improving
levels of trusts, also reduce the need for digital certificates as a
trust mechanism ... misc. related posts on the subject
https://www.garlic.com/~lynn/subpubkey.html#catch22
Failure of PKI in messaging
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Failure of PKI in messaging
Date: Tue, 13 Feb 2007 08:35:17 -0700
To: Ian G <iang@xxxxxxxx>
CC: Steven M. Bellovin <smb@xxxxxxxx>, Matt Blaze <mab@xxxxxxxx>,
James A. Donald <jamesd@xxxxxxxx>,
Cryptography <cryptography@xxxxxxxx>
Ian G wrote:
Actually, there are many problems. If you ask the low-level crypto
guys, they say that the HI is the problem. If you ask the HI guys, they
say that the PKI concept is the problem. If you ask the PKI people,
they say the users are not playing the game, and if you ask the users
they say the deployment is broken ... Everyone has got someone else to
blame.
They are all right, in some sense. The PKI concepts need loosening up,
emails should be digsig'd for authentication (**), and the HI should
start to look at what those digsigs could be used for.
But, until someone breaks the deadly embrace, nothing is going to
happen. That's what James is alluding to: what part can we fix, and
will it help the others to move?
iang
** I didn't say digital signing ... that's another problem that needs
fixing before it is safe to use, from the "ask the lawyers" basket.
looking at the ssl domain name certificate uptake scenario ... there
was a combination of things ... lots of publicity so that consumers
perceived it providing some benefit, merchants perceiving that the
consumers would feel better about it ... and therefor (for merchants)
that it was worthwhile to shell out the money ... and lots of
financial interests providing for publicity and support to have it
ubiquitously deployed (to encourage merchants to shell out the money).
lots of past posts mentioning the whole ssl domain name certificate
scenario
https://www.garlic.com/~lynn/subpubkey.html#sslcert
part of the problem was that the PKI financial model is out of kilter
with standard business practices. nominally a relying party has some
sort of relationship with the certifying agency (i.e. what they
are relying on) and there is exchange of value between the two
parties.
In the standard PKI model, there frequently is absolutely no
relationship between the relying party and the certifying agency. The
"owner" of the digital certificate is paying the certifying agency
... not the relying party ... so there is typically no exchange of
value between the certifying agency and the relying party ... and
therefor the relying party has no foundation for actually relying on
the certifying agency.
In early 90s ... there was some attempt to sidestep the lack of
business foundation for PKI ... by defining X.509 identity
certificates, frequently grossly overloaded with personal information
and then getting gov. regulations mandating the certificates. There
were also attempts to up the ante with semantic confusion attempting
to equate "digital signatures" with "human signatures". misc. past
posts about helping word smith various electronic signature
legislation and/or the wide divide between "digital" and "human"
signatures.
https://www.garlic.com/~lynn/subpubkey.html#signature
Remember that the (late 80s and) early 90s (with the attempts at ISO
x.509 identity certificates) was also in the period when you saw
various institutions and govs. mandating the elimination of the
internet and its replacement with ISO (OSI model) networking
standards.
one might even contend that in the ssl domain name certificate
scenario ... that once all the hype and publicity is stripped away
... that a fundamental issue is that the "relying party" has
absolutely no recourse with regard to the certifying agency when
things go wrong (which would exist in normal business relationship
between two parties). That the "padlock" symbol is purely a
representation of the hype and publicity ... and not a fundamental
business foundation.
recent thread about one of the major, fundamental justifications for
ssl domain name certificates ... countermeasure to man-in-the-middle
attacks ... and not being as effective as originally advertised:
https://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL
Failure of PKI in messaging ... addenda
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Failure of PKI in messaging ... addenda
Date: Tue, 13 Feb 2007 09:41:27 -0700
To: Ian G <iang@xxxxxxxx>
CC: Steven M. Bellovin <smb@xxxxxxxx>, Matt Blaze <mab@xxxxxxxx>,
James A. Donald <jamesd@xxxxxxxx>, Cryptography <cryptography@xxxxxxxx>
re:
https://www.garlic.com/~lynn/aadsm26.htm#32 Failure of PKI in messaging
another way of looking at the issue is somewhat alluded to in this
blog post
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browswer governance
somewhat contrasting SSL domain name certificate with association
branded payment instruments.
the association logos also promote a feeling of comfort for people
doing transactions ... but they have quite a bit of regulatory and
policy standing behind those transactions for the benefit of the
consumer ... something that you don't find in any of the ssl domain
name certificate operations.
at least in some of the PKI publicity and hype ... the concept was
conveyed that a relying party could base trust purely on a digital
certificate ... that the existence of a digital certificate provided
all the trust that anybody would ever need. however, there is a big
gap in the level of recourse provided to a consumer using an
association branded payment mechanism ... and the recourse provided to
a consumer (relying party) by the existence of a digital certificate.
i would contend that basic fundamental asymmetric cryptography defined
business process that allowed an individual to somewhat equate
digitally signed electronic communication nearly equivalent to having
face-to-face communication with an individual; aka it provided for
authentication and integrity. there was no sense of "trust" ... the
concept of trust was something that was associated with an individual
or entity ... digitally signature somewhat put electronic
communication on level playing field with face-to-face communication
... allowing it to be associated with a specific individual or
entity. The issue of "trust" was separate from being able to depend on
that equivalence.
this starts out purely as certificate-less operation
https://www.garlic.com/~lynn/subpubkey.html#certless
or this email from 1981 discussing using public key for secure communication
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
various PKI related publicity and hype from the 90s basically
attempted to equate digital certificates (added to an underlying
public key operation) would actually provide the basis for "trust"
between two parties that had no previous interaction (aka this is the
letters of credit/introduction from the sailing ship days scenario).
part of the issue was that there was frequently nothing that actually
provided recourse to the parties in the event that something didn't go
quite as expected (which is present in the association branded payment
mechanisms). such publicity/hype may also account for any confusion
that ssl domain name certification ... while only the basis for the
owner of a domain name is likely also the operator of a webserver
(addressed by that domain name) ... rather than actually the basis for
a webserver that a person thinks they are talking to is actually the
webserver they are talking to.
Failure of PKI in messaging
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Failure of PKI in messaging
Date: Wed, 14 Feb 2007 09:16:27 -0700
To: Leichter, Jerry <leichter_jerrold@xxxxxxxx>
CC: Ian G <iang@xxxxxxxx>, "Steven M. Bellovin" <smb@xxxxxxxx>,
Matt Blaze <mab@xxxxxxxx>, "James A. Donald" <jamesd@xxxxxxxx>,
Cryptography <cryptography@xxxxxxxx>
Leichter, Jerry wrote:
It's interesting to follow up on this idea, because it shows just how
profound the problem is. Imagine starting a business that ran a PKI
and did business the old way: You would charge someone *presenting*
an alleged certificate for an "OK". The "OK" would, for the fee paid,
provide insurance against the possibility of fraud. (Presumably, the
fee would be based on the size of the insured transaction and level
of experience and trust you have in the signing party.) It's to
your advantage to have many parties whose signatures you vouch for,
since that's what brings you customers; so you probably don't charge
that side of the business - though it helps someone to have a "high
trust" signature, since their customers will like paying a lower
premium to do assured business with them, so you could charge on
that side in some cases. But, unlike the case today, since your
own money is at stake if you vouch for someone untrustworthy, you
can't just go hand certs out to anyone who shows up at your door.
re:
https://www.garlic.com/~lynn/aadsm26.htm#32 Failure of PKI in message
https://www.garlic.com/~lynn/aadsm26.htm#33 Failure of PKI in messaging ... addenda
note that merchant interchange fee works this way ... i.e. the
merchant wanting to know whether it gets paid when you present your
card
recent posts with some interchange fee references
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
doing the original deployment of what currently has come to be called
electronic commerce, there was some investigation whether the payment
infrastructure would issue certificates ... since they were already
certifying merchants for processing of payment transactions (and the
digital certificates then become representation of that
certification). As mentioned before, merchants were already paying
fairly hefting interchange fee to effectively insure consumer
transactions ... that would have somewhat boxed-in/capped fees for ssl
domain name certificate operations ... which weren't providing
anything ... other than a lot of publicity and hype convincing public
that they should feel good about digital certificates ... previously
referenced posting in this blog
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
as i've often mentioned before ... this is probabily why the fed
gov. PKI has GSA signing contracts with certification authorities
... effectively making them agents of the federal gov. ... so
there is avenue for recourse and business reliance between the federal
gov as the relying party and the fedreal gov as the certificate
issuing operations (thru their agents via contractual relationship)
... i.e. effectively a relying party PKI operations
https://www.garlic.com/~lynn/subpubkey.html#rpo
the argument then is that in an online environment, the relying-party
digital certificates are redundant and superfluous. The two
diminishing PKI market segments are then
1) the original design point for digital certificates, situation where
the relying party has no repository of their own regarding prior
relationship with the certified entity and/or have no timely
connectivity to a certifying agency
2) no-value operations where the value of the transaction can't
justify relying parties keeping their own records and/or doing a
real-time transactions.
both of these remaining PKI market segments are rapidly shrinking as
(internet) online connectivity becomes ubiquitous and as the costs of
dataprocessing and networking continues to drop.
as mentioned numerous times, in effect, x9.59 financial standard just
augmented existing payment transactions with digital signature for
authentication and integrity. there were no requirement for digital
certificates ... for a wide variety of reasons ... in addition to
digital certificates being redundant and superfluous ... the
digital certificates also represented an enormous payload and processing
bloat that provides no fundamental added value
https://www.garlic.com/~lynn/subpubkey.html#bloat
the x9.59 consistent application of digital signature for
authentication and integrity ... w/o requiring any certificates
https://www.garlic.com/~lynn/subpubkey.html#certless
also eliminated simply "knowing" the associated account number as a
vulnerability ... that then eliminates a lot of the risk currently
associated with phishing and data breaches. x9.59 didn't eliminate
phishing and data breaches .... it just eliminated attackers being
able to utilize a lot of the acquired information for fraudulent
purposes.
With a pervasive use of SSL in the world today as support for
electronic commerce ... primarily to hide account numbers during
transit thru the internet ... x9.59 basically eliminates that need
.... effectively substituting authentication and integrity for
encryption (used to hide the account number).
So a level set ... rather than asking how to fix PKI for messaging
... since there are a lot of process and practices effectively result
in its failure ... start at a simpler level regarding what are the
authentication requirements for messaging. Digital signatures and
public keys might then be looked at for satisfying those
authentication requirements ... w/o necessarily requiring the
heavy-weight bloat and business process overhead related to PKI
deployments.
misc. past posts mentioning the GSA PKI scenario where contracts with
certifying authorities effectively make them agents of the federal gov
(creating a recourse and basis for relying)
https://www.garlic.com/~lynn/aepay10.htm#19 Misc. payment, security, fraud, & authentication GAO reports (long posting)
https://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
https://www.garlic.com/~lynn/aadsm18.htm#7 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
https://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
https://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
Failure of PKI in messaging
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Failure of PKI in messaging
Date: Fri, 16 Feb 2007 09:28:17 -0700
To: John Levine <johnl@xxxxxxxx>
CC: cryptography@xxxxxxxx, jamesd@xxxxxxxx
John Levine wrote:
It doesn't do anything about the obvious attack path of phishing
credentials from the users to stick bogus trusted entries into their
accounts. My examples showed all sorts of benign looking situations
in which users provide their credentials to parties of unknown
identity or reliability.
part of x9.59 financial standard
https://www.garlic.com/~lynn/x959.html
https://www.garlic.com/~lynn/subpubkey.html#x959
was to consistently require (digital signature) strong authentication
and integrity on all transactions. as a result, phishing, data
breaches, security breaches (with regard to account
numbers) was eliminated as risk vector (account numbers could be
divulged, phished, breached, etc ... but couldn't
be used for fraudulent purposes). this also eliminated needing SSL for
electronic commerce transactions (as part of hiding account
numbers). in the online model ... don't require independent
stand-alone/offline paradigm credentials ... just need a reliable
authentication mechanism that is reasonably resistant to attacks.
sort of as part the x9.59 effort ... in the later half of the 90s, was
the aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads
as countermeasure to software private keys being easily compromised
... i.e. digital signature becomes a something you have
authentication operation ... i.e. it represents having unique hardware
token containing the private key that generates the digital signature.
the next issue was hardware token costs ... both the costs of
individual hardware tokens ... as well as the aggregate infrastructure
costs related to institutional centric model with each institution
issuing their own hardware token.
the first part was addressed by eliminating everything thing from the
chip that wasn't in direct support of (security) of something you
have authentication ... and the other was moving from a "institution
centric" hardware token to a person-centric hardware token. Moving
to a person-centric hardware token also turns out to eliminate a
bunch of institutional hardware token personalization costs. The
objective was aggressive cost reduction gaining possibly two orders of
magnitude on per chip .... and instead of requiring a unique hardware
token effectively replacing every password a person currently uses
... just have one (or a small few) tokens per person. Institutional
specific credentials go away ... since the increase the per chip
issuing costs and tend to eliminate person-centric operation
(resulting in unique chips per institution).
This makes the hardware token (something you have) authentication
much more analogous to biometrics (something you are)
authentication. The hardware token for digital signature ... is
presented in very much the same way a RFID chip (with static number
vulnerable to replay attacks) might be presented ... or a fingerprint
is sensed (again w/o being subject to replay attacks) .... but not
requiring any other infrastructure, institutional, or application
specific processing (it becomes a single function ... authentication,
unlimited multi-app ... for whatever apps require authentication
... implementation). past posts about 3-factor authentication paradigm
https://www.garlic.com/~lynn/subintegrity.html#3factor
A couple of the remaining vulnerabilities are
- social engineering attacks getting victim to directly perform
operations on behalf of the attacker.
- direct chip attacks to give up private key
current phishing tends to be convincing the person that they have to
divulge some piece of information to verify and/or in support of other
operations. the attacker then uses the information to perform
fraudulent transactions w/o the victims knowledge. social engineering
to perform operations on behalf of the attacker would tend to raise
alarms in more peoples minds and possibly has less fraud ROI ... since
it would presumably require more effort on the attacker's behalf for
each fraudulent transactions. another possible social engineering
operation is to convince the individual to "return" their hardware
token (possibly as part of some required exchange operations). This
would be easier done with the institutional-centric model ... since
the victims would associate the token with the institution ... rather
than believing they "owned" the token (in a person-centric model).
the issue in direct chip attacks is attempting to keep the cost of the
attack somewhat higher than reasonable expected returns for the
attacker ... i.e. part of this is parameterised risk management. the
other is try and have the various chip attacks reasonably take longer
than the typical lost/stolen reporting interval ... i.e. associated
with an online transaction model. If the chip attacks cost more than
the reasonable return to the attacker ... or the attack typically
takes longer than avg. remaining lifetime before a lost/stolen report
deactivates the chip. In the parameterised risk management scenario
... the risk profile is registered for each kind of chip ... while
there is possibility of a single kind of chip serving all possible
operations ... there may be a case for multiple kinds of chips that
have different costs and risk profiles. Some scenarios might require
an individual to have a (person-centric) chip with a significantly
better risk profile (being able to perform transactions with values up
to the limit of a particular kind of chip risk profile).
This may not provide extensive countermeasures to the possible kinds
of attacks ... but it may be sufficient to provide countermeasures to
99percent of the current attacks (and make many of the remaining kinds
of attacks financially unattractive).
In the past, i've somewhat facetiously stated that the aads chip
strawman with person-centric approach and aggressive end-to-end cost
reduction could reduce fully loaded hardware token infrastructure
deployment costs by four orders of magnitude (reducing both per chip
costs as well as total aggregate number of chips for scenario where
hardware token authentication becames pervasive, say replacement for
all existing password/pin operations).
One of the scenarios is that there is currently a significant amount
of operations around hardware token paradigm that approach it from the
profit perspective ... as opposed to approaching it from the cost
perspective ... suggesting that total, fully loaded hardware token
deployment costs are potentially reduced by four orders of magnitude
has downside effect on many visions of profit.
disclaimer ... neither of us are associated with the owners of the
aads chip strawman patent portfolio
https://www.garlic.com/~lynn/aadssummary.htm
misc. past posts mentioning person-centric hardware token authentication paradigm
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
https://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
https://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005m.html#37 public key authentication
https://www.garlic.com/~lynn/2005p.html#6 Innovative password security
https://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
https://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
https://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
https://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
https://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
https://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing
New Credit Cards May Leak Personal Information
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: New Credit Cards May Leak Personal Information
Date: Fri, 16 Feb 2007 11:50:50 -0700
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
New Credit Cards May Leak Personal Information
http://news.yahoo.com/s/pcworld/20070216/tc_pcworld/129096;_ylt=A0WTUeOD9tVFrwkA7SwjtBAF
from above:
You may be carrying a new type of credit card that can transmit your
personal information to anyone who gets close to you with a scanner.
The new cards--millions of which have been issued over the past
year--use RFID, or Radio Frequency Identification, technology. RFID
allows scanners to use radio signals at varying distances to read
information stored on a computer chip.
... snip ...
this is somewhat discussed in recent post
https://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
i.e. x9.59 eliminating divulged account number as a vulnerability
... effectively substituting authentication & integrity for
privacy/confidentiality (leading to claim that x9.59 was privacy
agnostic)
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy
The other item mentioned in the article was leaking names. Part of the
x9a10 financial standard working group ... starting in the mid-90s
... was taking into account of an EU-directive (from the period) that
electronic point-of-sale transactions should be as anonymous as
cash. Somewhat the x9a10 assertion was that name on credit card was
required so that point-of-sale clerk could do additional
authentication by matching that name with the name on various forms of
identification. Given a sufficiently high integrity authentication
implementation ... the additional forms of authentication could be
eliminated and therefor the name on the card could be eliminated.
This also goes along with similar earlier discussions about RFID-enabled passposts
https://www.garlic.com/~lynn/aadsm25.htm#45 Flaw in RFID-enabled passports
https://www.garlic.com/~lynn/aadsm26.htm#0 Flaw in RFID-enabled passports (part 2?)
i.e. avoid unnecessarily spraying personal information all over the world
https://www.garlic.com/~lynn/aadsm26.htm#29 News.com: IBM donates new privacy tool to open-source Higgins
the parallel was drawn between these mechanisms deploying static data
personal identification information infrastructures and the x.509
identity digital certificates from the early 90s ... also raising
their own enormous privacy issues. In that period, there was even
suggestions that the x.509 identity digital certificates could be
overloaded with sufficient personal information that they could also
serve as electronic driver licenses and passports.
In the x9.59/aads model ... simple strong authentication and integrity
is used with sufficient countermeasures for things like replay attacks
and other kinds of exploits ... eliminating requirements for
significant amounts of additional personal information for
transactions
https://www.garlic.com/~lynn/x959.html#aads
Threatwatch: $400 to 'own' your account
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 25, 2007 04:26 PM
Subject: Threatwatch: $400 to 'own' your account
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000869.html
so maybe you will enjoy this one ... slightly different approach
... but there have been a number of recent articles about many attacks
are becoming quite a bit more focused
Security Reference Guide > How to Steal 80,000 Identities in One Day
http://www.informit.com/guides/content.asp?g=security&seqNum=243&rl=1
does overlap with
How to breach a company: Spies, Lies and KPMG
https://financialcryptography.com/mt/archives/000868.html
Usable Security 2007
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 25, 2007 04:47 PM
Subject: Usable Security 2007
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000852.html
and possibly related to the subject of "usable security in 2007",
... a thread that started out with "securing financial transactions a
high priority for 2007"
with mention of a URL for original article in this post
https://www.garlic.com/~lynn/2006y.html#7
then a whole lot of posts ... a relatively recent one with a number
news URL references to security breaches, skimming, and/or other
attacks harvesting account information enabling fraudulent
transactions (following also includes URL references to most of the
rest of the thread):
https://www.garlic.com/~lynn/2007e.html#2
and a post in the thread from today:
https://www.garlic.com/~lynn/2007e.html#12
with some number of additional "news" URLs
Chip and pin fails to halt card fraud rise
http://edinburghnews.scotsman.com/edinburgh.cfm?id=291732007
from above:
SHOPS have seen a massive rise in credit and debit card crime since
the introduction of chip and pin technology, according to a report
published today.
The new system was hailed as virtually fraud-proof but a survey by the
Scottish Grocers' Federation (SGF) suggests card crime has soared by
more than 50 per cent since 2005.
... snip ...
Fraud, embezzling and financial crime
http://business.scotsman.com/topics.cfm?tid=946
Card-skim criminals have police stumped
http://www.portsmouthtoday.co.uk/ViewArticle.aspx?ArticleID=2075455&SectionID=455
Plans to cut card fraud 'too complex'
http://www.itnews.com.au/newsstory.aspx?CIaNID=46197&src=site-marq
Plans to cut card fraud 'too complex'
http://www.itweek.co.uk/vnunet/news/2183738/plans-cut-card-fraud-slammed
Plans to cut card fraud 'too complex'
http://www.whatpc.co.uk/vnunet/news/2183738/plans-cut-card-fraud-slammed
Warnings over 'complicated' anti-fraud card systems
http://www.tuvps.co.uk/news/articles/warnings-over-complicated-anti-fraud-card-systems-18065845.asp
Usable Security 2007
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 25, 2007 05:05 PM
Subject: Usable Security 2007
Blog: Financial Cryptography
and for even further topic drift ...
https://www.garlic.com/~lynn/aadsm26.htm#38
for a totally different angle (sounds like an April 1st story? or
something out of truth is stranger than fiction)
Fraud victims told not to go to police
http://www.computeractive.co.uk/computeractive/news/2183192/cheque-card-crimes
gone 404 ... but lives on at wayback machine
https://web.archive.org/web/20070302123100/http://www.computeractive.co.uk/computeractive/news/2183192/cheque-card-crimes
from above:
People will no longer be able to report cheque or card fraud or theft
to the police under new rules being introduced by the Government.
From 1 April 2007, anyone who is a victim of this type of crime will
be told to report it to their bank or building society and not police.
It will now be up to financial institutions to report such crimes to
the police, which has lead to fears official figures will not truly
reflect the seriousness of the problem.
... snip ...
PKI: The terrorists' secret weapon
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PKI: The terrorists' secret weapon
Date: Wed, 14 Mar 2007 10:22:35 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx
Peter Gutmann wrote
-- Snip --
As Carl Ellison put it, "Plenty of PK, precious little I".
slightly related URL from this morning
Browser Certs Can't Force Adherence
http://www.networkcomputing.com/channels/security/showArticle.jhtml?articleID=198000131
in the past, i've repeatedly asserted that the "I" in PKI filled a
need related to letters of credit/introduction left-over from the
offline, sailing ship days.
In on online world, such "I" tends to be redundant and superfluous
... typically representing an (expensive) duplication of other
facilities.
Another way of looking at it is that typically cryptography has
represented some aspect of security ... and frequently the common
wisdom is that security is something that is best when built into the
basic core business processes and infrastructure ... rather than some
independent add-on. This possibly has contributed to failure of most
attempts to create large revenue flow for some independent
crypto/security feature (which frequently is a characteristic of PKI
deployments).
An example is some early to mid 90s proposed PKI deployments as an
electronic driver's license. The (driver's license) PKI certificate
supposedly would be grossly overloaded with personal information
... creating enormous privacy issues. Reliance on information in the
(PKI electronic) driver's license would be substituted for the growing
use of (online) real-time checks .... along with eliminating any of
the information that was becoming available from real-time checking
(outstanding warrants, revocation, overdue parking tickets, etc). Any
claims as to real-time checks still could be done, further highlighted
the PKI part being a significantly expensive redundant and superfluous
(add-on) operation.
lots of past references to certificate-less operation (
PK w/o the I
)
https://www.garlic.com/~lynn/subpubkey.html#certless
PKI: The terrorists' secret weapon (part II)
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PKI: The terrorists' secret weapon (part II)
Date: Wed, 14 Mar 2007 13:03:09 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm26.htm#40 PKI: The terrorists' secret weapon
so the other way of thinking about the "I" in PKI is that basically PK
is an Authentication mechanism, the "I" frequently stands for
attempting to move upstream in the value-chain revenue flow to
Identification.
several issues:
- emulation of the credential/certificate/license paradigm from the
offline world (like letters of credit/introduction) is net positive
when there is no other avenue for providing the necessary
information. it can quickly become redundant and superfluous in any
move into the online world.
- PKI perceived value supposedly increased proportional to the number
of attributes (i.e. personal information) included for an
entity. however (as repeatedly mention) this has tended to run into
serious privacy concerns. in some quarters rather than value
increasing with the amount of personal information included ... the
value increases as the amount of personal information goes to zero
- in numerous business processes, having online, real-time
information ... tailored specific to the business process ... is
significantly more valuable than lots of stale, static offline
information.
- in paradigm change to an online world, the stale, static offline
information methodologies tend to migrate into the no-value market
niches ... i.e. business processes that can't justify the cost of
higher-value, real-time information. being moved into no-value market
niches tends to create conflicts with objectives for moving upstream
in the value-chain revenue flows.
- any significant spending on offline, low-value, stale,
static information (credential/certificate/license) paradigm may
impact funds available for high-value online real-time operations; aka
any costs related to "I" (in PKI) should tend to zero ... at the same
time the unnecessary distribution of associated (personal,
identification) information tends to zero.
lots of past posts about purely PK Authentication operation w/o
needing any stale, static, redundant and superfluous "I"
(infrastructure and/or Identification) operation
https://www.garlic.com/~lynn/subpubkey.html#certless
"Dilemmas of Privacy and Surveillance" report launched
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: "Dilemmas of Privacy and Surveillance" report launched
Date: Wed, 28 Mar 2007 12:43:50 -0600
To: dave@xxxxxxxx
CC: ip@xxxxxxxx
Brian Randell wrote
Dave:
The (UK) Royal Academy of Engineering has just issued a report on
"Dilemmas of Privacy and Surveillance" that will I trust be of
considerable interest to IP.
From their press release at:
http://www.raeng.org.uk/news/releases/shownews.htm?NewsID=378
....
The full report is at:
http://www.raeng.org.uk/policy/reports/pdf/dilemmas_of_privacy_and_surveillance_report.pdf
this is somewhat the x.509 identity digital certificate scenario from
the early to mid-90s. By the mid-90s most organizations had realized
that identity digital certificates, typically grossly overloaded with
personal information represented significant privacy and liability
issues. What you saw at that time was many organizations retrenching
to what they called relying-party-only certificates ... containing
nothing more than some sort of database lookup index and a public
key. lots of past posts mentioning relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
in part because there had been so much information distributed
that the only way to provide security was via digital certificates.
however, it was trivial to demonstrate that in all of these
online scenerios ... that the digital certificate was redundant
and superfluous. the original scenario for digital certificates
was the electronic analogy to the offline sailing ship days
involving physical credential/certificates/licenses or things
like letters of credit/introduction ... for secure offline
distribution of information. in the transition to online environment
such instruments become largely redundant and superfluous.
lots of past posts referring to using public key digital signatures
for authentication .... w/o requiring digital certificates for
secure offline information distribution
https://www.garlic.com/~lynn/subpubkey.html#certless
similar discussion occurred in this earlier thread (which was also appeared
to this mailing list)
https://www.garlic.com/~lynn/aadsm25.htm#46 Flaw exploited in RFID-enabled passports
the same philosophy was used in the x9.59 financial standard ... requiring
authentication and authorization ... but not identification
https://www.garlic.com/~lynn/x959.html#x959
in the mid-90s, the x9a10 financial standard working group had been given
the requirement to preserve the integrity of the financial infrastructure
for all retail payments. part of a recent thread discussing x9.59 financial
standard and some of the other events that went on in the mid-90s ... and
how it continues to impact things today
https://www.garlic.com/~lynn/2007f.html#72 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007
in fact, in the mid-90s, we claimed that x9.59 was highly secure,
contained countermeasures to large variety of known
vulnerabilities and was privacy agnostic ... other posts mentioning
x9.59
https://www.garlic.com/~lynn/subpubkey.html#x959
Cost of an identity
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 28, 2007 05:03 PM
Subject: Cost of an identity
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000877.html
some cross over from another forum
We can have 'win-win' on security vs. privacy, says Acadamy
http://www.raeng.org.uk/news/releases/shownews.htm?NewsID=378
Dilemmas of Privacy and Surveillance Report
http://www.raeng.org.uk/policy/reports/pdf/dilemmas_of_privacy_and_surveillance_report.pdf
some comments
https://www.garlic.com/~lynn/aadsm26.htm#42
Governance of anonymous financial services
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Governance of anonymous financial services
Date: Fri, 30 Mar 2007 16:18:05 -0600 To: Ian G <iang@xxxxxxxx>
CC: Steve Schear <s.schear@xxxxxxxx>, cryptography@xxxxxxxx
Ian G wrote:
E.g., Ricardian contracts (my stuff) take the user agreement as a
document and bind it into each transaction by means of the hash of the
contract; they also ensure various other benefits such as the contract
being available and readable to all at all times, and the
acceptability of same, by the simple expedient of coding the
decimalisation into the contract. Ensuring that the contract is
readable, applicable and is available to all is a huge win in any
court case.
Other governance tricks: the usage of signed receipts can be used to
construct a full audit of the digital system. Also, signed receipts
are strong evidence of a transaction, which leads by some logic to a
new regime which we call triple entry accounting. This dramatically
changes the practice of accounting (which feeds into governance).
With DB side, one trick is to use psuedonym accounts for the basis,
and this allows no-loss protocols to be created. Again, this is useful
for governance, because if you have a lossy protocol, you have a
potential for fraud.
we had done something analogous in the x9.59 financial standard. the
x9a10 financial standard group had been given the requirement to
preserve the financial infrastructure for all retail payments.
https://www.garlic.com/~lynn/x959.html#x959
digital signature on the transaction itself provided for
end-to-end strong authentication (armoring payment transaction as
countermeasure to various kinds of replay attacks ... as
have been in the news recently related to large data breaches
and then being able to subsequently use the information for fraudulent
transactions).
one of the "problems" was that some of the other attempts at
PKI-related payments protocols in that period ... were creating
enormous (two orders of magnitude) processing and payload bloat
https://www.garlic.com/~lynn/subpubkey.html#bloat
one of the implied x9a10 requirements was efficiency, i.e. mechanism
that could be deployed in ALL environments (internet, point-of-sale,
cellphone, etc) ... and needed to be highly concerned about
processing and payload efficiency.
the actual transaction is digitally signed ... and it is also the
thing that is authorized, logged, archived, audited, etc.
so part of x9.59 provided for a hash of the receipt (contract,
bill-of-materials, sku data, "level 3" data, etc) as part of the
digitally signed payload (as opposed to including the whole
receipt). Then in any subsequent dispute, if both parties didn't
produce identical receipts ... the hash from the
audited/logged/archived transaction could be used to determine the
valid/correct receipt.
While the receipt
wasn't part of the actual audited/archived/logged transaction, the
process provided a mechanism (in cases of disputes) for establishing
the legitimate receipt.
we claimed privacy agnostic for x9.59 ...
https://www.garlic.com/~lynn/subpubkey.html#privacy
i.e. there was an account number in protocol but the degree that any
jurisdiction required a binding between an account number and an
individual was outside the x9.59 protocol. x9.59 was designed so that
it could be used for credit, debit, stored value, ach, etc. In many
jurisdictions, credit & debit can have some "know you customer"
requirements for financial institutions (binding between individuals
and account numbers) ... however there was 1) no requirement to
divulge such bindings during retail transactions and 2) x9.59 applies
equally well to stored-value retail transactions (where there is much
less frequently a requirement imposed for "know your customer").
Cost of an identity
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 31, 2007 08:31 AM
Subject: Cost of an identity
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm26.htm#43 Cost of an identity
of possible some interesting additional drift ... response to comment
in a mainframe n.g.
https://www.garlic.com/~lynn/2007g.html#19 T.J. Maxx data theft worse than first reported
in the response ... i even made reference to one of the analogies made
in this thread
and then a followup
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
the followup has reference to news item claiming that the exploit
wasn't copying transaction log ... but skimming the transaction as it
was being processed. the original comment somewhat implied that the
problems would all go away ... if merchants stopped storing account
numbers (in transaction logs). however, this latest (largest) exploit
may not have involved transaction logs at all.
The Founder Paradox
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 31, 2007 09:06 AM
Subject: The Founder Paradox
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000871.html
could consider analogous problem in Boyd's characterization of issues
in corporate america stemming from training executives had gotten as
young officers going into ww2.
the issue was that the country had to deploy an enormous number of
inexperienced and relatively untrained personal. the solution was to
create a rigid, top/down command & control structure ... attempting to
leverage the few skilled individuals that were available.
later, as these young officers started to populate corporate america
... they brought along with them the rigid, top/down command & control
structure paradigm ... based on original premise that it is necessary
in order to deal with (possibly large numbers of) inexperienced and
unskilled individuals.
some recent posts on the subject in another thread:
https://www.garlic.com/~lynn/2007e.html#45 time spent/day on a computer
https://www.garlic.com/~lynn/2007e.html#55 time spent/day on a computer
https://www.garlic.com/~lynn/2007f.html#41 time spent/day on a computer
one of boyd's observations was that the rigid, top/down, command &
control structure required something like 12 percent officiers ... he
contrasted this with the german army with only something like 3percent
officers
misc. past posts mentioning boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
and lots of URLs from around the web mentioning boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2
SSL MITM-attacks make the news
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: SSL MITM-attacks make the news
Date: Mon, 02 Apr 2007 11:35:31 -0600
To: cryptography@xxxxxxxx
ABN Amro compensates victims of 'man-in-the-middle' attack
http://www.finextra.com/fullstory.asp?id=16750
from above:
Four ABN Amro customers activated a virus allowing a man-in-the-middle
attack that overcame the bank's two-factor authentication. After the
attack, ABN Amro removed an 'urgent payment' option from its Web site
as a precaution, compensated the customers and launched a campaign to
remind users about internet banking safety.
... snip ...
and lots of past posts mentioning MITM-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm
Governance of anonymous financial services
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Governance of anonymous financial services
Date: Tue, 03 Apr 2007 12:52:21 -0600
To: Ian G <iang@xxxxxxxx>
CC: Steve Schear <s.schear@xxxxxxxx>, cryptography@xxxxxxxx
Ian G wrote:
OK, on the face of it, you seem to have been doing triple entry (with
the twist of a hash). Actually I am not so sure that it is even twisted
... as you are simply saying that someone somewhere was logging the
hash; but not who was storing the receipts.
To point: is this written up anywhere? <gollum> did I really ask
that? ;)
I wrote this concept up in a paper and am very happy to expand to
include other art and implementations, given more than copious free time...
http://iang.org/papers/triple_entry.html
I'm integrating (or should be) the work that Todd Boyle has done on
accounting, because his concept is more rather than less analogous.
re:
https://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services
so applying x9.59
https://www.garlic.com/~lynn/x959.html#x959
mapping to iso 8583 (i.e. credit transactions, debit transactions
... and even some number of stored-value transactions carried by some
point-of-sale terminal and ... at least part of the financial network)
https://www.garlic.com/~lynn/8583flow.htm
you have the standard iso8583 financial transactions with a x9.59
addenda ... that includes a digital signature, a hash of the receipt
and some misc. other stuff.
existing infrastructure advises that both merchant and consumer retain
(paper) receipts (in case of disputes). x9.59 financial standard
didn't specify/mandate how that might be done ... but provided for
support for applications for doing.
the financial transaction was already required to be archived/logged
for all sorts of regulations and business processes (as evidence some
number of recent breach references).
In the mid-90s, the x9a10 financial standard working group had been
given the requirement to preserve the integrity of the financial
infrastructure for ALL retail payments. In numerous other references
I've mentioned that doing required taking into account all sorts of
considerations as part of x9.59 standard (including countermeasures to
fraudulent transactions from breaches), it had to be extremely
lightweight because of numerous considerations when you are asked to
consider ALL retail transactions (including looking forward to various
c ontactless, wireless, cellphones, transit turnstyles, etc), and
maximizing the optimal use of all the existing processes and flows.
In any case, as a result, the "x9.59" transaction would be
logged/archived as part of existing standard financial transaction
processes ... which includes the digital signature against the full
transaction ... where the full transaction ... along with the digital
signature is being logged ... including the receipt hash and the
additional x9.59 specified fields.
the "receipt", that is hashed, isn't specified as part of the x9.59
protocol standard ... but is assumed to be whatever is necessary to
support resolution, in case of any dispute (at least the equivalent of
saying that both the merchant and consumer retained paper receipt
copies in the case of dispute).
we actually may have done too good a job. a lot of efforts that have
worked on doing similar or related efforts ... essentially viewed it
as profit opportunities. the x9a10 standards worked view all the
"stuff" as added expense ... to be aggressively eliminated as much as
possible. For instance in the AADS chip strawman
https://www.garlic.com/~lynn/x959.html#aads
in the mid-90s, i would semi-facetiously say that we would take a $500
mil-spec part, aggressively cost reduce it by 2-3 orders of magnitude,
increase its security/integrity, have it form-factor agnostic (as well
as being able to meet contactless transit turnstyle requirements).
to compound the problem ... we also did a bit of work on being able to
change the institutional-centric something you have authentication
paradigm to a person-centric paradigm ... i.e. rather than having one
"something" per institution ... you could have one (or a very few)
"somethings" per person (could be viewed as creating the something
you are biometric authentication analogy for something you have
authentication). misc. past posts mentioning 3-factor authentication
paradigm
https://www.garlic.com/~lynn/subintegrity.html#3factor
so having something that was aggressively cost reduced by 2-3 orders
of magnitude, more secure ... and instead of having one per
institution/environment (that a person was involved with), they would
have only one (or a very few). overall (for all possibly environments
requiring authentication) this could have represented possibly four
orders of magnitude cost reduction (that many others were viewing as
potential profit opportunity).
in any case, who would be the stake-holders interested in something
that eliminates nearly all fraud and nearly all costs?
a few past posts mentioning working on change-over to a person-centric paradigm:
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
https://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
https://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
https://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
https://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing
Governance of anonymous financial services
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Governance of anonymous financial services
Date: Tue, 03 Apr 2007 15:25:15 -0600
To: Ian G <iang@xxxxxxxx>
CC: Steve Schear <s.schear@xxxxxxxx>, cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services
https://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
My wife has been gone five years and I've been gone for over a year
(they had corporate re-org in Dec '05) ... and we have no
rights/interest ... but they continue to trickle out
https://www.garlic.com/~lynn/aadssummary.htm
latest today (3Apr2007) ... hot off the press:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=1&p=1&f=G&l=50&d=PTXT&S1=7200749.PN.&OS=PN/7200749&RS=PN/7200749
Method and system for using electronic communications for an electronic contract
Abstract
A method and system for digitally signing an electronic contract
document. An electronic communication contains an identifier, a
message, which includes the document, and a digital signature
generated with a private key of an asymmetric key pair (247). The
identifier may be used to retrieve a corresponding public key (287)
and account information pertaining to the sender of the message. The
public key may be used to authenticate the sender and the message. A
device containing the private key may be used to protect the privacy
thereof. The device may also generate a verification status indicator
corresponding to verification data input into the device. The
indicator may also be used as evidence that the sender of a contract
document performed an overt act in causing the electronic
communication to be digitally signed. A security profile linked to the
public key in a secure database indicates security characteristics of
the device.
... snip ...
for a little drift ... slightly related to this recent posting in sci.crypt
https://www.garlic.com/~lynn/2007g.html#40 Electronic signature outside Europe
DNSSEC to be strangled at birth
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: DNSSEC to be strangled at birth.
Date: Sat, 07 Apr 2007 11:03:04 -0600
To: Dave Korn <dave.korn@xxxxxxxx>
CC: 'Paul Hoffman' <paul.hoffman@xxxxxxxx>,
tls@xxxxxxxx, cryptography@xxxxxxxx
Dave Korn wrote:
We already had this with PKI and SSL, and it basically failed.
Works fine on a small scale in a tightly-disciplined organisation;
fails totally to scale to Joe Internet-User.
one could claim that PKI failed ... especially in its trusted 3rd
party scenario ... since it was an amazingly complex and expensive
deployment to solve a rapidly vanishing problem.
the basic design point is the electronic analog for physical
credentials, certificates, licenses used in the "offline" world ... or
the electronic analog of letters of credit/introduction from the
sailing ship days (and before) ... the trusted distribution of
information for the benefit of relying parties that had no other
recourse for the information.
in an online world ... a paradigm designed for trusted distribution of
information for an offline world, rapidly becomes redundant,
superfluous and obsolete (besides enormously NOT cost effective).
SSL was intended as countermeasures to two vulnerabilities 1) are you
really talking to the server that you think you are talking to (among
other things ip-address hijacking) and 2) evesdropping of information
in transit.
The SSL solution to #1 was predicated on the end-user having knowledge
of a trusted binding between the server he thought he was talking to
and the URL for that server. The SSL protocol then provided the
trusted binding between the URL and the server the user was actually
talking to. That weak-link in all of this was current infrastructure
where end-users frequently have very little knowledge of the binding
between the server they think they are talking to and the URL for that
server.
It isn't so much that SSL has failed to do what it was implemented to
do, it is that SSL failed to take into account that part where
end-users have very little knowledge of the relationship between
servers and the URLs for those servers. It isn't so much a small-scale
population that it works for ... it requires a (disciplined)
population that maintains adequate knowledge of the relationship
between servers and the URL for those servers. Even a well disciplined
population is likely only to maintain knowledge of strong binding
between servers and URLs ... for only a small number of servers and
their corresponding URLs. The same population may be also be
vulnerable when dealing with URLs and servers outside some well
regulated domain.
these series of posts talk about eliminating PKI and digital
certificates for SSL ... and going to real-time public key operations
in the domain name infrastructure ... as countermeasure to ip-address
hijacking (original SSL) as well as domain name hijacking (as well as
providing mechanism for encrypting information while in transit).
https://www.garlic.com/~lynn/subpubkey.html#catch22
Aka the current domain name certification authority PKI-based paradigm
has its root trust in the validity of the information at the domain
name infrastructure. While the existing SSL/PKI related implementation
was targeted at ip-address take-over ... it still remained vulnerable
to domain name hijacking.
however, the real-time domain name public keys, still doesn't address
the vulnerability of end-users typically not having knowledge of
strong binding between the website they think they are talking to and
the corresponding URL (making them vulnerable to website impersonation
and social engineering attacks that get them to click on arbitrary
URLs).
Solutions for these vulnerabilities ... typically involve some amount
of additional trust operations by the users ... along the lines of
local repository of trusted public keys with the corresponding trusted
binding to trusted URLs (which starts to look somewhat like the PGP
email public key repository). One of the issues for such solutions is
that they lack the economic incentive for large scale deployment
(i.e. there is no 3rd party taking in money selling digital
certificates).
The One True Identity -- cracks being examined, filled, and rotted out from the inside
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 8, 2007 05:47 AM
Subject: The One True Identity -- cracks being examined, filled, and rotted out from the inside
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000882.html
so can some of this be merged into a comprehensive paradigm for the
public ... which also has some spill over from a number of other
recent threads
so in this (and other) thread:
https://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services
https://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
https://www.garlic.com/~lynn/aadsm26.htm#49 Governance of anonymous financial services
i claimed that the work on x9.59 financial standard protocol in the
mid-90s ... attempted to take into account some sort of EU directive
about financial transactions at point-of-sale should be as anonymous
as cash.
the x9a10 financial standard working group, in the mid-90s had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments ... resulting in x9.59
https://www.garlic.com/~lynn/x959.html#x959
we claimed that x9.59 was privacy agnostic ... the only thing exposed
at retail point-of-sale was an account number. It was then up to
various jurisdictions whether there was any association/binding for
the account number. In many jurisdications there are "know you
customer" requirements that at some point requires a binding between
an account number and an individual ... at least for credit & debit
transactions. "stored-value" account numbers are still allowed to be
anonomous in many jurisdications ... all of these can be supported by
a common x9.59 protocol.
for even more drift
https://www.garlic.com/~lynn/aadsm26.htm#47 SSL MITM-attacks makes the news
https://www.garlic.com/~lynn/aadsm26.htm#50 DNSSEC to be strangled at birth
https://www.garlic.com/~lynn/2007g.html#58 Can SSL sessions be compromised
https://www.garlic.com/~lynn/2007g.html#60 Can SSL sessions be compromized
part of the issue is that how an entity is referred to
(identification) and what trust, privileges and permissions might
be granted that entity are totally different operations. It may be
possible to have a single, unique method of referring to an entity
... but that would never carry with it the sense of
trust/privileges/permissions which are nominaly extremely context
sensitive. This has been one of the places that "digital certificates"
have frequently strayed into dangerous waters ... attempting to bolix
up identification, authentication, trust, privileges, and permissions
into one big mash.
so for slightly more drift, a scenario is to take address books,
bookmarks, pgp key management, certificate management, etc ... and
merge them all into a single (context specific) contact metaphor
rather than having to educate the public about what pgp keys are and
certificates are ... they become a trust attribute related to
contact. the downside is this somewhat commoditizes the whole
PKI/certificate paradigm for the public. It is no longer a unique
high-priced operation, it is significantly simplified as a contact
attribute/characteristic (The CA is a "contact" and it can be trusted
to provide some kinds of trusted information about other contacts).
(email) pgp key lookup and (URL) public key lookup at domain name
system can appear as a single operation ... checking/validating the
trust of a contact ... just another characteristic/attribute of
contact.
the simplification is to take a single metaphor that the public is
already used to dealing with and merging all the myriad of disparate
operations into that single metaphor.
the claim can be made that trust hierarchy metaphors don't go over
well with the public because it doesn't match how most of the public
deal with the world.
however, it is fairly well established that the public can deal with
the world within a contact metaphor ... where trust could then become
an attribute within the contact metaphor (however, this may
drastically minimize the heights that some institutions try to raise
the status of trust to an extremely expensive independent paradigm).
the issue here is that the current SSL deployment fails to account for
the large gap that exists in the publics' mind between webservers they
think they are talking to and the URL that is used to contact those
webservers (and SSL only provides a check on whether the webserver
being talked to and the URL used to talk to the webserver are
consistent).
contacts can provide a methaphor for the public ... that spans the
gap. then there are two symbols that might be displayed for a URL
... one is its "trust" level symbol (from the contact repository) and
the other is the padlock ... which is purely related to whether the
transmission is being encrypted over the internet (i.e. the trust of
the site and whether there is countermeasure for evesdropping are two
independent characteristics).
Using consistent paradigm for all kinds of contacts ... then could
also mean that there be a consistent metaphor/representation for trust
and encryption across URLs, email, instant messages, etc.
contacts might include globally unique identifier ... but also have
local, context specific trust, permissions, privileges, etc.
The One True Identity -- cracks being examined, filled, and rotted out from the inside
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 8, 2007 12:10 PM
Subject: The One True Identity -- cracks being examined, filled, and rotted out from the inside
Blog: Financial Cryptography
Iang wrote:
Lynn,
possibly, the notion of using a contact metaphor has been explored
with the Bookmarks metaphor. The Petname concept has found some ease
of implementation by merging with the Bookmarks in web browsers. And
while Petnames are hard to describe, Bookmarks are easy.
When a user adds a bookmark, she names it how she wants. This becomes
a petname to a resource, a local, user-defined-and-known private
name. By adding a little crypto trickery (hash of the public key of
the server) to the bookmarks database, then we create a secure petname
and this can be used by a plugin to positively identify a repeat
visit.
The concept works and works well (Petname Toolbar is a minimalist
design, Trustbar also develops it further, and later generation
toolbars have incorporated the idea). It requires a slight user
training. One can criticise this on the basis that users don't do
anything, and can't be trained at all; or one can say this is the best
bang for buck that is currently available, for those who can be
trained, if we assume that user information has to be tapped in some
sense as a better or useful relationship.
re:
https://www.garlic.com/~lynn/aadsm26.htm#51
contacts (with address books) have frequently added several additional
optional information. making single consistent implementation for all
activity might simplify the web experience ... driving all from a
single interface/metaphor.
some address books already have automatic adding email addresses
... but without additional information ... however the additional
fields are there. so an equivalent might do something equivalent for
URLs ... possibly starting only with ones that claim HTTPS. then
additional fields might be optionally selected.
in some ways this might be viewed as analogous operation to IE domains
... but instead of being driven off the (security) domain metaphor
(and specifying URLs for each domain) ... it is driven off a (single)
contact metaphor ... selecting what optional information gets
specified for a URL.
optional information could be policy collections ... analogous to IE
domains ... and/or specific permissions.
the difference is that it changes from a security metaphor to a
(single, consistent) contact metaphor.
Getting a bank's URL loaded into contacts list with various online
banking related attributes ... then can start to close the existing
(SSL) gap between the server that a user thinks they are talking to
and the URL.
This would make web-based banking operate somewhat more like the
financial packages (quicken, money, etc) ... where registration of the
financial institution for banking is required (even tho under the
covers the financial packages may be using SSL for encryption).
Also more analogous to operation of earlier online banking operations
that had installed software with the necessary contact information for
doing direct dialed operation.
In the mid-90s, there were a couple of financial institution
presentations that mentioned that existing online banking software
required the financial institution to directly support something like
50-60 different flavors of modem drivers (different modem products,
different operating systems, etc) as well as have call-center support
for dailin operation.
Transition of online banking (or other online operations) to
"Internet" was enormous savings for the institution since it
effectively outsourced all the online gorp to an external organization
... and the external organization was able to amortize the online
connectivity across a broad range of (additional) offerings/services
to the consumer.
This consolidating of a large number of offerings/services was an
enormous cost savings to individual institutions and enormous benefit
to the consumer ... but also created a large ambiquity about who the
consumer was dealing with at any specific point in time (and SSL
doesn't actually provide complete end-to-end coverage eliminating all
of that ambiquity).
The consumer direct registering of attributes for specific contact
... would somewhat close the gap (left by SSL). It also removes some
of the disintermediation(?) that was introduced by the internet and
3rd party CAs between the consumer and the institutions that they were
dealing with (compared to earlier "direct" online software packages)
The problem is that could also be viewed as eliminating the excuse for
3rd party CAs charging institutions for digital certificates ... since
all that could be subsumed by user specifically loading institution
contact information (and SSL changed to directly use loaded public key
in the contact information).
The One True Identity -- cracks being examined, filled, and rotted out from the inside
Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 8, 2007 01:39 PM
Subject: The One True Identity -- cracks being examined, filled, and rotted out from the inside
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm26.htm#51
https://www.garlic.com/~lynn/aadsm26.htm#52
to even further extend the topic drift ... in the 90s, i gave a couple
conference talks as well as a graduate student seminar at ISI (USC)
that included the IETF editors organization.
It basically was that there had been a lot of protocols migrated from
circuit-based infrastructure to Internet (packet) operation ... w/o
taking into account that there were a lot of implicit characteristics
of the end-to-end circuit operation that were lost in the transition
to packet operation.
When we were called in to consult with a small client/server startup
about doing payment transactions on their server (with some technology
they had called SSL ... and since has frequently come to be called
electronic commerse), we had "sign-off" on the server to payment
gateway implementation (I somewhat facetiously joke is the original
SOA implementation).
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
One of the things we specified was extensive "compensating procedures"
(and added business critical dataprocessing features) as part of
moving financial transaction operation from circuit-based operation to
packet-based operation. We also tried to suggest that some similar
stuff should be implemented in the browser to server interface
... however we would get back responses like "that is too complicated"
... and since we only had sign-off on the server/gateway
implementation we couldn't force it.
some recent posts mentioning the topic:
https://www.garlic.com/~lynn/2007.html#15 SSL info
https://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007f.html#37 Is computer history taught now?
https://www.garlic.com/~lynn/2007g.html#38 Can SSL sessions be compromised?
https://www.garlic.com/~lynn/2007g.html#51 IBM to the PCM market
for other drift ... at the time I was doing some work with the RFC
editor related to RFC index and consistency of information in
STD1. That RFC index work continues and is at:
https://www.garlic.com/~lynn/rfcietff.htm
What to do about responsible disclosure?
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 9, 2007 03:05 PM
Subject: What to do about responsible disclosure?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000887.html
A little drift
Data Breach Notification Laws: A State-by-State Perspective
http://www.intelligententerprise.com/channels/infomanagement/showArticle.jhtml?articleID=198800638
Congress and Data breaches
http://computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=privacy&articleId=9015819&taxonomyId=84http://computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=privacy&articleId=9015819&taxonomyId=84&intsrc=kc_featamp;intsrc=kc_feat
this somewhat related to old security proportional to risk posting
https://www.garlic.com/~lynn/2001h.html#61
recent posts about having gotten exposed to some of cal. notification
legislation (both opt-in/opt-out stuff related to privacy matters as
well as breach stuff) when we were called into help wordsmith the
electronic signature legislation.
https://www.garlic.com/~lynn/2007f.html#72 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#8 Securing financial transactions a high priority for 2007
The One True Identity -- cracks being examined, filled, and rotted out from the inside
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 11, 2007 05:34 PM
Subject: The One True Identity -- cracks being examined, filled, and rotted out from the inside
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000882.html
other posts in this thread:
https://www.garlic.com/~lynn/aadsm26.htm#51 The One True Identity -- cracks being examined, filled, and rotted out from the inside
https://www.garlic.com/~lynn/aadsm26.htm#52 The One True Identity -- cracks being examined, filled, and rotted out from the inside
https://www.garlic.com/~lynn/aadsm26.htm#53 The One True Identity -- cracks being examined, filled, and rotted out from the inside
recent article
IBM's Higgins project: anonymous authentication for all
http://arstechnica.com/news.ars/post/20070411-ibms-higgins-project-offers-anonymous-internet-logins.html
comments in another fora after an earlier item in Jan.
https://www.garlic.com/~lynn/aadsm26.htm#24 IBM donates new privacy tool to open-source Higgins
Threatwatch: MITB spotted: MITM over SSL from within the browser
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 12, 2007 12:17 PM
Subject: Threatwatch: MITB spotted: MITM over SSL from within the browser
Blog: Financial Cryptography
re
https://financialcryptography.com/mt/archives/000884.html
Boarding Pass Hacker Targets Bank of America
http://it.slashdot.org/it/07/04/12/1444204.shtml
slight paranoia: A Deceit-Augmented Man In The Middle Attack Against
Bank of America's SiteKey Service
http://paranoia.dubfire.net/2007/04/deceit-augmented-man-in-middle-attack.html
from above:
Whereas a normal man-in-the-middle attack identically replicates the
attacked site, a deceit-augmented man-in-the-middle attack may present
the user with a slightly different user interface than the regular
interface. Man in the middle (MiTM) attacks are not a new threat -
they have been known about for a number of years, and phishers have
already used them to target Citibank and other online banks.
... snip ...
and past reference:
https://www.garlic.com/~lynn/2007d.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/aadsm26.htm#47 SSL MITM-attacks make the news
Our security sucks. Why can't we change? What's wrong with us?
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 17, 2007 07:24 PM
Subject: Our security sucks. Why can't we change? What's wrong with us?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000893.html
as i've periodically mentioned before, we were brought into help word
smith the cal (state) digital signature legislation ... and then later
the federal legistlation
https://www.garlic.com/~lynn/subpubkey.html#signature
as part of that activity we were exposed to some of the
disclosure/notification legislation work going on ... both with regard
to the use of personal information as well as security breaches and
data breaches. a few recent posts in various threads mentioning
notification/disclosures
https://www.garlic.com/~lynn/2007f.html#72
https://www.garlic.com/~lynn/2007f.html#75
https://www.garlic.com/~lynn/2007g.html#8
this somewhat, subsequently also got us roped into co-author of x9.99
financial privacy related standard ... somewhat in support of that
activity i had done a merged privacy taxonomy and glossary
... reference here
https://www.garlic.com/~lynn/index.html#glosnote
and for other topic drift, some other recent threads ... much more on
the integirty and security side of the topic ... as opposed to the
notification/disclosure side of the topic
https://www.garlic.com/~lynn/2007h.html#36
https://www.garlic.com/~lynn/2007h.html#37
and separate part/aspect (which touches slightly more on some of the
business issues) in the same thread
https://www.garlic.com/~lynn/2007h.html#27
https://www.garlic.com/~lynn/2007h.html#28
https://www.garlic.com/~lynn/2007h.html#31
Our security sucks. Why can't we change? What's wrong with us?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 18, 2007 08:06 PM
Subject: Our security sucks. Why can't we change? What's wrong with us?
Blog: Financial Cryptography
recent article from yesterday
Banks must come clean on ID theft
http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2007/04/17/EDGEBOS87H1.DTL
from above:
Two separate studies recently reached conflicting conclusions: While
one found that identity theft is on the rise significantly, the other
reported that it is on the decline.
So which is it?
... snip ...
i had made a similar observation a month ago
https://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007
also referenced here
https://www.garlic.com/~lynn/2007h.html#48 Securing financial transactions a high priority for 2007
previous post in this thread
https://www.garlic.com/~lynn/aadsm26.htm#57
and my oft repeated reference to old post on security proportional to
risk
https://www.garlic.com/~lynn/2001h.html#61
and in some of the existing environments the attackers can possibly
outspend the defenders possibly as much as 100:1
https://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 19, 2007 12:11 PM
Subject: On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000895.html
note that the quote wasn't mine ... i found it in recent (san fran
chronicle) newspaper article titled "Banks must come clean on ID
theft" and posted the reference
https://www.garlic.com/~lynn/2007h.html#48 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/aadsm26.htm#58 Our security sucks. Why can't we change? What's wrong with us?
although I did note that in a couple posts from last month I had
observed the relatively vast differences in various articles on how
recent fraud numbers were interpreted.
https://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#62 Securing financial transactions a high priority for 2007
now today there are references to recent Schneier article:
Bad Security Driving Out the Good
http://it.slashdot.org/it/07/04/19/140245.shtml
How Security Companies Sucker Us With Lemons
http://www.wired.com/politics/security/commentary/securitymatters/2007/04/securitymatters_0419?currentPage=all
and for a little more drift, there is recent thread topic drift
related to nothing succeeds like failure
https://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#33 sizeof() was: The Perfect Computer - 36 bits?
as well as somewhat similar reference in recent risk digest
http://catless.ncl.ac.uk/Risks/24.62.html
crypto component services - is there a market?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: crypto component services - is there a market?
Date: Thu, 19 Apr 2007 18:23:21 -0600
To: stefan.kelm@xxxxxxxx
CC: Cryptography <cryptography@xxxxxxxx>
Stefan Kelm wrote:
Here in Europe, e-invoicing very slowly seems to be
becoming a (or should I say "the"?) long-awaited
application for (qualified) electronic signatures.
Since electronic invoices need to be archived in
most countries some vendors apply time-stamps and
recommend to re-apply time-stamps from time to time.
recent post/thread with some discussion of the business of digital
certificates ... as distinct from either digital and/or electronic
signatures.
https://www.garlic.com/~lynn/2007h.html#28 sizeof() was: The Perfect Computer - 36 bits?
one of the exploits for the "changing" the burden of proof scenario
(mentioned in the above post) ... since the incentive is significant
... is where the merchant produces a digital signature plus
corresponding digital certificate purported to be from the other
party.
the underlying digital signature stuff was designed for providing
authentication and integrity for the transaction. there was never any
provisions for it to ever provide intent and/or handle the situation
of establishing the inverse ... i.e. in traditional digital signature
& digital certificate paradigm ... there is no way of proving what, if
any, digital signature and digital certificate were originally
appended to the transaction/invoice.
this somewhat gets into the area of non-repudiation services (where
some of the trusted time-stamping have periodically wandered into)
... i.e. for individuals, digital signature isn't representative of a
human signature and intent ... it is purely does (what digital
signatures were originally designed for) authentication and integrity.
other parts of the same thread related to digital signatures
https://www.garlic.com/~lynn/2007h.html#20 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#22 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#26 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#27 sizeof() was: The Perfect Computer - 36 bits?
possibly being able to force changing of burden of proof ... is
analogous to some past discussions about "dual-use" attack ... again
where there was possibility of allowing digital signatures to wander
into the arena of human signatures and intent ... a thread that
started in this mailing list
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#27 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
crypto component services - is there a market?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: crypto component services - is there a market?
Date: Fri, 20 Apr 2007 13:46:35 -0600
To: stefan.kelm@xxxxxxxx
CC: Cryptography <cryptography@xxxxxxxx>
re:
https://www.garlic.com/~lynn/aadsm26.htm#60 crypto component services - is there a market
slightly related discussion of x9.59 financial standard protocol
https://www.garlic.com/~lynn/x959.html#x959
supporting hash of invoice in any dispute resolution ... thread from a
couple weeks ago
https://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services
https://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
where the x9.59 transaction is digital signed (and presumably
logged/archived as part of various financial regulations).
In dispute, both parties can produce their version of any invoice
(bill of materials, etc) and differences can be resolved by the hash
included in the signed payment transaction.
In the mid-90s, the x9a10 financial standard working group had been
given the requirement to preserve the integrity of the financial
infrastructure for ALL retail payments. The x9.59 standards work faced
a few issues, including
1) It was starting to dawn that x.509 identity certificates from the
early 90s, frequently overloaded with personal information represented
significant privacy and liability issues. As a result there was move
to digital certificates that contained some sort of indirect (and/or
obfuscated) lookup value ... and were frequently referred to as
relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
however, it was trivial to show that in any situation where the
indirection had to be used for some sort of lookup ... that the public
key could be obtained in the same operation ... making the digital
certificate redundant and superfluous
2) Some of the other digital signed work for financial transactions in
the period ... the appending of a digital certificate to such a
transaction was resulting in two orders magnitude payload and
processing bloat (for something that was redundant and superfluous)
https://www.garlic.com/~lynn/subpubkey.html#bloat
3) The appending of the digital certificate is basically a paradigm
operation that supports distribution of trusted information for
offline operation (the electronic analog of physical credential,
certificate, license, and/or letters of credit/introduction from
sailing ship days and earlier). At the time we were working on x9.59
... there were several claiming that the appending of digital
certificates (to financial transactions) was needed to bring financial
processing into the "modern age". Our reply was that moving from a
fundamentally online infrastructure to an offline paradigm actually
represented a regression of several decades. It was somewhat after
that you started to see work on the rube goldberg OCSP standard.
....
In some respect ... trusted time-stamping is attempting to take the
online financial transaction model where there are frequently strict
regulations about archiving/auditing and extend it to other types of
operations. In the x9.59 financial standard scenario ... the
financial archiving/auditing infrastructure was extended to cover
invoice, bill-of-materials, etc ... but simply adding their hash to
the digital signed financial transaction (and at the same time
avoiding the enormous payload and processing bloat seen in various
other strategies).
Public key encrypt-then-sign or sign-then-encrypt?
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Public key encrypt-then-sign or sign-then-encrypt?
Date: Wed, 25 Apr 2007 17:26:28 -0600
To: cryptography@xxxxxxxx
Mads Rasmussen wrote:
Hugo Krawczyk [1] showed in the symmetric key setting that the
encrypt-then-authenticate was the way to go about securing the integrity
of an encrypted message.
What about the public key setting?
Jee Hea An, Yevgeniy Dodis and Tal Rabin claims that the order doesn't
matter [2]. Encrypt-then-sign or sign-then-encrypt is equally secure.
Is this really true? My feeling was that the principle from Krawczyk's
paper should apply to the public key setting as well.
the discussion in this thread was about potentially long-lived
document contents carrying digital signature for authentication and
integrity. this is a more of a business issue than a traditional
security/confidentiality issue
https://www.garlic.com/~lynn/2007h.html#15 asymmetric cryptography + digital signature
https://www.garlic.com/~lynn/2007h.html#21 asymmetric cryptography + digital signature
the contents plus digital signature might be encrypted for
transmission purposes (or other confidentiality reasons).
one might contend that if the document has to always be kept encrypted
... for confidentiality reasons ... then it might be useful to apply
the digital signature to the encrypted version.
however, if it is a long-term electronic document normally processed
in clear-text ... then clear-text digital signature can be used for
check of integrity and authentication (of the document contents) and
it may only rarely or never require encryption for confidentiality
part of this is that in the symmetric key example ... encryption can
be viewed as doing double duty for confidentiality and integrity
.... with authentication a separate item. in the asymmetric key
scenario, the digital signature is doing double duty for integrity and
authentication ... with (encryption) confidentiality a separate
operation ... in which, also using encryption for integrity can be
viewed as redundant.
Public key encrypt-then-sign or sign-then-encrypt?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Public key encrypt-then-sign or sign-then-encrypt?
Date: Thu, 26 Apr 2007 07:36:00 -0600
To: cryptography@xxxxxxxx
Travis H. wrote:
Also there's a semantic issue; am I attesting to the plaintext,
or the ciphertext? It's possible the difference could be important.
re:
https://www.garlic.com/~lynn/aadsm26.htm#62 Public key encrypt-then-sign or sign-then-encrypt?
there has been sporadic periods/attempts that effectively attempt to
equate "digital signature" with "human signature" ... possibly because
of semantic confusion since both terms contain the word "signature".
This goes beyond digital signature being able to provide integrity and
authentication (i.e. read, understood, approves, authorizes, and/or
agrees).
we saw one such when we were called into help word smith the
cal. state electronic signature (and later federal) legislation.
misc. past posts
https://www.garlic.com/~lynn/subpubkey.html#signature
another scenario that can arise is dual-use attack ... where same
private key is used to both digitally sign in authentication protocol
(i.e. presented with random "challenge" from a server and private key
automatically digitally signs the server presented value; the signing
of the server presented random value is countermeasure to replay
attacks against the server) and in the sense of human signature (read,
understood, approves, authorizes, and/or agrees). The attacker
injects a valid document in lieu of random data in an authentication
protocol that automatically performs digital signatures.
In the 90s, there was some suggestion that possibly a payment protocol
using digital signature ... in a PKI-based paradigm, the consumer
would append a digital certificate indicating their agreement with the
contents of what was being signed (as opposed to pure integrity and
authentication). The choice of the appended digital certificate would
be used to "prove" non-repudiation and subsequently also be the basis
for changing the burden of proof in disputes. Since PKI-based paradigm
don't provide for any integrity mechanism as to what digital
certificate was originally appended ... there was possibly motivation
(in such a PKI-based paradigm) for a relying-party to discover
someplace in the world a copy of a signer's digital certification that
would better suit the relying party's purpose (than the one that the
signer actually appended) ... there would have been significant
financial incentive to the relying party to change the burden of proof
in disputes.
Since that period, the idea of PKI-based paradigms (and/or digital
certificates) being used as basis for non-repudiation has been
severely depreciated.
some of this from security acronym PAIN
P -- privacy (or sometimes CAIN, confidentiality)
A -- authentication
I -- integrity
N -- non-repudiation
encryption provides for privacy/confidentiality ... and
possibly integrity.
digital signature provides for authentication and integrity
at various times in the past, some PKI-based paradigms have attempted
to make claims that digital signatures also imply non-repudiation
... and could equate to imply intent and equivalence with human
signature (read, understood, approves, authorizes and/or aggrees).
past posts mentioning dual-use attack and/or changing burdon-of-proof
https://www.garlic.com/~lynn/aadsm6.htm#nonreput Sender and receiver non-repudiation
https://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#55 MD5 collision in X509 certificates
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/aadsm21.htm#35 [Clips] Banks Seek Better Online-Security Tools
https://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
https://www.garlic.com/~lynn/aadsm23.htm#33 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/aadsm26.htm#60 crypto component services - is there a market?
https://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/2001g.html#59 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/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
https://www.garlic.com/~lynn/2005e.html#41 xml-security vs. native security
https://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#6 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
https://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005o.html#26 How good is TEA, REALLY?
https://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
https://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
https://www.garlic.com/~lynn/2005s.html#52 TTP and KCM
https://www.garlic.com/~lynn/2005v.html#3 ABN Tape - Found
https://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006e.html#8 Beginner's Pubkey Crypto Question
https://www.garlic.com/~lynn/2006s.html#34 Basic Question
https://www.garlic.com/~lynn/2007h.html#28 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007i.html#23 John W. Backus, 82, Fortran developer, dies
Dr Geer goes to Washington
Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 30, 2007 12:12 PM
Subject: Dr Geer goes to Washington
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000903.html
frequently there needs to be a paradigm shift ... i.e. building on
soft limestone or unstable shale ... rather than having a strong
foundation.
i was on a security panel several yrs ago with high-level executives
from major after-market security add-on companies and made the analogy
to the old after-market seatbelt paradigm ... that the only
substantial way of addressing the opportunity is building in integrity
into the underlying foundation ... and stop treating it as an
after-market add-on (after-market add-on was better than nothing
... but it wouldn't be very effective at providing coverage for
substantial portion of the market).
for a little drift ... also the analogy to the naked
transaction/payment paradigm raised here several months ago
https://www.garlic.com/~lynn/subintegrity.html#payments
the current situation might also be compared to medical field where
everything is treatment ... and there exist no preventive care &
procedures (i.e. having clean water can do wonders for illnesses and
death statistics) ... i.e. we are still in the dark ages compareable
to bleeding the patient to let out the evil spirits.
At times, I'm even tempted to compare things to a medical treatment
scenario where the doctor doesn't even bother to examine the patient
... just chooses a treatment at random.
Public key encrypt-then-sign or sign-then-encrypt?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Public key encrypt-then-sign or sign-then-encrypt?
Date: Wed, 02 May 2007 09:29:39 -0600
To: Florian Weimer <fw@xxxxxxxx>
CC: cryptography@xxxxxxxx
Florian Weimer wrote:
With sign, then encrypt, it's also possible that the receiver
decrypts the message, and then leaks it, potentially giving the
impression that the signer authorized the disclosure. There has
been a fair bit of buzz about this confusion. But the lesson from
that seems to be that signature semantics are very hard to agree
upon, and most marginally successful standards sidestep the issue
anyway, acting as a mere transport protocol.
re:
https://www.garlic.com/~lynn/aadsm26.htm#62 Public key encrypt-then-sign or sign-then-encrypt?
https://www.garlic.com/~lynn/aadsm26.htm#63 Public key encrypt-then-sign or sign-then-encrypt?
there is the issue for some kinds of operations of having integral
authentication and integrity .... or integral authentication and
privacy ... or integral privacy and integrity.
so there is the whole issue of semantic confusion with the term
digital signature .... because it contains the word "signature"
... leading to confusion that it might somehow be related to human
signature ... aka things like intent and a human having read,
understood, agrees, approves, and/or authorizes.
on the other hand ... digital signatures can get into various kinds of
dual-use attacks ... when the same private key is being used in a
purely authentication protocol (server sends random data to be
digitally signed ... as countermeasure to replay attack) ... and also
in a authentication+integrity protocol ... where the contents being
digitally signed is presumed to carry some sort of meaning (and that a
digital just happens to be performed ... carries some additional
implication other than authentication+integrity).
there is this slightly x-over thread from sci.crypt
https://www.garlic.com/~lynn/2007i.html#63 public key password authentication
https://www.garlic.com/~lynn/2007i.html#73 public key password authentication
https://www.garlic.com/~lynn/2007i.html#74 public key password authentication
where there is possibly the suggestion that if the only thing being
performed is authentication (and doesn't require either integrity
and/or privacy) ... then possibly a totally different protocol by
utilized (rather than digital signature) ... to help minimize the
apparent extensive (human) confusion where the same technology might
be used for both authentication only operations as well as
authentication plus integrity operations (and where having the word
"signature" in the term also appears to contribute significant
additional confusion).
however, in the x-over thread from sci.crypt ... i mention that if
both authentication and integrity are both required ... that
potentially if they are done as separate operation ... that there can
be (security) openings provided to attackers for things like
man-in-the-middle attacks.
in the "naked" transaction metaphor mentioned in these postings
https://www.garlic.com/~lynn/subintegrity.html#payments
it is possible that if authentication is performed separately from any
integrity provisions applied to the actual transactions ... that it
may be an opening for a man-in-the-middle attack (or other kinds of
attacks)
More Tipping Point evidence - POS vendors sued
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 2, 2007 04:34 PM
Subject: More Tipping Point evidence - POS vendors sued
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000906.html
for some topic drift ... having worked on the original payment gateway
using SSL to "hide" payment related information as fraud
countermeasure (for what has since come to be called electronic
commerce)
https://www.garlic.com/~lynn/subnetwork.html#gateway
but then got involved in x9a10 financial standard working group that
in the mid-90s had been given the requirement to preserve the
integrity of the financial infrastructure for all retail payments.
https://www.garlic.com/~lynn/x959.html#x959
one of the things looked at in x9a10 is defining x9.59 financial
standard protocol to eliminate risk/fraud associated with exposure of
things like account numbers, expiration dates, etc. recent post noting
that eliminating the risk associated with exposing account numbers and
expiration dates ... somewhat obsoleted the earlier work on electronic
commerce that used SSL cryptography to hide the same information.
https://www.garlic.com/~lynn/2007i.html#65
which also goes back to long series of posts started here with regard
to the naked payment/transaction metaphor (i.e. naked transactions
tend to require quite a bit more hiding and protection than
transactions that are more robust and armored)
https://www.garlic.com/~lynn/subintegrity.html#payments
then there is the somewhat related recent posts that somewhat raises
the question whether or not some of the fraud problems is because of
semantic confusion attempting to understand what various security
procedures actually accomplish
https://www.garlic.com/~lynn/2007i.html#74
https://www.garlic.com/~lynn/aadsm26.htm#65
survey of RFC S/MIME signature handling
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 5, 2007 10:14 AM
Subject: survey of RFC S/MIME signature handling
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000905.html
when we were asked in to help word smith the cal state (and later
federal) electronic signature act ... the lawyers had quite a bit to
say about this ... some past posts
https://www.garlic.com/~lynn/subpubkey.html#signature
i've joked that it involves the (caused by) semantic confusion because
the terms "digital signature" and "human signature" both contain the
word "signature"
the whole idea that past certification events has anything to do with
(future) intent, non-repudiation, and/or human signature (i.e. read,
understood, agrees, approves, and/or authorizes) has been severely
depreciated since the heyday of the enormous (semantic) confusion if
the 90s.
furthermore, it can be considered that even bringing up anything to do
with non-repudiation, intent, and human signature in
conjunction with issuing a digital certificate is enormous
misdirection and obfuscation.
the issue of certification authorities, certification process, and
digital certificates are analogous to the letters of
credit/introduction from the sailing ship days (and before) when the
relying party had no other means of obtaining information about the
party/stranger they were dealing with. in those days, relying parties
realized that the letter of introduction might have something to do
with the truth of what a stranger might possibly claim. However, the
letter of introduction was specifically with respect to specific facts
that were verified at the time the letter was written.
There was NEVER any implication that the act of certifying information
included in the letter of introduction was in any way associated with
the subject's subsequent human signature that carried with it any
implication of intent, non-repudiation, read, understood, agrees,
approves, and/or authorizes.
In fact, it was physically and temporal impossibility that the act of
certifying some information at some point distant in the past had any
bearing on the future human act of applying a (human) signature.
Subsequent work (after the 90s) in the area of intent,
non-repudiation, having read, understood, agrees, approves, and/or
authorizes ... all revolved around services that happened at the
moment a signature was applied ... somewhat equivalent to having
"witnesses" involved in the signing of a will (and severely
depreciated any possible prior work in relating any past work of
certification authorities to any future demonstration of intent).
In this subsequent work, there was nobody confused that the act of
certification at some point in the past (which is what a digital
certificate represents) .... was in any possible way related to the
conditions around the future application of a signature. This would be
on par with trying to make some connection between the issuance of a
birth certificate being related to proving that some person had
intended to sign a specific will. Part of the issue is that the two
events; some certification and some signing (demonstrating read,
understood, agrees, approves, and/or authorizes), are typically
separated by quite a distance ... both physically and temporally.
H6.1: Designing (Security) Without Requirements is like Building a Road Without a Route Map to a Destination You've Never Seen
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 5, 2007 10:45 AM
Subject: H6.1: Designing (Security) Without Requirements is like Building a Road Without a Route Map to a Destination You've Never Seen
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000910.html
should i say pet-peeve?
the other aspect is not having done a detailed end-to-end threat and
vulnerability analysis and then (not) stating exactly what is trying to be
accomplished ... it is tempted to make a statement with regard to not
knowing something ... that they don't even know that they don't
know. related post about not knowing what they don't know
https://www.garlic.com/~lynn/aadsm26.htm#64 Dr Geer goes to Washington
not only is there the requirement to know what route the road is to
transverse ... but there is a requirement to have detailed knowledge
of the conditions involved in the route as well as what traffic the
road is to carry.
for instance ... is part of the route subject to frost heaves ... and
are specific countermeasures necessary. past post discussing frost
heaves affecting road construction requirements:
https://www.garlic.com/~lynn/99.html#22 Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
https://www.garlic.com/~lynn/2002i.html#28 trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#35 pop density was: trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#36 pop density was: trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002j.html#42 Transportation
https://www.garlic.com/~lynn/2002j.html#68 Killer Hard Drives - Shrapnel?
https://www.garlic.com/~lynn/2003j.html#11 Idiot drivers
https://www.garlic.com/~lynn/2006h.html#45 The Pankian Metaphor
another part of road construction is knowing what kind of traffic will
be involved ... for instance past posts discussing that road lifetime
construction considerations are related to ton/axle loads for heavy
trucks (traffic from automobiles and light trucks can be ignored)
... long winded past thread exploring the subject of heavy truck
axle-load traffic affecting road construction
https://www.garlic.com/~lynn/2006g.html#5 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#6 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#10 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#12 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#15 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#19 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#26 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#32 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#35 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#46 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#49 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#53 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#54 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#5 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#6 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#23 The Pankian Metaphor
survey of RFC S/MIME signature handling
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 5, 2007 02:28 PM
Subject: survey of RFC S/MIME signature handling
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm26.htm#67 survey of RFC S/MIME signature handling
or to be (only slightly) more facetious ... require that all birth
certificates to carry a disclaimer that the document in no way is met
to carry any implication as to the validity of any signatures that the
named person may place on wills (at any time in the future). the birth
certificate disclaimer then would have to be extended to include the
enumeration of all possible documents on which a person might place
their signature.
WSJ: Soft evidence on a crypto-related breach
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 7, 2007 05:47 PM
Subject: WSJ: Soft evidence on a crypto-related breach
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000911.html
aside from the issues AADS and X9.59 financial standard protocol
https://www.garlic.com/~lynn/x959.html
providing transaction armoring for naked transactions
https://www.garlic.com/~lynn/subintegrity.html#payments
so they are no longer vulnerable to evesdropping and
replay attacks
https://www.garlic.com/~lynn/subintegrity.html#harvest
there is this recent item:
New Weakness in 802.11 WEP
http://developers.slashdot.org/developers/01/07/27/1734259.shtml?tid=93
which claims that it has an attack against what is being proposed for WEP2.
the referenced website:
http://ebiquity.org/article.php?sid=189
may be suffering from having been "slashdot'ed" ... since it hasen't
been responding.
AADS Postings and Posting Index,
- previous
- next
- home