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:
http://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
http://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.
http://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)
http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
http://www.garlic.com/~lynn/aadsm12.htm#26 I-D ACTION:draft-ietf-pkix-usergroup-01.txt
http://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
http://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#5 OCSP and LDAP
http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda)
http://www.garlic.com/~lynn/aadsm16.htm#22 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
http://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
http://www.garlic.com/~lynn/aadsm17.htm#53 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#4 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm19.htm#8 GeoTrust says existing PKI practices are worthless
http://www.garlic.com/~lynn/aadsm20.htm#33 How many wrongs do you need to make a right?
http://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on high-assurance certificates
http://www.garlic.com/~lynn/aadsm21.htm#36 browser vendors and CAs agreeing on high-assurance certificates
http://www.garlic.com/~lynn/aadsm23.htm#1 RSA Adaptive Authentication
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
http://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003b.html#50 Authentication w/o user ids and passwords
http://www.garlic.com/~lynn/2003l.html#33 RSA vs AES
http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2004b.html#25 Who is the most likely to use PK?
http://www.garlic.com/~lynn/2004b.html#52 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004e.html#20 Soft signatures
http://www.garlic.com/~lynn/2004h.html#52 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#2 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
http://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2005e.html#62 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#13 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#24 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005k.html#29 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#1 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#11 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#21 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#23 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
http://www.garlic.com/~lynn/2005l.html#33 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005o.html#40 Certificate Authority of a secured P2P network
http://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2005t.html#0 TTP and KCM
http://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#39 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#28 confidence in CA
http://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
http://www.garlic.com/~lynn/aadsm25.htm#43

a cross over postings mentioning sox
http://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
http://www.garlic.com/~lynn/2006u.html#40 New attack on the financial PIN processing
http://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
http://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:
http://www.garlic.com/~lynn/aadsm26.htm#4 Citibank e-mail looks phishy

and as referred to here
http://www.garlic.com/~lynn/2006u.html#42 New attacks on the financial PIN processing

x9.59 protocol
http://www.garlic.com/~lynn/x959.html#x959
http://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).
http://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
http://www.garlic.com/~lynn/2006u.html#40 New attack on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#43 New attack on the financial PIN processing

past posts in this thread
http://www.garlic.com/~lynn/aadsm26.htm#3 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/aadsm26.htm#4 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/aadsm26.htm#5 ATMs harcked using MP3 player

couple more in sci.crypt thread:
http://www.garlic.com/~lynn/2006u.html#47 New attack on the financial PIN processing
http://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
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
http://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?
http://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
http://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
http://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
http://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
http://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt
http://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues
http://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
http://www.garlic.com/~lynn/aadsm17.htm#38
Leading Cause of Data Security breaches Are Due to Insiders
http://www.garlic.com/~lynn/aadsm18.htm#49
Bank workers biggest ID theft threat
http://www.garlic.com/~lynn/2005l.html#35
other insider threat
http://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
http://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
http://www.garlic.com/~lynn/aadsm26.htm#6
http://www.garlic.com/~lynn/2006v.html#1
http://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
http://www.garlic.com/~lynn/2006u.html#56

in this post
http://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible

or this archeological reference
http://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
http://www.garlic.com/~lynn/2006u.html#45

and then a few items referencing what went on in the mid-90s
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#7 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm20.htm#9 the limits of crypto and authentication

and then old public key archeological reference from mid-80s
http://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications and even this older public key archeological reference form 1981
http://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:
http://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visiable?
http://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?

misc. (other archeological) posts to/referencing set-discuss forum
http://www.garlic.com/~lynn/aadsm2.htm#storage Storage of Certificates
http://www.garlic.com/~lynn/aadsmore.htm#setjava javasoft SET - NO!
http://www.garlic.com/~lynn/aepay3.htm#disputes Half of Visa's disputes, fraud result from I-commerce (more)
http://www.garlic.com/~lynn/aepay4.htm#comcert3 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#comcert5 Merchant Comfort Certificates
http://www.garlic.com/~lynn/aepay4.htm#3dssl VISA 3D-SSL
http://www.garlic.com/~lynn/aepay6.htm#ecomich call for new measures: ICH would be glad to help
http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aepay10.htm#26 Definese Dept Criticised on Internal Credit Card Fraud
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://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:
http://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?
http://www.garlic.com/~lynn/2001h.html#61

and then there are a couple recent posts about insider threats
http://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
http://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:
http://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/aadsm26.htm#10 Who has a Core Competency in Security?
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

and some of the posts in this blog on yes card exploits
http://www.garlic.com/~lynn/subintegrity.html#yescard

or the naked payments (and related) threads
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#8 Microsoft - will they bungle the security game?
http://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#21 Use of TPM chip for RNG?
http://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#25 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#27 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#37 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
http://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?
http://www.garlic.com/~lynn/aadsm24.htm#43 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
http://www.garlic.com/~lynn/aadsm25.htm#1 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#4 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#9 DDA cards may address the UK Chip&Pin woes
http://www.garlic.com/~lynn/aadsm25.htm#10 Crypto to defend chip IP: snake oil or good idea?
http://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
http://www.garlic.com/~lynn/aadsm25.htm#25 RSA SecurID SID800 Token vulnerable by design
http://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
http://www.garlic.com/~lynn/aadsm25.htm#38 How the Classical Scholars dropped security from the canon of Computer Science
http://www.garlic.com/~lynn/aadsm26.htm#6 Citibank e-mail looks phishy

Who has a Core Competency in Security?

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
http://www.garlic.com/~lynn/aepay3.htm#riskm
http://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
http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
http://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
http://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
http://www.garlic.com/~lynn/rfcidx15.htm#4772

from
http://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
http://www.garlic.com/~lynn/rfcidx15.htm#4732

Changing the Mantra -- RFC 4732 on rethinking DOS

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
http://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)
http://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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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:
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://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?)
http://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2006e.html#11 Caller ID "spoofing"
http://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
http://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?

and other references mentioning distributed operation
http://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core?
http://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
http://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:
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
http://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):
http://www.garlic.com/~lynn/2007.html#7 SSL info
http://www.garlic.com/~lynn/2007.html#15 SSL info
http://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
http://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
http://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:
http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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:
http://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
http://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
http://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)
http://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:
http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
http://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
http://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
http://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)
http://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
http://www.garlic.com/~lynn/aadsm26.htm#18 SSL (https, really) accelerators for Linux/Apache?

one of the things looked at for X9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://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
http://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
http://www.garlic.com/~lynn/aadsm26.htm#20 Tamperproof, yet playing Tetris

recent related comments
http://www.garlic.com/~lynn/aadsm26.htm#21 FC07 Preliminary Programme - Leaving Room for the Bad Guys

and a whole lot of past comments
http://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
http://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
http://www.garlic.com/~lynn/subtopic.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.
http://www.garlic.com/~lynn/96.html#24 old manuals
http://www.garlic.com/~lynn/2004g.html#45 command line switches
http://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
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm

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.
http://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.
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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 unuseable for exploists)
http://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
http://www.garlic.com/~lynn/subintegrity.html#yescard

somewhat related posts in this thread:
http://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#46 Securing financial transactions a high priority for 2007
http://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
http://www.garlic.com/~lynn/2001h.html#61

misc. past posts with reference to FSTC's FAST
http://www.garlic.com/~lynn/99.html#171 checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/99.html#216 Ask about Certification-less Public Key
http://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
http://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
http://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
http://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
http://www.garlic.com/~lynn/aadsm16.htm#5 DOD prepares for credentialing pilot
http://www.garlic.com/~lynn/aadsm17.htm#19 PKI International Consortium
http://www.garlic.com/~lynn/2005i.html#33 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#42 More Phishing scams, still no SSL being used
http://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
http://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
http://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"

and misc. past posts mentioning mitm-attacks
http://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
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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
http://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
http://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:
http://www.garlic.com/~lynn/aadsm20.htm#33 How many wrongs do you need to make a right?
http://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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
http://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 ...
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://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
http://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 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:
http://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"?
http://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007

lots of past posts mentioning MITM-attacks
http://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
http://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:
http://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
http://www.garlic.com/~lynn/subpubkey.html#catch22

For other topic drift ... a recent post/comment about the early x.500 stuff
http://www.garlic.com/~lynn/2007b.html#31 IBMLink 2000 Finding ESO levels

and recent posts with comments about early x.509 identity certificate stuff
http://www.garlic.com/~lynn/2007.html#15 SSL info
http://www.garlic.com/~lynn/2007.html#17 SSL info
http://www.garlic.com/~lynn/2007.html#34 SSL info
http://www.garlic.com/~lynn/2007.html#42 The logic of privacy
http://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
http://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:
http://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
http://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
http://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
http://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
http://www.garlic.com/~lynn/subpubkey.html#certless
.... also the reference from 1981
http://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
http://www.garlic.com/~lynn/x959.html#x959
http://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:
http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL

and recent post/thread from early last month on the subject
http://www.garlic.com/~lynn/2007b.html#53
http://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
http://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"?
http://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007

misc. past posts mentioning man-in-the-middle attacks
http://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