Misc AADS & X9.59 Discussions


AADS Postings and Posting Index,
previous - next - home


Flaw in RFID-enabled passports (part 2?)
Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
Citibank e-mail looks phishy
Citibank e-mail looks phishy
ATMs hacked using MP3 player
Citibank e-mail looks phishy
Citibank e-mail looks phishy
What is the point of encrypting information that is publicly visible?
Who has a Core Competency in Security?
Who has a Core Competency in Security?
What is the point of encrypting information that is publicly visible?
Who has a Core Competency in Security?
Who has a Core Competency in Security?
Who has a Core Competency in Security?
Who has a Core Competency in Security?
Security Implications of Using the Data Encryption Standard (DES)
Changing the Mantra -- RFC 4732 on rethinking DOS
SSL (https, really) accelerators for Linux/Apache?
Non-repudiation, Evidence and TLS: another fine mess I've got you into :-(
Tamperproof, yet playing Tetris
FC07 Preliminary Programme - Leaving Room for the Bad Guys
Tamperproof, yet playing Tetris
It's a Presidential Mandate, Feds use it. How come you are not using FDE?
News.com: IBM donates new privacy tool to open-source Higgins
EV - what was the reason, again?
man in the middle, SSL
man in the middle, SSL ... addenda
man in the middle, SSL
News.com: IBM donates new privacy tool to open-source Higgins
man in the middle, SSL
man in the middle, SSL ... addenda 2
Failure of PKI in messaging
Failure of PKI in messaging ... addenda
Failure of PKI in messaging
Failure of PKI in messaging
New Credit Cards May Leak Personal Information
Threatwatch: $400 to 'own' your account
Usable Security 2007
Usable Security 2007
PKI: The terrorists' secret weapon
PKI: The terrorists' secret weapon (part II)
"Dilemmas of Privacy and Surveillance" report launched
Cost of an identity
Governance of anonymous financial services
Cost of an identity
The Founder Paradox
SSL MITM-attacks make the news
Governance of anonymous financial services
Governance of anonymous financial services
DNSSEC to be strangled at birth
The One True Identity -- cracks being examined, filled, and rotted out from the inside
The One True Identity -- cracks being examined, filled, and rotted out from the inside
The One True Identity -- cracks being examined, filled, and rotted out from the inside
What to do about responsible disclosure?
The One True Identity -- cracks being examined, filled, and rotted out from the inside
Threatwatch: MITB spotted: MITM over SSL from within the browser
Our security sucks. Why can't we change? What's wrong with us?
Our security sucks. Why can't we change? What's wrong with us?
On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?
crypto component services - is there a market?
crypto component services - is there a market?
Public key encrypt-then-sign or sign-then-encrypt?
Public key encrypt-then-sign or sign-then-encrypt?
Dr Geer goes to Washington
Public key encrypt-then-sign or sign-then-encrypt?
More Tipping Point evidence - POS vendors sued
survey of RFC S/MIME signature handling
H6.1: Designing (Security) Without Requirements is like Building a Road Without a Route Map to a Destination You've Never Seen
survey of RFC S/MIME signature handling
WSJ: Soft evidence on a crypto-related breach


Flaw in RFID-enabled passports (part 2?)

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Flaw in RFID-enabled passports (part 2?)
Date: Thu, 09 Nov 2006 12:20:31 -0700
To: cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm25.htm#46 Flaw exploited in RFID-enabled passports

Budapest Declaration on Machine Readable Travel Documents (MRTDs)
http://www.fidis.net/home/single-news/article/budapest-declaration-on-machine-readable-travel-documents-mrtds-2/?tx_ttnews%5BbackPid%5D=4&cHash=fe8718735f

from above:
By failing to implement an appropriate security architecture, European governments have effectively forced citizens to adopt new international Machine Readable Travel Documents which dramatically decrease their security and privacy and increases risk of identity theft. Simply put, the current implementation of the European passport utilises technologies and standards that are poorly conceived for its purpose. In this declaration, researchers on Identity and Identity Management (supported by a unanimous move in the September 2006 Budapest meeting of the FIDIS "Future of Identity in the Information Society" Network of Excellence) summarise findings from an analysis of MRTDs and recommend corrective measures which need to be adopted by stakeholders in governments and industry to ameliorate outstanding issues.

... snip ...

and

RFID Passport Security 'Poorly Conceived'
http://it.slashdot.org/it/06/11/09/1757202.shtml

the above also references

Feds Leapfrog RFID Privacy Study
http://www.wired.com/news/technology/1,72019-0.html

from above:
The story seems simple enough. An outside privacy and security advisory committee to the Department of Homeland Security penned a tough report concluding the government should not use chips that can be read remotely in identification documents. But the report remains stuck in draft mode, even as new identification cards with the chips are being announced.

... snip ...

The Use of RFID for Human Identification; A DRAFT REPORT from DHS Emerging Applications and Technology Subcommittee
http://www.dhs.gov/xlibrary/assets/privacy/privacy_advcom_rpt_rfid_draft.pdf

Extended Validation - setting the minimum liability, the CA trap, the market in browser governance

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 12, 2006 05:42 PM
Subject: Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000835.html

there are several other disconnects between ssl domain name certificates and the infrastructure .... the primary use of ssl and e-commerce
https://www.garlic.com/~lynn/subpubkey.html#sslcert


1) one of the things that ssl domain name certificates were countermeasure to ip-address hijacking ... namely that the URL that the user entered got them to the correct web site ... and the website they thought they were talking to, was in fact, the website they were talking to.

the chain of trust then had certification authorities, certifying that the certified public key actually belonged to the owner of the specific domain name (that would be used in the url).

the first disconnect came when e-commerce sites figured out that using SSL consumed 80-90 percent of their capacity and started relegating SSL to purely check-out/purchase phase. The user now clicks on a button (from the website) that automatically supplies a URL ... which is then verified by a certificate (also supplied by the website). This creates a break in the chain of trust, since the URL originally provided by the user is no longer being verified.

the next disconnect came with the wide-spread adoption of users purely clicking on all sorts of buttons and field ... hardly ever actually manually entering a URL themselves. this has shown up in various kinds of phishing and spam attacks where users are requested to click on an email field that purports to represent some URL ... but in fact, may take the user to a fraudulent website (which can include man-in-the-middle attacks).

part of the financial disconnect has been that e-commerce has been extremely skewed. the large sites are extremely well known as are their URL(s); and they do the majority of the transactions. its is the millions of merchants that only do a few transactions where there is the greatest risk (but they can't justify a costly extraneous expense).

the merchants are also already paying premium to insure consumer credit card transactions. the issue for SSL domain name certificates is what additional benefit would they provide to anybody, that would justify paying a lot more money (other than well publicized campaign where consumers feel greater comfort when SSL is used, aka the merchant comfort certificates). To some extent certificate authorities are competing with credit card interchange fees that is already covering fraud exposure to consumers (bad things happening).


2) another issue with the ssl domain name certificates, is that the certification authorities have to resort to verifying the domain name owner with the authoritative agency for domain name ownership, which turns out to be the domain name infrastructure ... the agency that also has various possible integrity issues ... like ip-address hijacking, which is one of the original justifications for having ssl domain name certificates.

another integrity issue with domain name infrastructure is domain name hijacking vulnerabilities. having various vulnerabilities with the authoritative agencies responsible for the information that certification authorities are certifying ... can result in the certification authorities performing one hundred percent and still certifying erroneous information.

so, somewhat with the backing of the certification authority industry, there is proposal that all domain name owners register a public key as part of their domain name registration. this can close some number of vulnerabilities for domain name infrastructure (like ip-address and domain name hijacking), improving the integrity of the domain name infrastructure.

the certification authorities currently have an expensive, time-consuming and error prone process where they require a SSL domain name application to provide a lot of identification which they then have to try and match with the identification information on file (for the domain name owner) with the domain name infrastructure. going to onfile public keys, the certification authorities can require that SSL domain name certificate applications be digitally sign. Then the certification authority can do a real-time retrieval of the onfile public key to verify the digital signature (replacing an expensive, time-consuming and error prone identification process with a much simpler, less expensive, and reliable authentication process).

the problem is that the onfile public keys represent a catch-22 for the certification authorities. improving the integrity of the domain name infrastructure, decreases the original justification for having ssl domain name certificates. also allowing anybody to do real-time retrieval of onfile public keys means that general public could authenticate websites directly without requiring digital certificates at all.
https://www.garlic.com/~lynn/subpubkey.html#catch22


3) business model that is out of synch with traditional business processes. normally a relying party has a contract with an authoritative party where they pay directly for the services they receive (exchange of value). in the standard 3rd party certification authority business operation, the certification authority sells a certificate to an key-owner/end-user (and NOT the relying party). The relying party then has absolutely no relationship contractual, implied, or any other way) with the certification authority and/or any obligations related to the certification authorities duties.

The Federal PKI project somewhat dealt with this aspect by having the GSA (acting on behalf of the federal gov. agencies that would be relying parties) sign a contract with all "authorized" certification authorities (creating a contractual obligation between the relying parties and the certification authorities).

in the ssl domain name certificate infrastructure scenario, this would imply having every possible consumer/client (hundreds of millions or even billions) sign a contract with every possible certification authority (at least tens). the business plan of selling ssl domain name certificates to a few million merchant sites would be totally swamped by the costs of having to deal with tens of billions of individual consumer contracts (with the consumer as a relying party).


4) advent of ubiquitous online connectivity. the primary design point for digital certificates were in offline environments, analogous to letters of credit/introduction from sailing ship (and earlier) days ... where the relying party lacked any ability to directly access the responsible or authoritative agency. digital certificates designed for offline operation can become quickly obsoleted when the relying parties have direct, real-time access to the responsible authoritative agencies (like possibly being able to do real-time retrieval of onfile public keys from the domain name infrastructure OR real-time payment card authorization).

this has somewhat pushed digital certificates into the low/no value market segment where relying parties can't justify the expense of real-time operation for whatever business operation they are involved in. however, with the rapidly declining costs of data processing and online access, the places where relying parties can't justify real-time, online operation is also shrinking/declining. it is quickly becoming an extremely small no-value operation that can't justify real-time, online access.

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

Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 13, 2006 11:00 AM
Subject: Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates...
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000819.html
https://www.garlic.com/~lynn/aadsm25.htm#43

a cross over postings mentioning sox
https://www.garlic.com/~lynn/2006u.html#22 AOS: The next big thing in data storage

and other recent items:
Cheney Expresses Doubts About Sarbanes-Oxley
http://www.informationweek.com/showArticle.jhtml?articleID=193500718
Democrat Says Sarbanes-Oxley Already Being Thinned
http://www.baselinemag.com/article2/0,1540,2050437,00.asp
NY leaders see city's financial position threatened
http://money.cnn.com/2006/11/01/markets/bc.financial.newyork.politicians.reut/
Sarbanes-Oxley overkill, bankers say
http://www.newsobserver.com/104/story/504970.html
Lights Dimming On The Sarbanes Oxley Act?
http://www.crn.com/showArticle.jhtml?articleID=193700543
Greenspan calls SarBox a nightmare
http://weblog.infoworld.com/techwatch/archives/008823.html

Citibank e-mail looks phishy

Subject: Re: Citibank e-mail looks phishy
Date: Mon, 13 Nov 2006 12:36:22 -0700
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Perry E. Metzger <perry@xxxxxxxx>
CC: Peter Gutmann <pgut001@xxxxxxxx>,
Carlos.Cid@xxxxxxxx,  cryptography@xxxxxxxx
... and the situation can in turn be aggravated by ....

NatWest shuns ID fraud victims
http://business.timesonline.co.uk/article/0,,9558-2449436,00.html

from above ...
Other types of fraud are on the rise, too. New figures from Apacs show a dramatic rise in the number of 'phishing' incidents, where scammers send out an e-mail purporting to be from a consumer's bank and asking them to type in their account details.

... snip ...

Citibank e-mail looks phishy

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: James A. Donald <jamesd@xxxxxxxx>
Subject: Re: Citibank e-mail looks phishy
Date: Wed, 15 Nov 2006 16:15:12 -0700
CC: Leichter, Jerry <leichter_jerrold@xxxxxxxx>,
Perry E. Metzger <perry@xxxxxxxx>,  cryptography@xxxxxxxx
James A. Donald wrote
The failures of high finance are more subtle. They push the boundaries of what people can easily comprehend. Not one person in a thousand - no regulators, and not many accountants, understand what went wrong with Enron, though quite a lot of investors and creditors understand.

the straight-forward ones are not too bad ... they just require somebody to understand the infrastructure and to do a detailed vulnerability analysis. the more complex ones are systemic failures ... which can happen in complex, interconnected infrastructures .... whether it is financial infrastructure or the power grid ... or some of the PKI-based scenarios (things that might be considered relatively minor failures, cascade and pull down the whole infrastructure).

some of the straight-forward ones can also happen because of infrastructure and/or paradigm changes ... and there wasn't any forward thinking.

recent thread today in sci.crypt
https://www.garlic.com/~lynn/2006u.html#40 New attack on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#43 New attack on the financial PIN processing

there is reference to chip&pin and the YES CARD exploit
https://www.garlic.com/~lynn/subintegrity.html#yescard

as referenced, the x9a10 financial standard group was formed to work on x9.59 standard (and given the requirement to preserve the integrity of the financial infrastructure for all retail payments) in the same time frame that work started on chip&pin. chip&pin appeared to come out with a solution that addressed lost/stolen (magstripe) card. however, in the decade preceding that work, there was a big increase in skimming/harvesting static authentication data for the production of counterfeit cards.

there was already a partial countermeasure for lost/stolen card ... that was notifying the issuer and getting the account flagged. however, skimming, harvesting, and/or data breaches involving static authentication information was a much more difficult problem ... since it typically wasn't evident to the card owner that it has happened (and most indications would only be there when the fraudulent transactions started showing up)

so not too long after chip&pin deployments in the 90s, YES CARD exploits started appearing. some have even claimed that chip&pin actually made the situation worse vis-a-vis magstripe card ... because a chip was allowed to tell a terminal to do offline transactions (which a counterfeit YES CARD would always do) ... which negated the countermeasure of flagging the account (since a real time transaction wasn't being done, by the time a terminal found out that an account was flagged, it was way too late).

ATMs hacked using MP3 player

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: ATMs hacked using MP3 player
Date: Wed, 15 Nov 2006 16:51:40 -0700
To: cryptography@xxxxxxxx
and one more skimming attack

ATMs hacked using MP3 player
http://news.com.com/2061-10789_3-6135905.html

from above:
The gang targeted freestanding cash dispensers and would tap the phone line between the ATM and a wall socket by placing a two-way adaptor on it and connecting an MP3 player, according to the newspaper.

... snip ...

just another in long history of skimming/harvesting of static authentication information

somewhat related:
https://www.garlic.com/~lynn/aadsm26.htm#4 Citibank e-mail looks phishy

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

x9.59 protocol
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

attempted to address the whole problem of attackers acquiring (sensitive) static authentication information ... regardless of method, harvesting, skimming, data breaches, phishing, whatever ... effectively for use in any form of replay attack.

the design of the x9.59 protocol also attempted to address numerous possible man-in-the-middle attacks ... which still might occur even when switching from static authentication data to dynamic authentication data i.e. the authentication has to be part of the transaction itself ... as opposed to any separate operation (which could possibly open up cracks for man-in-the-middle attacks).
https://www.garlic.com/~lynn/subintegrity.html#mitm

Citibank e-mail looks phishy

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Citibank e-mail looks phishy
Date: Thu, 16 Nov 2006 07:45:08 -0700
To: cryptography@xxxxxxxx
CC: James A. Donald <jamesd@xxxxxxxx>,
    Leichter, Jerry <leichter_jerrold@xxxxxxxx>,
Perry E. Metzger <perry@xxxxxxxx>,
Anne & Lynn Wheeler wrote
some of the straight-forward ones can also happen because of infrastructure and/or paradigm changes ... and there wasn't any forward thinking.

recent thread today in sci.crypt
https://www.garlic.com/~lynn/2006u.html#40 New attack on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#43 New attack on the financial PIN processing


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

couple more in sci.crypt thread:
https://www.garlic.com/~lynn/2006u.html#47 New attack on the financial PIN processing
https://www.garlic.com/~lynn/2006u.html#48 New attack on the financial PIN processing

elsewhere in the "PIN processing" thread somebody mentions that ATM standards require encryption for the PIN but not the rest of the message. This could be considered sufficient prior to the introduction of signature-debit ... since up until that time, all debit transactions required the associated PIN.

However, the introduction of signature-debit makes the rest of the (unencrypted) message attractive targets, since attackers can skim the information and create counterfeit cards and use them in (PINless) signature-debit transactions.

or can you say security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

or using the "naked payments" metaphor, consistent requirement for a debit transaction to have a PIN ... and the PIN was given at least some level of protection ... would imply that the payment transaction had some degree of armoring ... which eliminated the rest of the transaction as useful to the attacker (and therefor didn't need encryption since it wasn't sufficient to perform fraudulent transactions). With the introduction of signature-debit, it removes the transaction armoring and creates a vulnerability for the rest of the transaction information (the armoring of the transaction information was removed, leaving it naked and exposed, making the information vulnerable to skimming, harvesting, data breach, etc attacks).

as mentioned numerous times in the past, the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

part of the standard was to specify an environment were the transactions were always consistently armored and never left naked and vulnerable. misc. past posts mentioning the naked payment/transaction metaphor
https://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
https://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#9 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#12 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#14 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#22 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#26 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#30 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#31 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#32 DDA cards may address the UK Chip&Pin woes
https://www.garlic.com/~lynn/aadsm24.htm#38 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#41 Naked Payments IV - let's all go naked
https://www.garlic.com/~lynn/aadsm24.htm#42 Naked Payments II - uncovering alternates, merchants v. issuers, Brits bungle the risk, and just what are MBAs good for?
https://www.garlic.com/~lynn/aadsm24.htm#46 More Brittle Security -- Agriculture
https://www.garlic.com/~lynn/aadsm25.htm#20 Identity v. anonymity -- that is not the question
https://www.garlic.com/~lynn/aadsm25.htm#28 WESII - Programme - Economics of Securing the Information Infrastructure
https://www.garlic.com/~lynn/2006m.html#15 OpenSSL Hacks
https://www.garlic.com/~lynn/2006m.html#24 OT - J B Hunt
https://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006o.html#40 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006t.html#40 Encryption and authentication

Citibank e-mail looks phishy

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Citibank e-mail looks phishy
Date: Thu, 23 Nov 2006 09:23:51 -0700
To: cryptography@xxxxxxxx
and now for some different threat vector:

Banks face growing threat of identity theft from insiders
http://news.com.com/Banks+face+growing+threat+of+identity+theft+from+insiders/2100-1029_3-6137940.html

from above:
Banks are pouring money into building formidable defenses against computer hackers, but are only just waking up to what may be a bigger threat--the physical theft of client information by people in the office.

.... snip ...

it isn't exactly new news ... insiders have always been considered the major threat ... whether it is physical theft or various kinds of electronic data breaches and/or security breaches.

misc. past items ...

Study: ID theft usually an inside job
https://www.garlic.com/~lynn/aadsm17.htm#38
Leading Cause of Data Security breaches Are Due to Insiders
https://www.garlic.com/~lynn/aadsm18.htm#49
Bank workers biggest ID theft threat
https://www.garlic.com/~lynn/2005l.html#35
other insider threat
https://www.garlic.com/~lynn/2006p.html#9

i've frequently commented in the past that the stuff about external threats that make the popular press has frequently obfuscated the source of the major threats (for all i know, insider attacks may even take advantage of the added confusion and ambiguity introduced by the prospect of internet-based attacks).

What is the point of encrypting information that is publicly visible?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 24, 2006 05:36 PM
Subject: What is the point of encrypting information that is publicly visible?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000839.html

PAIN security acronym:

P ... privacy (sometimes CAIN & confidentiality)
A ... authentication
I ... integrity
N ... non-repudiation


original (and possibly still one of the major) use for SSL was hiding account numbers as part of e-commerce ... long winded archeological reference
https://www.garlic.com/~lynn/2006u.html#56

a large part of the issue with account numbers is diametrically opposing requirements.

frequently, just knowledge of account numbers can effectively be used in various kinds of replay attacks for fraudulent transactions ... resulting in the requirement for account numbers to be kept confidential and never divulged.

at the same time, account numbers are required in scores of business processes, and as such, are required to be readily available. my oft repeated comment is that as a result of the diametrically opposing requirements, the planet could be buried under miles of encryption and still be unable to prevent account number leakage.

somewhat related thread
https://www.garlic.com/~lynn/aadsm26.htm#6
https://www.garlic.com/~lynn/2006v.html#1
https://www.garlic.com/~lynn/2006v.html#2

as mentioned in the above, the x9.59 financial standard changed the paradigm ... eliminating the requirement for keeping account number confidential ... effectively by using (consistently applying end-to-end) authentication and integrity for security ... as part of "armoring" all transactions (instead of privacy/confidentiality to achieve security, authentication and integrity was used for security).

of course, part of this was studying what the threats were and why ... and creating countermeasures for the actual threats.

Who has a Core Competency in Security?

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 25, 2006 11:41 AM
Subject: Who has a Core Competency in Security?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000840.html

byte my tongue? ... well it has been 10plus years

IBM was/is a very large company with a very broad range of people.

for instance this archeological reference
https://www.garlic.com/~lynn/2006u.html#56

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

or this archeological reference
https://www.garlic.com/~lynn/2006v.html#10

in various discussions from the mid-90s ... pointing out significant issues ... the eventual response (by numerous parties) was that they were taking the lead from visa and mastercard. For instance, the people that i dealt with on des and public key in the mid-80s weren't participating in this particular activity in the mid-90s ... another archeological reference from the mid-80s
https://www.garlic.com/~lynn/2006u.html#45

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

and then old public key archeological reference from mid-80s
https://www.garlic.com/~lynn/2006.html#30 IBM microwave application--early data communications a
nd even this older public key archeological reference form 1981
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

Who has a Core Competency in Security?

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 25, 2006 02:48 PM
Subject: Who has a Core Competency in Security?
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visiable?
https://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?

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

and even more archeological background

for much of the 80s, i reported to yorktown (but lived in san jose). yorktown was where the person responsible for des worked and one of the two people responsible for ecc worked.

i had office in bldg. 28 (san jose research on the main plant site) ... until they built the new building up the hill and then i had office in almaden research. I also had a block of offices and labs out in bldg. 29, the los gatos vlsi lab.

i still made the east coast trip a couple times a month (leaving on the monday night red-eye out of sfo for kennedy and returning on friday). when i started the habit, i would take twa#44 monday night, and return friday on the last leg of the twa tel aviv, rome, kennedy, sfo flight. twa went bankrupt and i switched to panam. then panam sold its pacific routes to united (to concentrate on atlantic routes), and i switched to american.

What is the point of encrypting information that is publicly visible?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 25, 2006 03:53 PM
Subject: What is the point of encrypting information that is publicly visible?
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?

somewhat related news item, hot off the presses

Michigan Credit Card Mystery Deepens
http://www.consumeraffairs.com/news04/2006/11/mi_card_fraud.html

from above:
Numerous incidents involving breaches of bank security also demonstrate that there are major vulnerabilities at every level of a plastic transaction, from withdrawing money to buying goods online.

... snip ...

and/or can you say security proportional to risk?
https://www.garlic.com/~lynn/2001h.html#61

and then there are a couple recent posts about insider threats
https://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/aadsm26.htm#7 Citibank e-mail looks phishy

related posts:

Citibank's Cards Mysteriously Shut Down
http://www.consumeraffairs.com/news04/2006/03/citibank_cards.html
The 'Worst Hack Ever:' Debit Card Security Crisis Continues
http://www.consumeraffairs.com/news04/2006/03/worst_hack.html
Visa Admits To Problem In Mysterious Data Breach
http://www.consumeraffairs.com/news04/2006/06/visa_data_breach.html
ATM, Bank Card Security Getting Worse
http://www.consumeraffairs.com/news04/2006/11/atm_security.html

Who has a Core Competency in Security?

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 27, 2006 10:04 AM
Subject: Who has a Core Competency in Security?
Blog: Financial Cryptography
and now for something completely different

Defeating Virtual Keyboards and Phishing Banks
http://it.slashdot.org/it/06/11/27/0546230.shtml
Defeating Image-Based Virtual Keyboards and Phishing Banks
http://blogs.securiteam.com/index.php/archives/678

Who has a Core Competency in Security?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 28, 2006 07:00 PM
Subject: Who has a Core Competency in Security?
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm26.htm#9 Who has a Core Competency in Security?
https://www.garlic.com/~lynn/aadsm26.htm#10 Who has a Core Competency in Security?
https://www.garlic.com/~lynn/aadsm26.htm#12 Who has a Core Competency in Security?

Fighting Fraudulent Transactions (from yesterday's blog)
http://www.schneier.com/blog/archives/2006/11/fighting_fraudu.html

... from above ....
The solution is not to better authenticate the person, but to authenticate the transaction. (Think credit cards. No one checks your signature. They really don't care if you're you. They maintain security by authenticating the transactions.)

... snip ...

authenticate the transaction sounds quite a bit like x9.59 financial industry standard from the work by the x9a10 financial standard working group started in the mid-90s
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

and some of the posts in this blog on YES CARD exploits
https://www.garlic.com/~lynn/subintegrity.html#yescard

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

Who has a Core Competency in Security?

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 30, 2006 11:21 AM
Subject: Who has a Core Competency in Security?
Blog: Financial Cryptography
several related items from hackinthtebox.org ... somewhat related to my old post on the thread between information security and risk management
https://www.garlic.com/~lynn/aepay3.htm#riskm
https://www.garlic.com/~lynn/aepay3.htm#riskaads

......

Information Security Fundamentally Broken
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=21854&mode=thread&order=0&thold=0
Information Security Fundamentally Broken
http://www.webpronews.com/expertarticles/expertarticles/wpn-62-20061130InformationSecurityFundamentallyBroken.html
Community Comments & Feedback to Security Absurdity Article
http://www.securityabsurdity.com/comments.php
IT industry looks to human behaviour experts to improve security
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=21852
IT industry looks to human behaviour experts to improve security
http://www.innovations-report.de/html/berichte/informationstechnologie/bericht-75125.html
Hackers take aim at financial institutions
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=21851
Hackers take aim at financial institutions
http://www.vnunet.com/vnunet/news/2169953/hackers-aim-financial

Who has a Core Competency in Security?

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: December 10, 2006 10:50 AM
Subject: Who has a Core Competency in Security?
Blog: Financial Cryptography
and a recent thread with a few more archeological references
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#15 more secure communication over the network
https://www.garlic.com/~lynn/2006w.html#18 more secure communication over the network

Security Implications of Using the Data Encryption Standard (DES)

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Security Implications of Using the Data Encryption Standard (DES)
Date: Sat, 23 Dec 2006 13:37:30 -0700
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
from rfc-editor announcement today
4772 I
Security Implications of Using the Data Encryption Standard (DES), Kelly S., 2006/12/22 (28pp) (.txt=68524) (was draft-kelly-saag-des-implications-06.txt)
...
The Data Encryption Standard (DES) is susceptible to brute-force attacks, which are well within the reach of a modestly financed adversary. As a result, DES has been deprecated, and replaced by the Advanced Encryption Standard (AES). Nonetheless, many applications continue to rely on DES for security, and designers and implementers continue to support it in new applications. While this is not always inappropriate, it frequently is. This note discusses DES security implications in detail, so that designers and implementers have all the information they need to make judicious decisions regarding its use.


... snip ...

rfc 4772 summary
https://www.garlic.com/~lynn/rfcidx15.htm#4772

from
https://www.garlic.com/~lynn/rfcietff.htm

and in the rfc summery, clicking on the ".txt=" field retrieves the actual RFC.

note that there have been (at least) two countermeasures to DES brute-force attacks ... one is 3DES ... and the other ... mandated for some ATM networks, has been DUKPT. while DUKPT doesn't change the difficulty of brute-force attack on single key ... it creates a derived unique key per transaction and bounds the life-time use of that key to relatively small window (typically significantly less than what even existing brute-force attacks would take). The attractiveness of doing such a brute-force attack is further limited because the typical transaction value is much less than the cost of typical brute-force attack.

... and a little extra in the same announcement:
4732 I
Internet Denial-of-Service Considerations, Handley M., IAB, Rescorla E., 2006/12/22 (38pp) (.txt=91844) (Refs 1058, 1075, 1112, 2349, 2385, 2439, 2827, 2918, 3261, 3411, 3550, 3618, 3682, 3768, 4251, 4271, 4346, 4566, 4601) (was draft-iab-dos-05.txt)
....
This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities.

... snip ...

rfc 4732 summary
https://www.garlic.com/~lynn/rfcidx15.htm#4732

Changing the Mantra -- RFC 4732 on rethinking DOS

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: December 26, 2006 02:49 PM
Subject: Changing the Mantra -- RFC 4732 on rethinking DOS
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000844.html

original post mentioned two RFCs, the other was
https://www.garlic.com/~lynn/aadsm26.htm#16 Security Implications of Using the Data Encryption Standard (DES)

we had done detailed vulnerability study when we were doing our high availability product (ha/cmp) ... including tcp/ip (both RFCs and code)
https://www.garlic.com/~lynn/subtopic.html#hacmp

i.e. availability might be considered part of integrity and from the security acronym PAIN
P - privacy (or sometimes CAIN and confidentiality)
A - authentication
I - integrity
N - non-repudiation


later when we had been called in to consult on payments transactions ... for something that has since come to be called e-commerce
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

there was also an incident where the largest online service provider was starting to have internet server crash ... storage exhaustion with a lot of half-open sessions. this started the middle of june and continued thru the middle of august (during that period they had wide variety of different people to come in and look at the problem).

Finally one of the people flew out to the west coast and bought me a hamburger after work. He described the problem while I ate the hamburger. Then i gave him a quick&dirty fix which he applied later that night.

Almost exactly a year later ... there was a whole lot of press with similar kind of system failures at an ISP in manhatten (i.e. I talked to most of the major product providers the previous year about addressing the problem ... but none were interested until the problem got a whole lot of press).

misc. past references to the incident:
https://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
https://www.garlic.com/~lynn/99.html#48 Language based exception handling. (Was: Did Intel pay UGS to kill Alpha port? Or Compaq simply doesn't care?)
https://www.garlic.com/~lynn/2005c.html#51 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2006e.html#11 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006i.html#6 The Pankian Metaphor

for some topic drift ... recent post having to do with ha/cmp scale-up and distributed lock manager (DLM) being able to meet database ACID properties
https://www.garlic.com/~lynn/2006x.html#3 Why so little parallelism?

and other references mentioning distributed operation
https://www.garlic.com/~lynn/2006y.html#5 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2006y.html#6 The Future of CPUs: What's After Multi-Core?

SSL (https, really) accelerators for Linux/Apache?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: SSL (https, really) accelerators for Linux/Apache?
Date: Thu, 04 Jan 2007 13:13:51 -0700
To: cryptography@xxxxxxxx
for lots of topic drift about fast transactions and lightweight SSL (somewhat related to past assertions that majority of SSL use has been e-commerce related)... recent post in thread on secure financial transactions
https://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007

having some discussion about this news URL from today:

Faster payments should not result in weaker authentication
http://www.securitypark.co.uk/article.asp?articleid=26294&CategoryID=1

... other posts in the same thread:
https://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007

so having done a lot of optimization on the original payment gateway and some other SSL uses ... some of it mentioned in this thread (to help minimize payment transaction elapsed time):
https://www.garlic.com/~lynn/2007.html#7 SSL info
https://www.garlic.com/~lynn/2007.html#15 SSL info
https://www.garlic.com/~lynn/2007.html#17 SSL info

now, in the above thread, I've discussed the possible catch-22 for the SSL domain name certification industry
https://www.garlic.com/~lynn/subpubkey.html#catch22

however, in the past, I've also discussed leveraging the catch-22 to implement a really lightweight SSL ... somewhat similar proposal mentioned here in old email from 1981
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

and a couple past posts discussing really lightweight SSL in the context of the catch-22 scenario:
https://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.garlic.com/~lynn/2006f.html#33 X.509 and ssh

So after the initial e-commerce activity ... there were some number of efforts in the mid-90s to improve the internet payment technologies ... two such activities were SET and X9A10. The financial standards X9A10 working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (not just internet) ... resulting X9.59
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

I had gotten ahold of the SET specification when it was first available and did a crypto-op profile and calculated some crypto-op performance for typical SET transactions. Some number of people associated with SET claimed that my numbers were off by two orders of magnitude (too large by a factor of one hundred times) ... however when they eventually had running code ... my profile numbers were within a couple percent of the measured numbers. On an otherwise idle dedicated test infrastructure, a simple SET transaction was over 30 seconds elapsed time ... nearly all of that crypto-op processing. In a loaded infrastructure, contention and queueing delays could stretch that out to several minutes (or longer). Besides the enormous processing bloat ... there was also a lot of protocol chatter and enormous payload bloat. misc. posts:
https://www.garlic.com/~lynn/subpubkey.html#bloat

by comparison, X9.59 had to be a lightweight payload, lightweight processing, and fast transaction that was applicable to all environments (not just the internet).

x9.59 went for lightweight payload transaction that could complete in a single transaction roundtrip, with strong end-to-end security (applicable whether the transaction was "in-transit" or "at-rest"). It effectively substituted end-to-end strong authentication and strong integrity for information hiding encryption. X9.59 also eliminated knowledge of the account number as a fraud exploit
https://www.garlic.com/~lynn/subintegrity.html#harvest

and therefor eliminated the need for the most common use of SSL for hiding account numbers in e-commerce transactions (i.e. for really high performance and lightweight SSL is when you don't have to do it at all).

Non-repudiation, Evidence and TLS: another fine mess I've got you into :-(

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 5, 2007 10:42 AM
Subject: Non-repudiation, Evidence and TLS: another fine mess I've got you into :-(
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000848.html

old post where i pulled some sc27 definitions and added them to my merged security taxonomy and glossary
https://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudiation non-repudiation shares same issues surrounding "human signature" ... where a "human" signature is indication that somebody is demonstrating intent and has read, understood, agrees, approves, and/or authorizes something ... requiring some sort of indication that holds for each specific operation. "digital signature" carries NONE of those characteristics (other than the terms happen to share the word "signature"). lots of past posts discussing "human signature" (and having been brought in to help word-smith the california and federal electronic signature legislation)
https://www.garlic.com/~lynn/subpubkey.html#signature

non-repudiation requires something similar ... and as such, many of the definitions have morphed into involving a service that provides some indication as to some specific occurance ... rather than trying to demonstrate non-repudiation of intent, demonstrate non-repudiation (actually proof) of some specific event or activity having occured.

a couple of (lengthy) past threads discussing "meaning" of non-repudiation:
https://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep1 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep2 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep4 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
https://www.garlic.com/~lynn/2001c.html#30 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#34 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#40 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#41 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#42 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#43 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#44 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#46 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#47 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#50 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#51 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#52 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#54 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#59 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#73 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#8 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#11 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#12 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage
https://www.garlic.com/~lynn/aadsm11.htm#15 Meaning of Non-repudiation

Tamperproof, yet playing Tetris

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Tamperproof, yet playing Tetris.
Date: Sat, 06 Jan 2007 13:43:33 -0700
To: cryptography@xxxxxxxx
Perry E. Metzger wrote
Handheld "Chip & Pin" terminals for reading credit cards in the UK are required to be tamperproof to avoid the possibility of people suborning them. Here is a report from a group that has not merely tampered with such a terminal, but has (as a demo) converted it into a tetris game to demonstrate that they can make it do whatever they like.
http://www.lightbluetouchpaper.org/2006/12/24/chip-pin-terminal-playing-tetris/


a couple mentions of the same

Game over for Chip and PIN?
http://www.finextra.com/fullstory.asp?id=16332
Hacked Chip and PIN terminal plays Tetris
http://www.astalavista.com/?section=news&cmd=details&newsid=3160
Chip and Pin fraud alert
http://www.thisismoney.co.uk/saving-and-banking/article.html?in_article_id=416139&in_page_id=7&ct=5

misc. past posts on related vulnerabilities and exploits
https://www.garlic.com/~lynn/subintegrity.html#yescard

as an aside ... some of the "overlay" type of exploits that make the news about automatic teller machines have also been used with point-of-sale terminals ... somewhat a man-in-the-middle attack ... even if it is only being used for skimming information (as in most of the automatic teller machine scenarios) .... aka how does the consumer know they are dealing with the real-terminal ... or an MITM/middle-man terminal? various past posts mentioning MITM-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitmattack

the EU finread standard attempted to address some of the same issues ... providing tamper resistant personal-use terminals (addressing some of the same tamper resistant characteristics as point-of-sale terminals)
https://www.garlic.com/~lynn/subintegrity.html#finread

two of the issues
  1. is the transaction you "see", the same as the transaction you "approve"
  2. independent pin-entry ... as countermeasure to the numerous PC-based keylogging vulnerabilities
there is somewhat reduced concern that a terminal (that you always have physical possession of) ... being subverted with some sort of overlay technology (i.e. there isn't an actual attack the tamper-resistant characteristics of the operating point-of-sale terminal ... but there is a MITM overlay). Cellphone and PDAs use at POS have also been suggested as countermeasure to the variety of point-of-sale terminal exploits.

In X9A10 financial standards working group .... recent mention in this post
https://www.garlic.com/~lynn/aadsm26.htm#18 SSL (https, really) accelerators for Linux/Apache?

one of the things looked at for X9.59 standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

was how can the relying/authorizing party really know the integrity characteristics of the transaction environment. so x9.59 allowed for the transaction environment (point-of-sale terminal, finread terminal, etc) to also digitally (co-)sign the transaction. the authorizing party can look-up the integrity characteristics of the terminal used in the transaction environment (and also have some assurance that terminal was actually used for the transaction based on verifying its digital signature with onfile public key).

FC07 Preliminary Programme - Leaving Room for the Bad Guys

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 8, 2007 09:59 AM
Subject: FC07 Preliminary Programme - Leaving Room for the Bad Guys
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000850.html

i would contend that a lot of vulnerabiilties raised by YES CARD exploit ... misc. past posts
https://www.garlic.com/~lynn/subintegrity.html#yescard

was looking at a very narrow set of threats ... specifically lost/stolen card threats ... and concentrating on countermeasures for attacks on the cards. the YES CARD exploits effectively turn out to be attacks on the terminals, not attacks on the cards.

the basis for the YES in the YES CARD reference comes somewhat from the standpoint that once it was assumed that the card had been secured, then a system could be deployed where the terminal could rely on business rules implemented in the card.

the issue was that skimming type of attacks (typically a terminal attack) ... recent reference
https://www.garlic.com/~lynn/aadsm26.htm#20

predated work on infrastructure that gave rise to YES CARDs. a (terminal) skimming attack then could be used to produce a counterfeit YES CARD ... and letting the terminal rely on "judgement" of the card for offline transactions severely aggravated the risk exposure (somewhat blindly assuming that there wouldn't be countefeit cards). It wasn't even necessary to skim the PIN ... since the terminal would ask the (potentially counterfeit) card, if the entered PIN was correct, and of course, a counterfeit YES CARD would always answer YES.

So, another maxim would be to include the full end-to-end analysis of all the components when designing high integrity infrastructure..

However, the guideline that there is always possibility that something has been overlooked (the bad guys are so ingenious), either purposefully or not ... would promote design of security in-depth with multiple layers/levels of countermeasures (even when you may have otherwised believed all bases have been covered).

Tamperproof, yet playing Tetris

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Tamperproof, yet playing Tetris.
Date: Mon, 08 Jan 2007 11:41:36 -0700
To: cryptography@xxxxxxxx
... and has now made slashdot ....

Chip & PIN Terminal Playing Tetris
http://hardware.slashdot.org/hardware/07/01/08/1355221.shtml

previous post
https://www.garlic.com/~lynn/aadsm26.htm#20 Tamperproof, yet playing Tetris

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

and a whole lot of past comments
https://www.garlic.com/~lynn/subintegrity.html#yescard

It's a Presidential Mandate, Feds use it. How come you are not using FDE?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: It's a Presidential Mandate, Feds use it. How come you are not using FDE?
Date: Wed, 17 Jan 2007 19:07:01 -0700
To: Steven M. Bellovin <smb@xxxxxxxx>
CC: cryptography@xxxxxxxx
Steven M. Bellovin wrote:
Not necessarily -- many of my systems have multiple disk drives and file systems, some of which are on removable media. Apart from that, though, this is reinforcing my point -- what is the threat model?

PC/RT had external scsi disk drive housing ... with scsi disk drive "bricks" that could be removed from the housing and locked in safes (when the owner wasn't physical present). This was later part of the '80s ... twenty some years ago.

nearly 35 yrs ago ... there was this enormous corporate project and all the information on the project was kept strictly confidential. a whole bunch of security features were added to prevent leakage of any of the information. they even went so far as to claim that even I couldn't access the information ... even if I was physical present in the room. It was one of the few times that I actually took the bait ... I claimed it would only take me a few minutes ... I found the location in memory of the authentication routine and patched one byte so all returns from the routine indicated valid authentication (most of the time was spent disabling all access to the machine from outside the room since i didn't want a real compromise).

This is similar ... but different to more recent YES CARD vulnerability ... where the card is asked if the correct PIN has been entered ... and a YES CARD always responds YES. Would appear to work not only for skimming scenario and counterfeit card .... but also as a MITM-attack with valid card. misc. past posts mentioning yes card
https://www.garlic.com/~lynn/subintegrity.html#yescard

In any case, my claim way back then (nearly 35yrs ago) was that the only countermeasure to such physical access was encrypting the data. Later, I even did prototype filesystem as example ... but at the time ... the processor load was excessive (would typically only be justified for small subset of extremely sensitive information).

The project back then was called Future System
https://www.garlic.com/~lynn/submain.html#futuresys

and was canceled w/o ever being announced. However there were some comments that the amount spent on the failed future system project would have bankrupted any other computer company.

misc. past posts admitted to haven once risen to the bait in my brash youth.
https://www.garlic.com/~lynn/96.html#24 old manuals
https://www.garlic.com/~lynn/2004g.html#45 command line switches
https://www.garlic.com/~lynn/2006.html#11 Some credible documented evidence that a MVS or later op sys has ever been hacked

The scenario was that if I had physical access ... there were a whole variety of compromises that wouldn't have been possible otherwise .... at least for these class of systems ... small footnote about some deployments ... which i didn't find out until sometime later
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

Note that when it started becoming common for people taking portable terminals and later PCs on the road ... for off-site access (reading email, etc) in the very early 80s ... there was vulnerability study done ... and one conclusion was that one of the most weakest points is a hotel PBX closet ... which resulted in design, build and deployment of custom encrypting 2400baud modems for all off-site dial-in access.

I'm periodically quite dismayed by the cavalier way that many corporations have treated off-site access over the past 20 years. For other comparison, the corporate network, which was larger than arpanet/internet from just about the beginning until possibly sometime mid-85.
https://www.garlic.com/~lynn/subnetwork.html#internalnet

required link encryptors on all lines that left a corporate facility ... and sometime in the mid-80s there were comments that the internal corporate network had over half of all the link encryptors in the world (these are things like leased lines ... separate from the encrypting dial-up modems).

News.com: IBM donates new privacy tool to open-source Higgins

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: News.com: IBM donates new privacy tool to open-source Higgins
Date: Tue, 30 Jan 2007 10:14:47 -0700
To: John Gilmore <gnu@xxxxxxxx>
CC: cryptography@xxxxxxxx
John Gilmore wrote:

http://news.com.com/IBM+donates+new+privacy+tool+to+open-source/2100-1029_3-6153625.html

IBM donates new privacy tool to open-source
By Joris Evers
Staff Writer, CNET News.com
Published: January 25, 2007, 9:00 PM PST


... and

For example, when making a purchase online, buyers would provide an encrypted credential issued by their credit card company instead of actual credit card details. The online store can't access the credential, but passes it on to the credit card issuer, which can verify it and make sure the retailer gets paid.

"This limits the liability that the storefront has, because they don't have that credit card information anymore," Nadalin said. "All you hear about is stores getting hacked."

Similarly, an agency such as the Department of Motor Vehicles could issue an encrypted credential that could be used for age checks, for example. A company looking for such a check won't have to know an individual's date of birth or other driver's license details; the DMV can simply electronically confirm that a person is of age, according to IBM.


...

this was somewhat the issue with x.509 identity certificates from the early 90s, they were being overloaded with personal information ... and then the proposal that everybody should then "spray" such digital certificates frequently all over the world. in this period, they were also being touted for use in electronic driver's licenses, passports, etc.

In the mid-90s, with the realization of the enormous privacy exposures of such a paradigm ... there was some parties retrenching to relying-party-only certificates ... basically a record pointer ... which was then used as reference to the record with the necessary information ... and only the absolutely necessary information was then divulged.
https://www.garlic.com/~lynn/subpubkey.html#rpo

however, it was trivially possible to demonstrated that the actual digital certificate was redundant and superfluous ... all that was necessary was the record pointer, a digital signature ... and the responsible agency could verify the digital signature with public key on file ... at the same time they processed the request using the record pointer.

This was basically the FSTC organizations
http://www.fstc.org/

model for "FAST" (financial authenticated secure transaction). The transaction is mapped into existing ISO 8583 message and uses the existing infrastructure operations. Rather then divulging age, a FAST (/8583) transaction ... digital signed by the individual ... could ask whether the person meets some age criteria, address criteria, etc ... getting YES/NO response ... w/o divulging any additional information (like actual date of birth). This was modeled after existing (ISO 8583, debit, credit, etc) financial transaction which effectively asks whether the merchant gets paid or not (simply YES/NO response).

This is also, effectively the X9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

The X9A10 financial standard working group, in the mid-90s was given the requirement to preserve the integrity of the financial infrastructure for all retail payments. The transaction is sent with digital signature, the responsible agency validates the digital signature, examines the transaction request and then responds YES/NO regarding whether the merchant gets paid or not.

The other characteristic of X9.59 was that it included a business rule that "X9.59" account numbers couldn't be used in non-X9.59 transaction. That made the associated account numbers (record pointers) unusable w/o the accompanying digital signature i.e. random people couldn't generate random (valid) transactions against the account number/record number. This had the effect of eliminating a lot of the existing skimming/harvesting exploits (it didn't do anything about the skimming/harvesting ... but it made the information unusable for exploists)
https://www.garlic.com/~lynn/subintegrity.html#harvest

It isn't necessary to have an encrypted credential ... since if it was purely "static data" ... and simply presenting such static data exposes the infrastructure to various kinds of replay attack. In that sense, the static data can be any recognizable information specific to the responsible agency handling the transaction. The "static data" is used by the responsible party to lookup the actual information (including, if necessary the public key) ... and the digital signature on every transaction prevents various kinds of replay attacks ... that might be possible in an infrastructure relying on only static data. If the agency is going to lookup something (rather than have it carried around in large encrypted packet ...) then it becomes immaterial whether the actual (static data) record locator is encrypted or not.

for a little drift ... a different kind of static data exploit here
https://www.garlic.com/~lynn/subintegrity.html#yescard

somewhat related posts in this thread:
https://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#46 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007

with reference to recent news items somewhat touching on the same subject:

Latest Breach May Force a New Approach to Data Security
http://www.digitaltransactions.net/newsstory.cfm?newsid=1226

Analyst: Banks Must Make Credit Card Accounts Useless to Data Theives
http://www.informationweek.com/showArticle.jhtml;jsessionid=E34WIOTVAIIHKQSNDLPCKHSCJUNN2JVN?articleID=197000263

this is somewhat related to my periodic references that existing infrastructure could bury the planet under miles of (information hiding) encryption and still not prevent account number linkage ... somewhat related old post about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

misc. past posts with reference to FSTC's FAST
https://www.garlic.com/~lynn/99.html#171 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/99.html#216 Ask about Certification-less Public Key
https://www.garlic.com/~lynn/99.html#217 AADS/X9.59 demo & standards at BAI (world-wide retail banking) show
https://www.garlic.com/~lynn/ansiepay.htm#privacy more on privacy
https://www.garlic.com/~lynn/aadsm9.htm#cfppki3 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop
https://www.garlic.com/~lynn/aepay10.htm#8 FSTC to Validate WAP 1.2.1 Specification for Mobile Commerce
https://www.garlic.com/~lynn/aadsm16.htm#5 DOD prepares for credentialing pilot
https://www.garlic.com/~lynn/aadsm17.htm#19 PKI International Consortium
https://www.garlic.com/~lynn/2005i.html#33 Improving Authentication on the Internet
https://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#42 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh

EV - what was the reason, again?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 2, 2007 09:33 AM
Subject: EV - what was the reason, again?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000863.html

a lot of work the past couple years has gone into countermeasures to phishing ... original SSL was suppose to provide for both 1) is the website you think you are talking to, really the website you are talking to and 2) hide information that would be transmitted over the internet.

some what related recent comment here on Extended Validation certificates
https://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007

however, recent news items:

Phishing overtakes viruses and Trojans
http://www.astalavista.com/?section=news&cmd=details&newsid=3321
Phishing overtakes viruses and Trojans
http://news.com.com/2100-7349_3-6154716.html?part=rss&tag=2547-1_3-0-20&subj=news
Phishing overtakes viruses and Trojans
http://news.com.com/Phishing+overtakes+viruses+and+Trojans/2100-7349_3-6154716.html?tag=nefd.top

a recent comment here
https://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"

and misc. past posts mentioning mitm-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

we had looked at the whole domain name certification process ... when we were doing some consulting for a small client/server startup that wanted to handle payments on servers ... and had this technology called SSL ... old reference
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

part of the issue mentioned many times before is the economics to the merchant related to fraud. the merchant is already paying a heavy fraud burden effectively related to transaction insurance in form of interchange fees. the digital certificates don't provide any additional help in that area ... that was one of the reasons we coined the term "comfort certificates" way back when.

start of one such tread, long ago and far away
https://www.garlic.com/~lynn/aepay4.htm#comcert Merchant Comfort Certificates

and the certificates being somewhat orthogonal to basic issues also shows up in this old post on security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

aka merchant is already paying a hefty bill ... the certificates provide little practical benefit to the merchant ... so it is difficult for merchant to show any ROI for spending large amounts of money on certificates ... which then means that certification authorities have hard time charging a lot for certification activities. this is my past observation that primary direction for digital certificates left is to move into the low-value/no-value market segment (which further reduces justification for doing a lot related to the issurance of certificates). a few old posts on the subject:
https://www.garlic.com/~lynn/aadsm20.htm#33 How many wrongs do you need to make a right?
https://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security

and as i've frequently repeated in the past ... the miriad of vulnerabilities and exploits was behind a lot of the x9.59 financial industry standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

when in the mid-90s, the x9a10 financial standard working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments.

it would be more logical to drop back to clients being able to get "on-file" public keys directly from the domain name infrastructure for providing assurance that the website that the browser things it is talking to, is really the website the browser is talking to (and provide for slimmed down SSL providing for information hiding while in transits the internet) ... misc. past posts related to that subject
https://www.garlic.com/~lynn/subpubkey.html#catch22

and have the fraud and integrity issues related to types of transactions integrated into existing infrastructure operations for handling fraud and integrity issues.

a fundamental problem in security operations crops up trying to address issues in adhoc and hodge-podge manner ... which leaves a lot of openings and cracks for the attackers.

man in the middle, SSL

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: man in the middle, SSL
Date: Sat, 03 Feb 2007 10:04:18 -0700
To: James Muir <jamuir@xxxxxxxx>
CC: cryptography@xxxxxxxx
James Muir wrote:
It is my understanding that SSL is engineered to resist mitm attacks, so I am suspicious of these claims. I wondered if someone more familiar with SSL/TLS could comment.

Isn't in the case that the application doing SSL on the client should detect what this proxy server is doing and display a warning to the user?


My oft repeated comment about when we were asked to consult with this small client/server startup that wanted to do payments on servers .... and had this technology called SSL ...
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

The browser was to check that what the person typed in ... matched the domain name in the digital certificate that the server provided (that the server that the client thot they were talking to was the server that they were talking to).

There was some other ancillary things that we were interested in ... that the digital certificate actually represented something more ... i.e. it was issued by the acquiring financial institution that financially stood behind the merchant .... since the merchant was already paying a lot of money to cover doing business. however, that never happened ... so the digital certificate just represents that it belongs to the owner of the domain. this issue is somewhat touched on in this blog posting
https://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
in this blog
https://financialcryptography.com/mt/archives/000863.html

However, early on, merchant webservers found that doing SSL for the whole shopping experience cut their thruput by something like 80-90 percent ... so the industry fairly quickly switched to just using SSL for the payment/checkout portion when you click on their button. Now the URL is being provided by the server (button) ... not by the client, as a result the effect is no longer "is the client talking to the server that the client thinks they are talking to" ... since the server is supplying both the URL and the digital certificate ... the result is "the server is the server that the server claims to be" (unless it is a really dumb crook/attacker).

It isn't sufficient for there to be "ssl certificates" to be countermeasure to MITM-attack, the security process has to include that the server is validated against something the client supplies ... not that the server is validated against something the server supplies (i.e. i can prove that i am whoever i claim to be ... not that i can prove that i am who you think i am).

This is also behind a lot of the phishing stuff ... that the attacker can claim to be something ... and provide a field/button for you to click on ... the SSL certificate then just proves that the server matches the URL provided by the field/button; since the attacker supplying the field/button is producing the URL ... and not the client ... it takes advantage of the difference, for a MITM-attack ... between the opening/crack opened by what is claimed for the button and what the URL actually is ... since only the URL is being validated by the SSL certificate ... not what the client thinks is claimed for the field/button. some more comments in these posts:
https://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"?
https://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007

lots of past posts mentioning MITM-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

i.e. you have to understand the end-to-end business process (of security) ... where all the cracks are ... and just which (of possibly large number) MITM vulnerability ... that you have specifically created a countermeasure for.

so one of the things that we did as part of early deployment (of this stuff that has since come to be called electronic commerce) was go around and do some detailed end-to-end audits of these emerging operations that were calling themselves certification authorities and producing these things that were being called SSL domain name digital certificates. At the time, we coined this term certificate manufacturing to try and differentiate what was happening
https://www.garlic.com/~lynn/subpubkey.html#manufacture

and what was in the literature about "public key infrastructure" ... for a little topic drift ... proposal from 1981 for a (small i) infrastructure:
https://www.garlic.com/~lynn/2006w.html#12 more secure communcation over the network

Part of the "audits" was figuring out just what it was they were doing as part of the process that they were calling certification ... as the business process supporting the technology that produced the actual digital certificates (i.e. a credential/certificate that is a stand-in representation of the certification they were performing). this gave rise to a lot of comments/observations about if the domain name infrastructure actually provided a direct, higher integrity operation ... it would obsolete any requirement for having external certification operations (and therefor also could obsolete the certificates as representations of those certification operations) ... lots of past posts mentioning such catch-22 scenario
https://www.garlic.com/~lynn/subpubkey.html#catch22

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

and recent posts with comments about early x.509 identity certificate stuff
https://www.garlic.com/~lynn/2007.html#15 SSL info
https://www.garlic.com/~lynn/2007.html#17 SSL info
https://www.garlic.com/~lynn/2007.html#34 SSL info
https://www.garlic.com/~lynn/2007.html#42 The logic of privacy
https://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007d.html#10 The logic of privacy

man in the middle, SSL ... addenda

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: man in the middle, SSL ... addenda
Date: Sat, 03 Feb 2007 13:33:52 -0700
To: James Muir <jamuir@xxxxxxxx>
CC: cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL

basically digital certificates were designed as the electronic equivalent for offline distribution of information ... paradigm left over from the "letters of credit" and "letters of introduction" out of the sailing ship days (and earlier). as things moved into the online age ... certification authorities with digital certificates moved into generic low-value/no-value market segment.

this is the difference between a generic employee badge for door entry ... that is identical for all employees ... vis-a-vis doing stuff specific and tailored to each employee.

this is somewhat the x.509 identity certificate example mentioned in the previous post ... from the early 90s ... overloaded with personal information and paradigm that promoted repeatedly spraying the identity certificates all over the world. by the mid-90s, it was starting to dawn that such a paradigm wasn't such a good idea ... and there was retrenchment to relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

which basically only contained public key and some sort of record location (which holds the "real" information). however, in the payment sector ... even these truncated relying-party-only certificates still represented enormous payload and processing bloat
https://www.garlic.com/~lynn/subpubkey.html#bloat

especially when it was trivial to demonstrate that you could have the public key along with all the other necessary information in the designated record ... and that the digital certificate was therefor redundant and superfluous. This is also somewhat the scenario raised in the domain name infrastructure for on-file public keys .... creating a significant catch-22 for the ssl domain name certification authority industry
https://www.garlic.com/~lynn/subpubkey.html#catch22

... just upgrade the existing domain name infrastructure with on-file public keys (a requirement also suggested by the ssl domain name certification authority industry) ... but such a change could quickly result in a certificate-free, public key infrastructure
https://www.garlic.com/~lynn/subpubkey.html#certless
.... also the reference from 1981
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

i.e. for the most part now ... SSL is just be using to prove that you have some valid domain name ... and the domain name you claim is the domain name you have ... this is somewhat equivalent to the low-value door badge readers to simply check are you some valid employee ... w/o regard to any higher value scenario requiring specific detail about which valid employee.

so one of the points i repeatedly raise is that while digital certificates (as representation of some certification) is part of an offline paradigm construct ... and in the migration of the world to online environment ... digital certificates have attempted to find place in the no-value/low-value market niches ... that as soon as there is some online component (real-time, online access to the information) ... it then becomes trivial to show that such digital certificates become redundant and superfluous.

so SSL domain name infrastructure was originally primarily being used to support what came to be called electronic commerce (and still may be the primary use) .... for:

1) is the browser actually talking to the webserver that the person thinks it is talking to and
2) hide (encrypt) the account number during transmission over the internet.

there have been some number of technical implementation vulnerabilities with respect to SSL and things like MITM-attacks ... but the big business process issue was that the deployment fairly early changed from "is the browser actually talking to the webserver the person thinks it is talking to" ... to "the browser is talking to the webserver that the webserver claims to be" (since the same webserver was supplying both the URL and the digital certificate confirming the webserver supplied URL).

The second feature of ssl (encrypting to hide transmitted account numbers) was somewhat to place the transactions flying over the anarchy of the world-wide Internet ... on "level play field" with the transactions that were fling over dedicated telephone wires. However, the major vulnerability during that period ... and continuing today ... wasn't evesdropping the transaction during public transmission ... but vulnerabilities at the end-points .... which SSL does nothing to address. The end-point webservers somewhat increased vulnerabilities (compared to non-internet implementations) since a lot of the transaction logs became exposed to attacks from the internet. This matter is slightly debatable since the long term studies ... continuing up thru at least recently, is that seventy percent of the resulting fraudulent transactions involve some sort of "insider".

So for SSL 1) the resulting major deployments of SSL negating much of the original countermeasure against MITM-attacks (related to integrity issues in the domain name infrastructure) and 2) the encryption only slightly put internet transactions on same playing field vis-a-vis the non-internet transactions ... and SSL did nothing to address the major vulnerabilities (at least with regard to the fraud related to the kind of transactions that might happen over the internet ... whether the actually fraudulent transactions occurred over the internet or not).

So after working on the stuff currently called electronic commerce ... we did some stuff in the x9a10 financial standard working group ... which in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (ALL as in ALL ... and not just internet). the result was x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

in the security PAIN acronym

P ... privacy (sometimes CAIN and confidentiality)
A ... authentication
I ... integrity
N .... non-repudiation


SSL was being used for privacy/confidentiality attempting to prevent leakage of the account number. The x9a10 working group observation was that the account number was needed in large number of different business processes ... and couldn't just be simply kept hidden. This somewhat resulted in my periodically repeated comment that the planet could be buried under miles of encryption and still not prevent account number leakage. This is because the account number is required (unencrypted) in a large number of different places (and these processes may occur over extended period of time)

So effectively ... x9.59 standard (security) could be described as substituting "authentication" and "integrity" for "privacy/confidentiality" in order to preserve the integrity of the financial infrastructure. X9.59 transactions can be exposed all over the place ... during transmission over the internet, in security breaches involving transactions logs ... etc ... and the attackers still wouldn't be able to use the information to perform fraudulent transactions. It was no longer necessary to hide (encrypt) the account number and/or the transactions to prevent fraud ... the information could be widely publicly exposed and the crooks wouldn't be able to use the information for fraudulent transactions.

In that sense ... x9.59 eliminates one of the primary uses of SSL for hiding electronic commerce transactions (encrypting transactions) and some suggested improvements in the domain name infrastructure integrity eliminates most of the rest ... i.e. MITM-attacks.

man in the middle, SSL

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: man in the middle, SSL
Date: Mon, 05 Feb 2007 10:42:48 -0700
To: James Muir <jamuir@xxxxxxxx>
CC: cryptography@xxxxxxxx
somewhat related

Study Finds Bank of America SiteKey is Flawed
http://it.slashdot.org/it/07/02/05/1323243.shtml

Study Finds Security Flaws on Web Sites of Major Banks
http://www.nytimes.com/2007/02/05/technology/05secure.html?ref=business

The Emperor's New Security Indicators
http://www.usablesecurity.org/emperor/

from above
We evaluate website authentication measures that are designed to protect users from man-in-the-middle, phishing, and other site forgery attacks. We asked 67 bank customers to conduct common online banking tasks. Each time they logged in, we presented increasingly alarming clues that their connection was insecure. First, we removed HTTPS indicators. Next, we removed the participant's site-authentication image---the customer-selected image that many websites now expect their users to verify before entering their passwords. Finally, we replaced the bank's login page with a warning page. After each clue, we measured whether participants entered their passwords or withheld them. ... snip ...

somewhat the issue ... from previous posts in this thread:
https://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL

and recent post/thread from early last month on the subject
https://www.garlic.com/~lynn/2007b.html#53
https://www.garlic.com/~lynn/2007b.html#54

... originally SSL was going to prevent man-in-the-middle attack because the person knew the website that they were going to talk to and the corresponding URL. They would enter that URL into the browser and the browser would validate that the contacted website was in fact the website for that URL (assuming the entered URL was HTTPS and not HTTP)

early on, SSL was perceived to be too expensive, and so relegated it to just checkout/payment. now the user entered URL with HTTP and the website wasn't validated ... so could be man-in-the-middle. at some point the user clicked on https (checkout/payment) button provided by the website. now instead of HTTPS validating that the user was talking to the webserver that they thot they were talking to ... HTTPS was validating that the webserver was whatever webserver that the webserver was claiming to be (since the webserver was providing both the HTTPS URL and the SSL digital certificate).

so as the user convention of clicking on provided buttons proliferated ... the cracks/gaps widened between what webserver the user thot they were talking to and the webserver they might actually be talking to (since there was less & less a connection between what consumers thot of as the website and the URLs that were being validated by SSL).

So one of the possible countermeasures was for a website to provide unique something you know authentication ... i.e. something hopefully only you knew (so you had higher degree of confidence that you were actually talking to the website you thot you were talking to.

The problem was that if the communication was already talking to man-in-the-middle website impersonation ... there is nothing that would prevent the man-in-the-middle from impersonating the website to the consumer ... and impersonating the consumer to the actual website. Effectively, by definition for man-in-the-middle, the man-in-the-middle transparently passes communication in both directions (except possibly modifying URLs and internet addresses contained in the traffic as needed).

in effect, the mechanism is a countermeasure to simple website impersonation attacks (attacks on the consumer) ... but not to website man-in-the-middle attacks.

other refs
https://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"?
https://www.garlic.com/~lynn/2007c.html#51 Securing financial transactions a high priority for 2007

misc. past posts mentioning man-in-the-middle attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

News.com: IBM donates new privacy tool to open-source Higgins

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: News.com: IBM donates new privacy tool to open-source Higgins
Date: Mon, 05 Feb 2007 11:41:28 -0700
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
Anne & Lynn Wheeler wrote:
http://news.com.com/IBM+donates+new+privacy+tool+to+open-source/2100-1029_3-6153625.html


from above:
The encrypted credentials would be for one-time use only. The next purchase or other transaction will require a new credential. The process is similar to the one-time-use credit card numbers that Citigroup card holders can already generate on the bank's Web site.

... snip ...

past post:
https://www.garlic.com/~lynn/aadsm26.htm#24 News.com: IBM donates new privacy tool to open-source Higgins

... so if you had to go to the credential issuing website every time you needed a one-time use credential (one-time use is countermeasure to replay attacks involve static data credentials) ... what mechanism are you using to authenticate yourself to the credential issuing website.

if the mechanism for authentication to the credential issuing website is of reasonably strong security ... then why don't you use that mechanism directly in the regular transaction ... rather than having to have an intermediary credential involved.

this is somewhat the argument used about digital certificates being redundant and superfluous in an online environment ... whatever was used to acquire the (x.509 identity) digital certificate ... especially a relying-party-only digital certificate
https://www.garlic.com/~lynn/subpubkey.html#rpo

to avoid repeatedly spraying personal information all over the world ... just use that interaction directly ... and avoid the superfluous and redundant digital certificate.

this is the certificate-less public key infrastructure operation
https://www.garlic.com/~lynn/subpubkey.html#certless

in the x9.59 financial standard transaction
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959

or in the similar FAST transaction (for matters other than financial transaction authorization) done by FSTC in the 90s
http://www.fstc.org/

one might claim that this new mechanism is another approach to addressing the enormous privacy exposure represented by the x.509 identity digital certificates from the early 90s ... but my oft repeated claim is that the whole credentialing and certificate paradigm is left-over from the offline era. in the online era ... if the relying party either 1) has their own online information and/or 2) has online, realtime access to the responsible authoritative agency or institution ... then credentials and certificates purely represent (redundant and superfluous) relics predating online infrastructures.

man in the middle, SSL

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: man in the middle, SSL
Date: Tue, 06 Feb 2007 08:40:18 -0700
To: Leichter, Jerry <leichter_jerrold@xxxxxxxx>
CC: James Muir <jamuir@xxxxxxxx>,  cryptography@xxxxxxxx
Leichter, Jerry wrote:
Recall how SiteKey works: When you register, you pick an image (from a large collection) and a phrase. Whenever you connect, the bank will play back the image and phrase. You aren't supposed to enter your password until you see your own image and phrase.

i.e. it is a countermeasure to a impersonation attack ... not a man-in-the-middle (impersonation). all it presumably attempts to address is "are you talking to the website you think you are talking to" ... which is the same thing that SSL countermeasure to man-in-the-middle is supposed to be doing.

man-in-the-middle can defeat simple impersonation countermeasures by impersonating the server to the client and impersonating the client to the server ... and (somewhat) transparently passing traffic in both directions. requiring the server to present unique something you know authentication information is then straight forward for man-in-the-middle by having access to the "real" server.

i would contend that the issue for introducing sitekey ... was that SSL wasn't adequately protecting against man-in-the-middle attacks ... i.e. previous posts
https://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL ... addenda
https://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle, SSL

... however, i contend that sitekey isn't even designed to be countermeasure against man-in-the-middle attacks ... it only is a countermeasure against simple impersonation attacks ... so it isn't even addressing the short-comings in SSL that (my opinion) gave rise for the need for sitekey in the first place.

the other issue is that "your own image and phrase" is a shared-secret (and a flavor of static something you know authentication) ... so it presumably requires similar practices required for password shared-secrets ... if it had turned out to significantly address SSL short-comings (mitm-attacks) and saw wide deployment .... then presumably you would need a unique flavor for every unique security domain (ala password shared-secrets). The implication then is that it would scale as poorly as password shared-secret paradigm.

previous post mentioning that the paradigm might scale as poorly as other shared-secret based authentication implementations
https://www.garlic.com/~lynn/2007b.html#10 Special characters in passwords was Re: RACF - Password rules

misc. posts mentioning man-in-the-middle attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

misc. posts mentioning shared-secret (authentication) paradigm
https://www.garlic.com/~lynn/subintegrity.html#secret

man in the middle, SSL ... addenda 2

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: man in the middle, SSL ... addenda 2
Date: Wed, 07 Feb 2007 11:44:28 -0700
To: cryptography@xxxxxxxx
so the assertion in the previous post
https://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL

was that sitekey as being introduced because of shortcomings in SSL countermeasures to man-in-the-middle attacks .... however sitekey only deals with simple impersonation and is easily defeated with a man-in-the-middle attack

in earlier post
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL

there was reference to SSL attempting to address man-in-the-middle attacks and "are you really talking to the server that you think you are talking to". however, SSL might be better characterized as verifying that the operator of the webserver is the owner of the corresponding domain name ... aka a digital certificate & pki operation demonstrates that the operator of the webserver has use of the private key that corresponds to the "public key" in the digital certificate ... bound to the domain name. The browser than validates that the domain name in the URL is the same as the domain name in the (validated) digital certificate.

one of my assertions is that problems cropped up when the public started associating webservers with buttons that they clicked on ... significantly degrading any association in most of the publics' mind between URLs and the webserver. Since the public weren't effectively associating URLs with webservers ... and the only function provided by SSL (as countermeasure to man-in-the-middle attacks) was validating the correspondence between the URL and the webserver .... a widening security gap exists between the "buttons" that the public associate with webservers and the URL, which is the unit of validation by SSL

one conclusion is if countermeasures are introduced that don't actually address the actual security vulnerabilities ... then they may not be able to eliminate those security vulnerabilities.

so one countermeasure that has been introduced (to close some part of the security gap) is by some of the email clients which look for "buttons" in the content ... and if the label of the button appears to be a url/http ... it checks if the actual url/http is the same as the claimed url/http. if they don't match ... the email client will flag the email as potential problem. The simple countermeasure by attackers ... is to not use a http/url label for the button (i.e. just label the button something else, say the name of some financial institution).

Another kind of approach trying to close the gap between what the people associate with webservers and the actual URL used ... is to take a page out of PGP and have a list of "trusted" urls (or at least domain names). Browsers display the assigned trust level recorded for that domain name used in the URL (and then SSL verifies that the webserver contacted is actually the webserver for that URL). This would start to provide a mechanism for closing the gap between what the public deals with and the part of the infrastructure being checked by SSL.

(at least) two problems with this approach:

1) a repository of URL trust levels is almost identical to a trusted public key repository (directly used by PGP). the repository could directly record both the URL, the public key for that URL as well as the associated trust level. this would be another demonstration of digital certificates being redundant and superfluous in an online world and would provide the basis for a more trusted environment than the current SSL operation .... misc. past posts mentioning certificate-less public key operation
https://www.garlic.com/~lynn/subpubkey.html#certless

2) so the new (old) attack is social engineering attempting to get people to click on various buttons that change the trust level in their local trust repository. however, that also exists today ... social engineering to get people to load certification authority digital certificates into their local (certificate authority public key) repository.

so number #1 doesn't eliminate all possible attacks ... however, it actually addresses one of the identified security vulnerabilities/attacks ... as opposed to supplying "fixes" for things other than what is actually broken.

lots of past posts mentioning ssl domain name certificates .... including posts in long thread about the certificates providing more of a feeling of "comfort", as opposed to actually security, integrity, trust, etc.
https://www.garlic.com/~lynn/subpubkey.html#sslcert

note that #1, in attempt to close the gap between what the public associates with websites ... and what is SSL is validated for a website (i.e. some chance that the operator of a webserver reached by the domain name in the URL is the same as the owner of that domain name) ... it can actually close some of the gaps ... but in doing so, it increases the need for endpoints with some level of integrity ... and/or it leaves the end-points as possibly the weaskest link in the trust chain. also as outlined in #1, the possibly integrity improvement that comes from a local trust repository ... can also result in making digital certificates even more redundant and superfluous (doesn't reduce the need for public key operations ... just further reduces the need for digital certificates as a trust mechanism) ... this is similar to other examples where improving levels of trusts, also reduce the need for digital certificates as a trust mechanism ... misc. related posts on the subject
https://www.garlic.com/~lynn/subpubkey.html#catch22

Failure of PKI in messaging

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Failure of PKI in messaging
Date: Tue, 13 Feb 2007 08:35:17 -0700
To: Ian G <iang@xxxxxxxx>
CC: Steven M. Bellovin <smb@xxxxxxxx>,  Matt Blaze <mab@xxxxxxxx>,
James A. Donald <jamesd@xxxxxxxx>,
   Cryptography <cryptography@xxxxxxxx>
Ian G wrote:
Actually, there are many problems. If you ask the low-level crypto guys, they say that the HI is the problem. If you ask the HI guys, they say that the PKI concept is the problem. If you ask the PKI people, they say the users are not playing the game, and if you ask the users they say the deployment is broken ... Everyone has got someone else to blame.

They are all right, in some sense. The PKI concepts need loosening up, emails should be digsig'd for authentication (**), and the HI should start to look at what those digsigs could be used for.

But, until someone breaks the deadly embrace, nothing is going to happen. That's what James is alluding to: what part can we fix, and will it help the others to move?

iang

** I didn't say digital signing ... that's another problem that needs fixing before it is safe to use, from the "ask the lawyers" basket.


looking at the ssl domain name certificate uptake scenario ... there was a combination of things ... lots of publicity so that consumers perceived it providing some benefit, merchants perceiving that the consumers would feel better about it ... and therefor (for merchants) that it was worthwhile to shell out the money ... and lots of financial interests providing for publicity and support to have it ubiquitously deployed (to encourage merchants to shell out the money). lots of past posts mentioning the whole ssl domain name certificate scenario
https://www.garlic.com/~lynn/subpubkey.html#sslcert

part of the problem was that the PKI financial model is out of kilter with standard business practices. nominally a relying party has some sort of relationship with the certifying agency (i.e. what they are relying on) and there is exchange of value between the two parties.

In the standard PKI model, there frequently is absolutely no relationship between the relying party and the certifying agency. The "owner" of the digital certificate is paying the certifying agency ... not the relying party ... so there is typically no exchange of value between the certifying agency and the relying party ... and therefor the relying party has no foundation for actually relying on the certifying agency.

In early 90s ... there was some attempt to sidestep the lack of business foundation for PKI ... by defining X.509 identity certificates, frequently grossly overloaded with personal information and then getting gov. regulations mandating the certificates. There were also attempts to up the ante with semantic confusion attempting to equate "digital signatures" with "human signatures". misc. past posts about helping word smith various electronic signature legislation and/or the wide divide between "digital" and "human" signatures.
https://www.garlic.com/~lynn/subpubkey.html#signature

Remember that the (late 80s and) early 90s (with the attempts at ISO x.509 identity certificates) was also in the period when you saw various institutions and govs. mandating the elimination of the internet and its replacement with ISO (OSI model) networking standards.

one might even contend that in the ssl domain name certificate scenario ... that once all the hype and publicity is stripped away ... that a fundamental issue is that the "relying party" has absolutely no recourse with regard to the certifying agency when things go wrong (which would exist in normal business relationship between two parties). That the "padlock" symbol is purely a representation of the hype and publicity ... and not a fundamental business foundation.

recent thread about one of the major, fundamental justifications for ssl domain name certificates ... countermeasure to man-in-the-middle attacks ... and not being as effective as originally advertised:
https://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL

Failure of PKI in messaging ... addenda

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Failure of PKI in messaging ... addenda
Date: Tue, 13 Feb 2007 09:41:27 -0700
To: Ian G <iang@xxxxxxxx>
CC: Steven M. Bellovin <smb@xxxxxxxx>,  Matt Blaze <mab@xxxxxxxx>,
    James A. Donald <jamesd@xxxxxxxx>,  Cryptography <cryptography@xxxxxxxx>
re:
https://www.garlic.com/~lynn/aadsm26.htm#32 Failure of PKI in messaging

another way of looking at the issue is somewhat alluded to in this blog post
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minium liability, the CA trap, the market in browswer governance

somewhat contrasting SSL domain name certificate with association branded payment instruments.

the association logos also promote a feeling of comfort for people doing transactions ... but they have quite a bit of regulatory and policy standing behind those transactions for the benefit of the consumer ... something that you don't find in any of the ssl domain name certificate operations.

at least in some of the PKI publicity and hype ... the concept was conveyed that a relying party could base trust purely on a digital certificate ... that the existence of a digital certificate provided all the trust that anybody would ever need. however, there is a big gap in the level of recourse provided to a consumer using an association branded payment mechanism ... and the recourse provided to a consumer (relying party) by the existence of a digital certificate.

i would contend that basic fundamental asymmetric cryptography defined business process that allowed an individual to somewhat equate digitally signed electronic communication nearly equivalent to having face-to-face communication with an individual; aka it provided for authentication and integrity. there was no sense of "trust" ... the concept of trust was something that was associated with an individual or entity ... digitally signature somewhat put electronic communication on level playing field with face-to-face communication ... allowing it to be associated with a specific individual or entity. The issue of "trust" was separate from being able to depend on that equivalence.

this starts out purely as certificate-less operation
https://www.garlic.com/~lynn/subpubkey.html#certless

or this email from 1981 discussing using public key for secure communication
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

various PKI related publicity and hype from the 90s basically attempted to equate digital certificates (added to an underlying public key operation) would actually provide the basis for "trust" between two parties that had no previous interaction (aka this is the letters of credit/introduction from the sailing ship days scenario).

part of the issue was that there was frequently nothing that actually provided recourse to the parties in the event that something didn't go quite as expected (which is present in the association branded payment mechanisms). such publicity/hype may also account for any confusion that ssl domain name certification ... while only the basis for the owner of a domain name is likely also the operator of a webserver (addressed by that domain name) ... rather than actually the basis for a webserver that a person thinks they are talking to is actually the webserver they are talking to.

Failure of PKI in messaging

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Failure of PKI in messaging
Date: Wed, 14 Feb 2007 09:16:27 -0700
To: Leichter, Jerry <leichter_jerrold@xxxxxxxx>
CC: Ian G <iang@xxxxxxxx>,  "Steven M. Bellovin" <smb@xxxxxxxx>,
    Matt Blaze <mab@xxxxxxxx>, "James A. Donald" <jamesd@xxxxxxxx>,
Cryptography <cryptography@xxxxxxxx>
Leichter, Jerry wrote:
It's interesting to follow up on this idea, because it shows just how profound the problem is. Imagine starting a business that ran a PKI and did business the old way: You would charge someone *presenting* an alleged certificate for an "OK". The "OK" would, for the fee paid, provide insurance against the possibility of fraud. (Presumably, the fee would be based on the size of the insured transaction and level of experience and trust you have in the signing party.) It's to your advantage to have many parties whose signatures you vouch for, since that's what brings you customers; so you probably don't charge that side of the business - though it helps someone to have a "high trust" signature, since their customers will like paying a lower premium to do assured business with them, so you could charge on that side in some cases. But, unlike the case today, since your own money is at stake if you vouch for someone untrustworthy, you can't just go hand certs out to anyone who shows up at your door.

re:
https://www.garlic.com/~lynn/aadsm26.htm#32 Failure of PKI in message
https://www.garlic.com/~lynn/aadsm26.htm#33 Failure of PKI in messaging ... addenda

note that merchant interchange fee works this way ... i.e. the merchant wanting to know whether it gets paid when you present your card

recent posts with some interchange fee references
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007b.html#64 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#18 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007

doing the original deployment of what currently has come to be called electronic commerce, there was some investigation whether the payment infrastructure would issue certificates ... since they were already certifying merchants for processing of payment transactions (and the digital certificates then become representation of that certification). As mentioned before, merchants were already paying fairly hefting interchange fee to effectively insure consumer transactions ... that would have somewhat boxed-in/capped fees for ssl domain name certificate operations ... which weren't providing anything ... other than a lot of publicity and hype convincing public that they should feel good about digital certificates ... previously referenced posting in this blog
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance

as i've often mentioned before ... this is probabily why the fed gov. PKI has GSA signing contracts with certification authorities ... effectively making them agents of the federal gov. ... so there is avenue for recourse and business reliance between the federal gov as the relying party and the fedreal gov as the certificate issuing operations (thru their agents via contractual relationship) ... i.e. effectively a relying party PKI operations
https://www.garlic.com/~lynn/subpubkey.html#rpo

the argument then is that in an online environment, the relying-party digital certificates are redundant and superfluous. The two diminishing PKI market segments are then

1) the original design point for digital certificates, situation where the relying party has no repository of their own regarding prior relationship with the certified entity and/or have no timely connectivity to a certifying agency

2) no-value operations where the value of the transaction can't justify relying parties keeping their own records and/or doing a real-time transactions.

both of these remaining PKI market segments are rapidly shrinking as (internet) online connectivity becomes ubiquitous and as the costs of dataprocessing and networking continues to drop.

as mentioned numerous times, in effect, x9.59 financial standard just augmented existing payment transactions with digital signature for authentication and integrity. there were no requirement for digital certificates ... for a wide variety of reasons ... in addition to digital certificates being redundant and superfluous ... the digital certificates also represented an enormous payload and processing bloat that provides no fundamental added value
https://www.garlic.com/~lynn/subpubkey.html#bloat

the x9.59 consistent application of digital signature for authentication and integrity ... w/o requiring any certificates
https://www.garlic.com/~lynn/subpubkey.html#certless

also eliminated simply "knowing" the associated account number as a vulnerability ... that then eliminates a lot of the risk currently associated with phishing and data breaches. x9.59 didn't eliminate phishing and data breaches .... it just eliminated attackers being able to utilize a lot of the acquired information for fraudulent purposes.

With a pervasive use of SSL in the world today as support for electronic commerce ... primarily to hide account numbers during transit thru the internet ... x9.59 basically eliminates that need .... effectively substituting authentication and integrity for encryption (used to hide the account number).

So a level set ... rather than asking how to fix PKI for messaging ... since there are a lot of process and practices effectively result in its failure ... start at a simpler level regarding what are the authentication requirements for messaging. Digital signatures and public keys might then be looked at for satisfying those authentication requirements ... w/o necessarily requiring the heavy-weight bloat and business process overhead related to PKI deployments.

misc. past posts mentioning the GSA PKI scenario where contracts with certifying authorities effectively make them agents of the federal gov (creating a recourse and basis for relying)
https://www.garlic.com/~lynn/aepay10.htm#19 Misc. payment, security, fraud, & authentication GAO reports (long posting)
https://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
https://www.garlic.com/~lynn/aadsm18.htm#7 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
https://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
https://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)

Failure of PKI in messaging

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Failure of PKI in messaging
Date: Fri, 16 Feb 2007 09:28:17 -0700
To: John Levine <johnl@xxxxxxxx>
CC: cryptography@xxxxxxxx,  jamesd@xxxxxxxx
John Levine wrote:
It doesn't do anything about the obvious attack path of phishing credentials from the users to stick bogus trusted entries into their accounts. My examples showed all sorts of benign looking situations in which users provide their credentials to parties of unknown identity or reliability.

part of x9.59 financial standard
https://www.garlic.com/~lynn/x959.html
https://www.garlic.com/~lynn/subpubkey.html#x959

was to consistently require (digital signature) strong authentication and integrity on all transactions. as a result, phishing, data breaches, security breaches (with regard to account numbers) was eliminated as risk vector (account numbers could be divulged, phished, breached, etc ... but couldn't be used for fraudulent purposes). this also eliminated needing SSL for electronic commerce transactions (as part of hiding account numbers). in the online model ... don't require independent stand-alone/offline paradigm credentials ... just need a reliable authentication mechanism that is reasonably resistant to attacks.

sort of as part the x9.59 effort ... in the later half of the 90s, was the aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads

as countermeasure to software private keys being easily compromised ... i.e. digital signature becomes a something you have authentication operation ... i.e. it represents having unique hardware token containing the private key that generates the digital signature.

the next issue was hardware token costs ... both the costs of individual hardware tokens ... as well as the aggregate infrastructure costs related to institutional centric model with each institution issuing their own hardware token.

the first part was addressed by eliminating everything thing from the chip that wasn't in direct support of (security) of something you have authentication ... and the other was moving from a "institution centric" hardware token to a person-centric hardware token. Moving to a person-centric hardware token also turns out to eliminate a bunch of institutional hardware token personalization costs. The objective was aggressive cost reduction gaining possibly two orders of magnitude on per chip .... and instead of requiring a unique hardware token effectively replacing every password a person currently uses ... just have one (or a small few) tokens per person. Institutional specific credentials go away ... since the increase the per chip issuing costs and tend to eliminate person-centric operation (resulting in unique chips per institution).

This makes the hardware token (something you have) authentication much more analogous to biometrics (something you are) authentication. The hardware token for digital signature ... is presented in very much the same way a RFID chip (with static number vulnerable to replay attacks) might be presented ... or a fingerprint is sensed (again w/o being subject to replay attacks) .... but not requiring any other infrastructure, institutional, or application specific processing (it becomes a single function ... authentication, unlimited multi-app ... for whatever apps require authentication ... implementation). past posts about 3-factor authentication paradigm
https://www.garlic.com/~lynn/subintegrity.html#3factor

A couple of the remaining vulnerabilities are
  1. social engineering attacks getting victim to directly perform operations on behalf of the attacker.
  2. direct chip attacks to give up private key
current phishing tends to be convincing the person that they have to divulge some piece of information to verify and/or in support of other operations. the attacker then uses the information to perform fraudulent transactions w/o the victims knowledge. social engineering to perform operations on behalf of the attacker would tend to raise alarms in more peoples minds and possibly has less fraud ROI ... since it would presumably require more effort on the attacker's behalf for each fraudulent transactions. another possible social engineering operation is to convince the individual to "return" their hardware token (possibly as part of some required exchange operations). This would be easier done with the institutional-centric model ... since the victims would associate the token with the institution ... rather than believing they "owned" the token (in a person-centric model).

the issue in direct chip attacks is attempting to keep the cost of the attack somewhat higher than reasonable expected returns for the attacker ... i.e. part of this is parameterised risk management. the other is try and have the various chip attacks reasonably take longer than the typical lost/stolen reporting interval ... i.e. associated with an online transaction model. If the chip attacks cost more than the reasonable return to the attacker ... or the attack typically takes longer than avg. remaining lifetime before a lost/stolen report deactivates the chip. In the parameterised risk management scenario ... the risk profile is registered for each kind of chip ... while there is possibility of a single kind of chip serving all possible operations ... there may be a case for multiple kinds of chips that have different costs and risk profiles. Some scenarios might require an individual to have a (person-centric) chip with a significantly better risk profile (being able to perform transactions with values up to the limit of a particular kind of chip risk profile).

This may not provide extensive countermeasures to the possible kinds of attacks ... but it may be sufficient to provide countermeasures to 99percent of the current attacks (and make many of the remaining kinds of attacks financially unattractive).

In the past, i've somewhat facetiously stated that the aads chip strawman with person-centric approach and aggressive end-to-end cost reduction could reduce fully loaded hardware token infrastructure deployment costs by four orders of magnitude (reducing both per chip costs as well as total aggregate number of chips for scenario where hardware token authentication becames pervasive, say replacement for all existing password/pin operations).

One of the scenarios is that there is currently a significant amount of operations around hardware token paradigm that approach it from the profit perspective ... as opposed to approaching it from the cost perspective ... suggesting that total, fully loaded hardware token deployment costs are potentially reduced by four orders of magnitude has downside effect on many visions of profit.

disclaimer ... neither of us are associated with the owners of the aads chip strawman patent portfolio
https://www.garlic.com/~lynn/aadssummary.htm

misc. past posts mentioning person-centric hardware token authentication paradigm
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
https://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
https://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005m.html#37 public key authentication
https://www.garlic.com/~lynn/2005p.html#6 Innovative password security
https://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
https://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
https://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
https://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
https://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
https://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing

New Credit Cards May Leak Personal Information

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: New Credit Cards May Leak Personal Information
Date: Fri, 16 Feb 2007 11:50:50 -0700
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
New Credit Cards May Leak Personal Information
http://news.yahoo.com/s/pcworld/20070216/tc_pcworld/129096;_ylt=A0WTUeOD9tVFrwkA7SwjtBAF

from above:
You may be carrying a new type of credit card that can transmit your personal information to anyone who gets close to you with a scanner.

The new cards--millions of which have been issued over the past year--use RFID, or Radio Frequency Identification, technology. RFID allows scanners to use radio signals at varying distances to read information stored on a computer chip.


... snip ...

this is somewhat discussed in recent post
https://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging

i.e. x9.59 eliminating divulged account number as a vulnerability ... effectively substituting authentication & integrity for privacy/confidentiality (leading to claim that x9.59 was privacy agnostic)
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#privacy

The other item mentioned in the article was leaking names. Part of the x9a10 financial standard working group ... starting in the mid-90s ... was taking into account of an EU-directive (from the period) that electronic point-of-sale transactions should be as anonymous as cash. Somewhat the x9a10 assertion was that name on credit card was required so that point-of-sale clerk could do additional authentication by matching that name with the name on various forms of identification. Given a sufficiently high integrity authentication implementation ... the additional forms of authentication could be eliminated and therefor the name on the card could be eliminated.

This also goes along with similar earlier discussions about RFID-enabled passposts
https://www.garlic.com/~lynn/aadsm25.htm#45 Flaw in RFID-enabled passports
https://www.garlic.com/~lynn/aadsm26.htm#0 Flaw in RFID-enabled passports (part 2?)

i.e. avoid unnecessarily spraying personal information all over the world
https://www.garlic.com/~lynn/aadsm26.htm#29 News.com: IBM donates new privacy tool to open-source Higgins

the parallel was drawn between these mechanisms deploying static data personal identification information infrastructures and the x.509 identity digital certificates from the early 90s ... also raising their own enormous privacy issues. In that period, there was even suggestions that the x.509 identity digital certificates could be overloaded with sufficient personal information that they could also serve as electronic driver licenses and passports.

In the x9.59/aads model ... simple strong authentication and integrity is used with sufficient countermeasures for things like replay attacks and other kinds of exploits ... eliminating requirements for significant amounts of additional personal information for transactions
https://www.garlic.com/~lynn/x959.html#aads

Threatwatch: $400 to 'own' your account

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 25, 2007 04:26 PM
Subject: Threatwatch: $400 to 'own' your account
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000869.html

so maybe you will enjoy this one ... slightly different approach ... but there have been a number of recent articles about many attacks are becoming quite a bit more focused

Security Reference Guide > How to Steal 80,000 Identities in One Day
http://www.informit.com/guides/content.asp?g=security&seqNum=243&rl=1

does overlap with

How to breach a company: Spies, Lies and KPMG
https://financialcryptography.com/mt/archives/000868.html

Usable Security 2007

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 25, 2007 04:47 PM
Subject: Usable Security 2007
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000852.html

and possibly related to the subject of "usable security in 2007", ... a thread that started out with "securing financial transactions a high priority for 2007"

with mention of a URL for original article in this post
https://www.garlic.com/~lynn/2006y.html#7

then a whole lot of posts ... a relatively recent one with a number news URL references to security breaches, skimming, and/or other attacks harvesting account information enabling fraudulent transactions (following also includes URL references to most of the rest of the thread):
https://www.garlic.com/~lynn/2007e.html#2

and a post in the thread from today:
https://www.garlic.com/~lynn/2007e.html#12

with some number of additional "news" URLs

Chip and pin fails to halt card fraud rise
http://edinburghnews.scotsman.com/edinburgh.cfm?id=291732007

from above:
SHOPS have seen a massive rise in credit and debit card crime since the introduction of chip and pin technology, according to a report published today.

The new system was hailed as virtually fraud-proof but a survey by the Scottish Grocers' Federation (SGF) suggests card crime has soared by more than 50 per cent since 2005.


... snip ...

Fraud, embezzling and financial crime
http://business.scotsman.com/topics.cfm?tid=946
Card-skim criminals have police stumped
http://www.portsmouthtoday.co.uk/ViewArticle.aspx?ArticleID=2075455&SectionID=455
Plans to cut card fraud 'too complex'
http://www.itnews.com.au/newsstory.aspx?CIaNID=46197&src=site-marq
Plans to cut card fraud 'too complex'
http://www.itweek.co.uk/vnunet/news/2183738/plans-cut-card-fraud-slammed
Plans to cut card fraud 'too complex'
http://www.whatpc.co.uk/vnunet/news/2183738/plans-cut-card-fraud-slammed
Warnings over 'complicated' anti-fraud card systems
http://www.tuvps.co.uk/news/articles/warnings-over-complicated-anti-fraud-card-systems-18065845.asp

Usable Security 2007

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 25, 2007 05:05 PM
Subject: Usable Security 2007
Blog: Financial Cryptography
and for even further topic drift ...
https://www.garlic.com/~lynn/aadsm26.htm#38

for a totally different angle (sounds like an April 1st story? or something out of truth is stranger than fiction)

Fraud victims told not to go to police
http://www.computeractive.co.uk/computeractive/news/2183192/cheque-card-crimes
gone 404 ... but lives on at wayback machine
https://web.archive.org/web/20070302123100/http://www.computeractive.co.uk/computeractive/news/2183192/cheque-card-crimes

from above:
People will no longer be able to report cheque or card fraud or theft to the police under new rules being introduced by the Government.

From 1 April 2007, anyone who is a victim of this type of crime will be told to report it to their bank or building society and not police.

It will now be up to financial institutions to report such crimes to the police, which has lead to fears official figures will not truly reflect the seriousness of the problem.


... snip ...

PKI: The terrorists' secret weapon

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PKI: The terrorists' secret weapon
Date: Wed, 14 Mar 2007 10:22:35 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx
Peter Gutmann wrote
-- Snip --

As Carl Ellison put it, "Plenty of PK, precious little I".


slightly related URL from this morning

Browser Certs Can't Force Adherence
http://www.networkcomputing.com/channels/security/showArticle.jhtml?articleID=198000131

in the past, i've repeatedly asserted that the "I" in PKI filled a need related to letters of credit/introduction left-over from the offline, sailing ship days.

In on online world, such "I" tends to be redundant and superfluous ... typically representing an (expensive) duplication of other facilities.

Another way of looking at it is that typically cryptography has represented some aspect of security ... and frequently the common wisdom is that security is something that is best when built into the basic core business processes and infrastructure ... rather than some independent add-on. This possibly has contributed to failure of most attempts to create large revenue flow for some independent crypto/security feature (which frequently is a characteristic of PKI deployments).

An example is some early to mid 90s proposed PKI deployments as an electronic driver's license. The (driver's license) PKI certificate supposedly would be grossly overloaded with personal information ... creating enormous privacy issues. Reliance on information in the (PKI electronic) driver's license would be substituted for the growing use of (online) real-time checks .... along with eliminating any of the information that was becoming available from real-time checking (outstanding warrants, revocation, overdue parking tickets, etc). Any claims as to real-time checks still could be done, further highlighted the PKI part being a significantly expensive redundant and superfluous (add-on) operation.

lots of past references to certificate-less operation ( PK w/o the I )
https://www.garlic.com/~lynn/subpubkey.html#certless

PKI: The terrorists' secret weapon (part II)

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: PKI: The terrorists' secret weapon (part II)
Date: Wed, 14 Mar 2007 13:03:09 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm26.htm#40 PKI: The terrorists' secret weapon

so the other way of thinking about the "I" in PKI is that basically PK is an Authentication mechanism, the "I" frequently stands for attempting to move upstream in the value-chain revenue flow to Identification.

several issues: lots of past posts about purely PK Authentication operation w/o needing any stale, static, redundant and superfluous "I" (infrastructure and/or Identification) operation
https://www.garlic.com/~lynn/subpubkey.html#certless

"Dilemmas of Privacy and Surveillance" report launched

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: "Dilemmas of Privacy and Surveillance" report launched
Date: Wed, 28 Mar 2007 12:43:50 -0600
To: dave@xxxxxxxx
CC: ip@xxxxxxxx
Brian Randell wrote
Dave:

The (UK) Royal Academy of Engineering has just issued a report on "Dilemmas of Privacy and Surveillance" that will I trust be of considerable interest to IP.

From their press release at:

http://www.raeng.org.uk/news/releases/shownews.htm?NewsID=378
....
The full report is at:
http://www.raeng.org.uk/policy/reports/pdf/dilemmas_of_privacy_and_surveillance_report.pdf


this is somewhat the x.509 identity digital certificate scenario from the early to mid-90s. By the mid-90s most organizations had realized that identity digital certificates, typically grossly overloaded with personal information represented significant privacy and liability issues. What you saw at that time was many organizations retrenching to what they called relying-party-only certificates ... containing nothing more than some sort of database lookup index and a public key. lots of past posts mentioning relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

in part because there had been so much information distributed that the only way to provide security was via digital certificates.

however, it was trivial to demonstrate that in all of these online scenerios ... that the digital certificate was redundant and superfluous. the original scenario for digital certificates was the electronic analogy to the offline sailing ship days involving physical credential/certificates/licenses or things like letters of credit/introduction ... for secure offline distribution of information. in the transition to online environment such instruments become largely redundant and superfluous.

lots of past posts referring to using public key digital signatures for authentication .... w/o requiring digital certificates for secure offline information distribution
https://www.garlic.com/~lynn/subpubkey.html#certless

similar discussion occurred in this earlier thread (which was also appeared to this mailing list)
https://www.garlic.com/~lynn/aadsm25.htm#46 Flaw exploited in RFID-enabled passports

the same philosophy was used in the x9.59 financial standard ... requiring authentication and authorization ... but not identification
https://www.garlic.com/~lynn/x959.html#x959

in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. part of a recent thread discussing x9.59 financial standard and some of the other events that went on in the mid-90s ... and how it continues to impact things today
https://www.garlic.com/~lynn/2007f.html#72 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007

in fact, in the mid-90s, we claimed that x9.59 was highly secure, contained countermeasures to large variety of known vulnerabilities and was privacy agnostic ... other posts mentioning x9.59
https://www.garlic.com/~lynn/subpubkey.html#x959

Cost of an identity

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 28, 2007 05:03 PM
Subject: Cost of an identity
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000877.html

some cross over from another forum

We can have 'win-win' on security vs. privacy, says Acadamy
http://www.raeng.org.uk/news/releases/shownews.htm?NewsID=378

Dilemmas of Privacy and Surveillance Report
http://www.raeng.org.uk/policy/reports/pdf/dilemmas_of_privacy_and_surveillance_report.pdf

some comments
https://www.garlic.com/~lynn/aadsm26.htm#42

Governance of anonymous financial services

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Governance of anonymous financial services
Date: Fri, 30 Mar 2007 16:18:05 -0600 To: Ian G <iang@xxxxxxxx>
CC: Steve Schear <s.schear@xxxxxxxx>, cryptography@xxxxxxxx
Ian G wrote:
E.g., Ricardian contracts (my stuff) take the user agreement as a document and bind it into each transaction by means of the hash of the contract; they also ensure various other benefits such as the contract being available and readable to all at all times, and the acceptability of same, by the simple expedient of coding the decimalisation into the contract. Ensuring that the contract is readable, applicable and is available to all is a huge win in any court case.

Other governance tricks: the usage of signed receipts can be used to construct a full audit of the digital system. Also, signed receipts are strong evidence of a transaction, which leads by some logic to a new regime which we call triple entry accounting. This dramatically changes the practice of accounting (which feeds into governance).

With DB side, one trick is to use psuedonym accounts for the basis, and this allows no-loss protocols to be created. Again, this is useful for governance, because if you have a lossy protocol, you have a potential for fraud.


we had done something analogous in the x9.59 financial standard. the x9a10 financial standard group had been given the requirement to preserve the financial infrastructure for all retail payments.
https://www.garlic.com/~lynn/x959.html#x959

digital signature on the transaction itself provided for end-to-end strong authentication (armoring payment transaction as countermeasure to various kinds of replay attacks ... as have been in the news recently related to large data breaches and then being able to subsequently use the information for fraudulent transactions).

one of the "problems" was that some of the other attempts at PKI-related payments protocols in that period ... were creating enormous (two orders of magnitude) processing and payload bloat
https://www.garlic.com/~lynn/subpubkey.html#bloat

one of the implied x9a10 requirements was efficiency, i.e. mechanism that could be deployed in ALL environments (internet, point-of-sale, cellphone, etc) ... and needed to be highly concerned about processing and payload efficiency.

the actual transaction is digitally signed ... and it is also the thing that is authorized, logged, archived, audited, etc.

so part of x9.59 provided for a hash of the receipt (contract, bill-of-materials, sku data, "level 3" data, etc) as part of the digitally signed payload (as opposed to including the whole receipt). Then in any subsequent dispute, if both parties didn't produce identical receipts ... the hash from the audited/logged/archived transaction could be used to determine the valid/correct receipt.

While the receipt wasn't part of the actual audited/archived/logged transaction, the process provided a mechanism (in cases of disputes) for establishing the legitimate receipt.

we claimed privacy agnostic for x9.59 ...
https://www.garlic.com/~lynn/subpubkey.html#privacy

i.e. there was an account number in protocol but the degree that any jurisdiction required a binding between an account number and an individual was outside the x9.59 protocol. x9.59 was designed so that it could be used for credit, debit, stored value, ach, etc. In many jurisdictions, credit & debit can have some "know you customer" requirements for financial institutions (binding between individuals and account numbers) ... however there was 1) no requirement to divulge such bindings during retail transactions and 2) x9.59 applies equally well to stored-value retail transactions (where there is much less frequently a requirement imposed for "know your customer").

Cost of an identity

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 31, 2007 08:31 AM
Subject: Cost of an identity
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm26.htm#43 Cost of an identity

of possible some interesting additional drift ... response to comment in a mainframe n.g.
https://www.garlic.com/~lynn/2007g.html#19 T.J. Maxx data theft worse than first reported

in the response ... i even made reference to one of the analogies made in this thread

and then a followup
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported

the followup has reference to news item claiming that the exploit wasn't copying transaction log ... but skimming the transaction as it was being processed. the original comment somewhat implied that the problems would all go away ... if merchants stopped storing account numbers (in transaction logs). however, this latest (largest) exploit may not have involved transaction logs at all.

The Founder Paradox

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 31, 2007 09:06 AM
Subject: The Founder Paradox
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000871.html

could consider analogous problem in Boyd's characterization of issues in corporate america stemming from training executives had gotten as young officers going into ww2.

the issue was that the country had to deploy an enormous number of inexperienced and relatively untrained personal. the solution was to create a rigid, top/down command & control structure ... attempting to leverage the few skilled individuals that were available.

later, as these young officers started to populate corporate america ... they brought along with them the rigid, top/down command & control structure paradigm ... based on original premise that it is necessary in order to deal with (possibly large numbers of) inexperienced and unskilled individuals.

some recent posts on the subject in another thread:
https://www.garlic.com/~lynn/2007e.html#45 time spent/day on a computer
https://www.garlic.com/~lynn/2007e.html#55 time spent/day on a computer
https://www.garlic.com/~lynn/2007f.html#41 time spent/day on a computer

one of boyd's observations was that the rigid, top/down, command & control structure required something like 12 percent officiers ... he contrasted this with the german army with only something like 3percent officers

misc. past posts mentioning boyd
https://www.garlic.com/~lynn/subboyd.html#boyd
and lots of URLs from around the web mentioning boyd
https://www.garlic.com/~lynn/subboyd.html#boyd2

SSL MITM-attacks make the news

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: SSL MITM-attacks make the news
Date: Mon, 02 Apr 2007 11:35:31 -0600
To: cryptography@xxxxxxxx
ABN Amro compensates victims of 'man-in-the-middle' attack
http://www.finextra.com/fullstory.asp?id=16750

from above:
Four ABN Amro customers activated a virus allowing a man-in-the-middle attack that overcame the bank's two-factor authentication. After the attack, ABN Amro removed an 'urgent payment' option from its Web site as a precaution, compensated the customers and launched a campaign to remind users about internet banking safety.

... snip ...

and lots of past posts mentioning MITM-attacks
https://www.garlic.com/~lynn/subintegrity.html#mitm

Governance of anonymous financial services

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Governance of anonymous financial services
Date: Tue, 03 Apr 2007 12:52:21 -0600
To: Ian G <iang@xxxxxxxx>
CC: Steve Schear <s.schear@xxxxxxxx>,  cryptography@xxxxxxxx
Ian G wrote:
OK, on the face of it, you seem to have been doing triple entry (with the twist of a hash). Actually I am not so sure that it is even twisted ... as you are simply saying that someone somewhere was logging the hash; but not who was storing the receipts.

To point: is this written up anywhere? <gollum> did I really ask that? ;)

I wrote this concept up in a paper and am very happy to expand to include other art and implementations, given more than copious free time...
http://iang.org/papers/triple_entry.html

I'm integrating (or should be) the work that Todd Boyle has done on accounting, because his concept is more rather than less analogous.


re:
https://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services

so applying x9.59
https://www.garlic.com/~lynn/x959.html#x959

mapping to iso 8583 (i.e. credit transactions, debit transactions ... and even some number of stored-value transactions carried by some point-of-sale terminal and ... at least part of the financial network)
https://www.garlic.com/~lynn/8583flow.htm

you have the standard iso8583 financial transactions with a x9.59 addenda ... that includes a digital signature, a hash of the receipt and some misc. other stuff.

existing infrastructure advises that both merchant and consumer retain (paper) receipts (in case of disputes). x9.59 financial standard didn't specify/mandate how that might be done ... but provided for support for applications for doing.

the financial transaction was already required to be archived/logged for all sorts of regulations and business processes (as evidence some number of recent breach references).

In the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments. In numerous other references I've mentioned that doing required taking into account all sorts of considerations as part of x9.59 standard (including countermeasures to fraudulent transactions from breaches), it had to be extremely lightweight because of numerous considerations when you are asked to consider ALL retail transactions (including looking forward to various c ontactless, wireless, cellphones, transit turnstyles, etc), and maximizing the optimal use of all the existing processes and flows.

In any case, as a result, the "x9.59" transaction would be logged/archived as part of existing standard financial transaction processes ... which includes the digital signature against the full transaction ... where the full transaction ... along with the digital signature is being logged ... including the receipt hash and the additional x9.59 specified fields.

the "receipt", that is hashed, isn't specified as part of the x9.59 protocol standard ... but is assumed to be whatever is necessary to support resolution, in case of any dispute (at least the equivalent of saying that both the merchant and consumer retained paper receipt copies in the case of dispute).

we actually may have done too good a job. a lot of efforts that have worked on doing similar or related efforts ... essentially viewed it as profit opportunities. the x9a10 standards worked view all the "stuff" as added expense ... to be aggressively eliminated as much as possible. For instance in the AADS chip strawman
https://www.garlic.com/~lynn/x959.html#aads

in the mid-90s, i would semi-facetiously say that we would take a $500 mil-spec part, aggressively cost reduce it by 2-3 orders of magnitude, increase its security/integrity, have it form-factor agnostic (as well as being able to meet contactless transit turnstyle requirements).

to compound the problem ... we also did a bit of work on being able to change the institutional-centric something you have authentication paradigm to a person-centric paradigm ... i.e. rather than having one "something" per institution ... you could have one (or a very few) "somethings" per person (could be viewed as creating the something you are biometric authentication analogy for something you have authentication). misc. past posts mentioning 3-factor authentication paradigm
https://www.garlic.com/~lynn/subintegrity.html#3factor

so having something that was aggressively cost reduced by 2-3 orders of magnitude, more secure ... and instead of having one per institution/environment (that a person was involved with), they would have only one (or a very few). overall (for all possibly environments requiring authentication) this could have represented possibly four orders of magnitude cost reduction (that many others were viewing as potential profit opportunity).

in any case, who would be the stake-holders interested in something that eliminates nearly all fraud and nearly all costs?

a few past posts mentioning working on change-over to a person-centric paradigm:
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
https://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
https://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
https://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
https://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing

Governance of anonymous financial services

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Governance of anonymous financial services
Date: Tue, 03 Apr 2007 15:25:15 -0600
To: Ian G <iang@xxxxxxxx>
CC: Steve Schear <s.schear@xxxxxxxx>,  cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services
https://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services

My wife has been gone five years and I've been gone for over a year (they had corporate re-org in Dec '05) ... and we have no rights/interest ... but they continue to trickle out
https://www.garlic.com/~lynn/aadssummary.htm

latest today (3Apr2007) ... hot off the press:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=1&p=1&f=G&l=50&d=PTXT&S1=7200749.PN.&OS=PN/7200749&RS=PN/7200749

Method and system for using electronic communications for an electronic contract

Abstract

A method and system for digitally signing an electronic contract document. An electronic communication contains an identifier, a message, which includes the document, and a digital signature generated with a private key of an asymmetric key pair (247). The identifier may be used to retrieve a corresponding public key (287) and account information pertaining to the sender of the message. The public key may be used to authenticate the sender and the message. A device containing the private key may be used to protect the privacy thereof. The device may also generate a verification status indicator corresponding to verification data input into the device. The indicator may also be used as evidence that the sender of a contract document performed an overt act in causing the electronic communication to be digitally signed. A security profile linked to the public key in a secure database indicates security characteristics of the device.


... snip ...

for a little drift ... slightly related to this recent posting in sci.crypt
https://www.garlic.com/~lynn/2007g.html#40 Electronic signature outside Europe

DNSSEC to be strangled at birth

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: DNSSEC to be strangled at birth.
Date: Sat, 07 Apr 2007 11:03:04 -0600
To: Dave Korn <dave.korn@xxxxxxxx>
CC: 'Paul Hoffman' <paul.hoffman@xxxxxxxx>,
    tls@xxxxxxxx,  cryptography@xxxxxxxx
Dave Korn wrote:
We already had this with PKI and SSL, and it basically failed. Works fine on a small scale in a tightly-disciplined organisation; fails totally to scale to Joe Internet-User.

one could claim that PKI failed ... especially in its trusted 3rd party scenario ... since it was an amazingly complex and expensive deployment to solve a rapidly vanishing problem.

the basic design point is the electronic analog for physical credentials, certificates, licenses used in the "offline" world ... or the electronic analog of letters of credit/introduction from the sailing ship days (and before) ... the trusted distribution of information for the benefit of relying parties that had no other recourse for the information.

in an online world ... a paradigm designed for trusted distribution of information for an offline world, rapidly becomes redundant, superfluous and obsolete (besides enormously NOT cost effective).

SSL was intended as countermeasures to two vulnerabilities 1) are you really talking to the server that you think you are talking to (among other things ip-address hijacking) and 2) evesdropping of information in transit.

The SSL solution to #1 was predicated on the end-user having knowledge of a trusted binding between the server he thought he was talking to and the URL for that server. The SSL protocol then provided the trusted binding between the URL and the server the user was actually talking to. That weak-link in all of this was current infrastructure where end-users frequently have very little knowledge of the binding between the server they think they are talking to and the URL for that server.

It isn't so much that SSL has failed to do what it was implemented to do, it is that SSL failed to take into account that part where end-users have very little knowledge of the relationship between servers and the URLs for those servers. It isn't so much a small-scale population that it works for ... it requires a (disciplined) population that maintains adequate knowledge of the relationship between servers and the URL for those servers. Even a well disciplined population is likely only to maintain knowledge of strong binding between servers and URLs ... for only a small number of servers and their corresponding URLs. The same population may be also be vulnerable when dealing with URLs and servers outside some well regulated domain.

these series of posts talk about eliminating PKI and digital certificates for SSL ... and going to real-time public key operations in the domain name infrastructure ... as countermeasure to ip-address hijacking (original SSL) as well as domain name hijacking (as well as providing mechanism for encrypting information while in transit).
https://www.garlic.com/~lynn/subpubkey.html#catch22

Aka the current domain name certification authority PKI-based paradigm has its root trust in the validity of the information at the domain name infrastructure. While the existing SSL/PKI related implementation was targeted at ip-address take-over ... it still remained vulnerable to domain name hijacking.

however, the real-time domain name public keys, still doesn't address the vulnerability of end-users typically not having knowledge of strong binding between the website they think they are talking to and the corresponding URL (making them vulnerable to website impersonation and social engineering attacks that get them to click on arbitrary URLs).

Solutions for these vulnerabilities ... typically involve some amount of additional trust operations by the users ... along the lines of local repository of trusted public keys with the corresponding trusted binding to trusted URLs (which starts to look somewhat like the PGP email public key repository). One of the issues for such solutions is that they lack the economic incentive for large scale deployment (i.e. there is no 3rd party taking in money selling digital certificates).

The One True Identity -- cracks being examined, filled, and rotted out from the inside

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 8, 2007 05:47 AM
Subject: The One True Identity -- cracks being examined, filled, and rotted out from the inside
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000882.html

so can some of this be merged into a comprehensive paradigm for the public ... which also has some spill over from a number of other recent threads

so in this (and other) thread:
https://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services
https://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
https://www.garlic.com/~lynn/aadsm26.htm#49 Governance of anonymous financial services

i claimed that the work on x9.59 financial standard protocol in the mid-90s ... attempted to take into account some sort of EU directive about financial transactions at point-of-sale should be as anonymous as cash.

the x9a10 financial standard working group, in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... resulting in x9.59
https://www.garlic.com/~lynn/x959.html#x959

we claimed that x9.59 was privacy agnostic ... the only thing exposed at retail point-of-sale was an account number. It was then up to various jurisdictions whether there was any association/binding for the account number. In many jurisdications there are "know you customer" requirements that at some point requires a binding between an account number and an individual ... at least for credit & debit transactions. "stored-value" account numbers are still allowed to be anonomous in many jurisdications ... all of these can be supported by a common x9.59 protocol.

for even more drift
https://www.garlic.com/~lynn/aadsm26.htm#47 SSL MITM-attacks makes the news
https://www.garlic.com/~lynn/aadsm26.htm#50 DNSSEC to be strangled at birth
https://www.garlic.com/~lynn/2007g.html#58 Can SSL sessions be compromised
https://www.garlic.com/~lynn/2007g.html#60 Can SSL sessions be compromized

part of the issue is that how an entity is referred to (identification) and what trust, privileges and permissions might be granted that entity are totally different operations. It may be possible to have a single, unique method of referring to an entity ... but that would never carry with it the sense of trust/privileges/permissions which are nominaly extremely context sensitive. This has been one of the places that "digital certificates" have frequently strayed into dangerous waters ... attempting to bolix up identification, authentication, trust, privileges, and permissions into one big mash.

so for slightly more drift, a scenario is to take address books, bookmarks, pgp key management, certificate management, etc ... and merge them all into a single (context specific) contact metaphor

rather than having to educate the public about what pgp keys are and certificates are ... they become a trust attribute related to contact. the downside is this somewhat commoditizes the whole PKI/certificate paradigm for the public. It is no longer a unique high-priced operation, it is significantly simplified as a contact attribute/characteristic (The CA is a "contact" and it can be trusted to provide some kinds of trusted information about other contacts).

(email) pgp key lookup and (URL) public key lookup at domain name system can appear as a single operation ... checking/validating the trust of a contact ... just another characteristic/attribute of contact.

the simplification is to take a single metaphor that the public is already used to dealing with and merging all the myriad of disparate operations into that single metaphor.

the claim can be made that trust hierarchy metaphors don't go over well with the public because it doesn't match how most of the public deal with the world.

however, it is fairly well established that the public can deal with the world within a contact metaphor ... where trust could then become an attribute within the contact metaphor (however, this may drastically minimize the heights that some institutions try to raise the status of trust to an extremely expensive independent paradigm).

the issue here is that the current SSL deployment fails to account for the large gap that exists in the publics' mind between webservers they think they are talking to and the URL that is used to contact those webservers (and SSL only provides a check on whether the webserver being talked to and the URL used to talk to the webserver are consistent).

contacts can provide a methaphor for the public ... that spans the gap. then there are two symbols that might be displayed for a URL ... one is its "trust" level symbol (from the contact repository) and the other is the padlock ... which is purely related to whether the transmission is being encrypted over the internet (i.e. the trust of the site and whether there is countermeasure for evesdropping are two independent characteristics).

Using consistent paradigm for all kinds of contacts ... then could also mean that there be a consistent metaphor/representation for trust and encryption across URLs, email, instant messages, etc.

contacts might include globally unique identifier ... but also have local, context specific trust, permissions, privileges, etc.

The One True Identity -- cracks being examined, filled, and rotted out from the inside

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 8, 2007 12:10 PM
Subject: The One True Identity -- cracks being examined, filled, and rotted out from the inside
Blog: Financial Cryptography
Iang wrote:
Lynn,

possibly, the notion of using a contact metaphor has been explored with the Bookmarks metaphor. The Petname concept has found some ease of implementation by merging with the Bookmarks in web browsers. And while Petnames are hard to describe, Bookmarks are easy.

When a user adds a bookmark, she names it how she wants. This becomes a petname to a resource, a local, user-defined-and-known private name. By adding a little crypto trickery (hash of the public key of the server) to the bookmarks database, then we create a secure petname and this can be used by a plugin to positively identify a repeat visit.

The concept works and works well (Petname Toolbar is a minimalist design, Trustbar also develops it further, and later generation toolbars have incorporated the idea). It requires a slight user training. One can criticise this on the basis that users don't do anything, and can't be trained at all; or one can say this is the best bang for buck that is currently available, for those who can be trained, if we assume that user information has to be tapped in some sense as a better or useful relationship.


re:
https://www.garlic.com/~lynn/aadsm26.htm#51

contacts (with address books) have frequently added several additional optional information. making single consistent implementation for all activity might simplify the web experience ... driving all from a single interface/metaphor.

some address books already have automatic adding email addresses ... but without additional information ... however the additional fields are there. so an equivalent might do something equivalent for URLs ... possibly starting only with ones that claim HTTPS. then additional fields might be optionally selected.

in some ways this might be viewed as analogous operation to IE domains ... but instead of being driven off the (security) domain metaphor (and specifying URLs for each domain) ... it is driven off a (single) contact metaphor ... selecting what optional information gets specified for a URL.

optional information could be policy collections ... analogous to IE domains ... and/or specific permissions.

the difference is that it changes from a security metaphor to a (single, consistent) contact metaphor.

Getting a bank's URL loaded into contacts list with various online banking related attributes ... then can start to close the existing (SSL) gap between the server that a user thinks they are talking to and the URL.

This would make web-based banking operate somewhat more like the financial packages (quicken, money, etc) ... where registration of the financial institution for banking is required (even tho under the covers the financial packages may be using SSL for encryption).

Also more analogous to operation of earlier online banking operations that had installed software with the necessary contact information for doing direct dialed operation.

In the mid-90s, there were a couple of financial institution presentations that mentioned that existing online banking software required the financial institution to directly support something like 50-60 different flavors of modem drivers (different modem products, different operating systems, etc) as well as have call-center support for dailin operation.

Transition of online banking (or other online operations) to "Internet" was enormous savings for the institution since it effectively outsourced all the online gorp to an external organization ... and the external organization was able to amortize the online connectivity across a broad range of (additional) offerings/services to the consumer.

This consolidating of a large number of offerings/services was an enormous cost savings to individual institutions and enormous benefit to the consumer ... but also created a large ambiquity about who the consumer was dealing with at any specific point in time (and SSL doesn't actually provide complete end-to-end coverage eliminating all of that ambiquity).

The consumer direct registering of attributes for specific contact ... would somewhat close the gap (left by SSL). It also removes some of the disintermediation(?) that was introduced by the internet and 3rd party CAs between the consumer and the institutions that they were dealing with (compared to earlier "direct" online software packages)

The problem is that could also be viewed as eliminating the excuse for 3rd party CAs charging institutions for digital certificates ... since all that could be subsumed by user specifically loading institution contact information (and SSL changed to directly use loaded public key in the contact information).

The One True Identity -- cracks being examined, filled, and rotted out from the inside

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 8, 2007 01:39 PM
Subject: The One True Identity -- cracks being examined, filled, and rotted out from the inside
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm26.htm#51
https://www.garlic.com/~lynn/aadsm26.htm#52

to even further extend the topic drift ... in the 90s, i gave a couple conference talks as well as a graduate student seminar at ISI (USC) that included the IETF editors organization.

It basically was that there had been a lot of protocols migrated from circuit-based infrastructure to Internet (packet) operation ... w/o taking into account that there were a lot of implicit characteristics of the end-to-end circuit operation that were lost in the transition to packet operation.

When we were called in to consult with a small client/server startup about doing payment transactions on their server (with some technology they had called SSL ... and since has frequently come to be called electronic commerse), we had "sign-off" on the server to payment gateway implementation (I somewhat facetiously joke is the original SOA implementation).
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

One of the things we specified was extensive "compensating procedures" (and added business critical dataprocessing features) as part of moving financial transaction operation from circuit-based operation to packet-based operation. We also tried to suggest that some similar stuff should be implemented in the browser to server interface ... however we would get back responses like "that is too complicated" ... and since we only had sign-off on the server/gateway implementation we couldn't force it.

some recent posts mentioning the topic:
https://www.garlic.com/~lynn/2007.html#15 SSL info
https://www.garlic.com/~lynn/2007.html#28 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007f.html#37 Is computer history taught now?
https://www.garlic.com/~lynn/2007g.html#38 Can SSL sessions be compromised?
https://www.garlic.com/~lynn/2007g.html#51 IBM to the PCM market

for other drift ... at the time I was doing some work with the RFC editor related to RFC index and consistency of information in STD1. That RFC index work continues and is at:
https://www.garlic.com/~lynn/rfcietff.htm

What to do about responsible disclosure?

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 9, 2007 03:05 PM
Subject: What to do about responsible disclosure?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000887.html

A little drift

Data Breach Notification Laws: A State-by-State Perspective
http://www.intelligententerprise.com/channels/infomanagement/showArticle.jhtml?articleID=198800638
Congress and Data breaches
http://computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=privacy&articleId=9015819&taxonomyId=84http://computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=privacy&articleId=9015819&taxonomyId=84&intsrc=kc_featamp;intsrc=kc_feat

this somewhat related to old security proportional to risk posting
https://www.garlic.com/~lynn/2001h.html#61

recent posts about having gotten exposed to some of cal. notification legislation (both opt-in/opt-out stuff related to privacy matters as well as breach stuff) when we were called into help wordsmith the electronic signature legislation.
https://www.garlic.com/~lynn/2007f.html#72 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#8 Securing financial transactions a high priority for 2007

The One True Identity -- cracks being examined, filled, and rotted out from the inside

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 11, 2007 05:34 PM
Subject: The One True Identity -- cracks being examined, filled, and rotted out from the inside
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000882.html

other posts in this thread:
https://www.garlic.com/~lynn/aadsm26.htm#51 The One True Identity -- cracks being examined, filled, and rotted out from the inside
https://www.garlic.com/~lynn/aadsm26.htm#52 The One True Identity -- cracks being examined, filled, and rotted out from the inside
https://www.garlic.com/~lynn/aadsm26.htm#53 The One True Identity -- cracks being examined, filled, and rotted out from the inside

recent article

IBM's Higgins project: anonymous authentication for all
http://arstechnica.com/news.ars/post/20070411-ibms-higgins-project-offers-anonymous-internet-logins.html

comments in another fora after an earlier item in Jan.
https://www.garlic.com/~lynn/aadsm26.htm#24 IBM donates new privacy tool to open-source Higgins

Threatwatch: MITB spotted: MITM over SSL from within the browser

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 12, 2007 12:17 PM
Subject: Threatwatch: MITB spotted: MITM over SSL from within the browser
Blog: Financial Cryptography
re
https://financialcryptography.com/mt/archives/000884.html

Boarding Pass Hacker Targets Bank of America
http://it.slashdot.org/it/07/04/12/1444204.shtml
slight paranoia: A Deceit-Augmented Man In The Middle Attack Against Bank of America's SiteKey Service
http://paranoia.dubfire.net/2007/04/deceit-augmented-man-in-middle-attack.html

from above:
Whereas a normal man-in-the-middle attack identically replicates the attacked site, a deceit-augmented man-in-the-middle attack may present the user with a slightly different user interface than the regular interface. Man in the middle (MiTM) attacks are not a new threat - they have been known about for a number of years, and phishers have already used them to target Citibank and other online banks.

... snip ...

and past reference:
https://www.garlic.com/~lynn/2007d.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/aadsm26.htm#47 SSL MITM-attacks make the news

Our security sucks. Why can't we change? What's wrong with us?

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 17, 2007 07:24 PM
Subject: Our security sucks. Why can't we change? What's wrong with us?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000893.html

as i've periodically mentioned before, we were brought into help word smith the cal (state) digital signature legislation ... and then later the federal legistlation
https://www.garlic.com/~lynn/subpubkey.html#signature

as part of that activity we were exposed to some of the disclosure/notification legislation work going on ... both with regard to the use of personal information as well as security breaches and data breaches. a few recent posts in various threads mentioning notification/disclosures
https://www.garlic.com/~lynn/2007f.html#72
https://www.garlic.com/~lynn/2007f.html#75
https://www.garlic.com/~lynn/2007g.html#8

this somewhat, subsequently also got us roped into co-author of x9.99 financial privacy related standard ... somewhat in support of that activity i had done a merged privacy taxonomy and glossary ... reference here
https://www.garlic.com/~lynn/index.html#glosnote

and for other topic drift, some other recent threads ... much more on the integirty and security side of the topic ... as opposed to the notification/disclosure side of the topic
https://www.garlic.com/~lynn/2007h.html#36
https://www.garlic.com/~lynn/2007h.html#37

and separate part/aspect (which touches slightly more on some of the business issues) in the same thread
https://www.garlic.com/~lynn/2007h.html#27
https://www.garlic.com/~lynn/2007h.html#28
https://www.garlic.com/~lynn/2007h.html#31

Our security sucks. Why can't we change? What's wrong with us?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 18, 2007 08:06 PM
Subject: Our security sucks. Why can't we change? What's wrong with us?
Blog: Financial Cryptography
recent article from yesterday

Banks must come clean on ID theft
http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2007/04/17/EDGEBOS87H1.DTL

from above:
Two separate studies recently reached conflicting conclusions: While one found that identity theft is on the rise significantly, the other reported that it is on the decline.

So which is it?


... snip ...

i had made a similar observation a month ago
https://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007

also referenced here
https://www.garlic.com/~lynn/2007h.html#48 Securing financial transactions a high priority for 2007

previous post in this thread
https://www.garlic.com/~lynn/aadsm26.htm#57

and my oft repeated reference to old post on security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

and in some of the existing environments the attackers can possibly outspend the defenders possibly as much as 100:1
https://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported

On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 19, 2007 12:11 PM
Subject: On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000895.html

note that the quote wasn't mine ... i found it in recent (san fran chronicle) newspaper article titled "Banks must come clean on ID theft" and posted the reference
https://www.garlic.com/~lynn/2007h.html#48 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/aadsm26.htm#58 Our security sucks. Why can't we change? What's wrong with us?

although I did note that in a couple posts from last month I had observed the relatively vast differences in various articles on how recent fraud numbers were interpreted.
https://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#62 Securing financial transactions a high priority for 2007

now today there are references to recent Schneier article:

Bad Security Driving Out the Good
http://it.slashdot.org/it/07/04/19/140245.shtml
How Security Companies Sucker Us With Lemons
http://www.wired.com/politics/security/commentary/securitymatters/2007/04/securitymatters_0419?currentPage=all

and for a little more drift, there is recent thread topic drift related to nothing succeeds like failure
https://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#33 sizeof() was: The Perfect Computer - 36 bits?

as well as somewhat similar reference in recent risk digest
http://catless.ncl.ac.uk/Risks/24.62.html

crypto component services - is there a market?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: crypto component services - is there a market?
Date: Thu, 19 Apr 2007 18:23:21 -0600
To: stefan.kelm@xxxxxxxx
CC: Cryptography <cryptography@xxxxxxxx>
Stefan Kelm wrote:
Here in Europe, e-invoicing very slowly seems to be becoming a (or should I say "the"?) long-awaited application for (qualified) electronic signatures. Since electronic invoices need to be archived in most countries some vendors apply time-stamps and recommend to re-apply time-stamps from time to time.

recent post/thread with some discussion of the business of digital certificates ... as distinct from either digital and/or electronic signatures.
https://www.garlic.com/~lynn/2007h.html#28 sizeof() was: The Perfect Computer - 36 bits?

one of the exploits for the "changing" the burden of proof scenario (mentioned in the above post) ... since the incentive is significant ... is where the merchant produces a digital signature plus corresponding digital certificate purported to be from the other party.

the underlying digital signature stuff was designed for providing authentication and integrity for the transaction. there was never any provisions for it to ever provide intent and/or handle the situation of establishing the inverse ... i.e. in traditional digital signature & digital certificate paradigm ... there is no way of proving what, if any, digital signature and digital certificate were originally appended to the transaction/invoice.

this somewhat gets into the area of non-repudiation services (where some of the trusted time-stamping have periodically wandered into) ... i.e. for individuals, digital signature isn't representative of a human signature and intent ... it is purely does (what digital signatures were originally designed for) authentication and integrity.

other parts of the same thread related to digital signatures
https://www.garlic.com/~lynn/2007h.html#20 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#22 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#26 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#27 sizeof() was: The Perfect Computer - 36 bits?

possibly being able to force changing of burden of proof ... is analogous to some past discussions about "dual-use" attack ... again where there was possibility of allowing digital signatures to wander into the arena of human signatures and intent ... a thread that started in this mailing list
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#27 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures

crypto component services - is there a market?

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: crypto component services - is there a market?
Date: Fri, 20 Apr 2007 13:46:35 -0600
To: stefan.kelm@xxxxxxxx
CC: Cryptography <cryptography@xxxxxxxx>
re:
https://www.garlic.com/~lynn/aadsm26.htm#60 crypto component services - is there a market

slightly related discussion of x9.59 financial standard protocol
https://www.garlic.com/~lynn/x959.html#x959

supporting hash of invoice in any dispute resolution ... thread from a couple weeks ago
https://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services
https://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services

where the x9.59 transaction is digital signed (and presumably logged/archived as part of various financial regulations).

In dispute, both parties can produce their version of any invoice (bill of materials, etc) and differences can be resolved by the hash included in the signed payment transaction.

In the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments. The x9.59 standards work faced a few issues, including

1) It was starting to dawn that x.509 identity certificates from the early 90s, frequently overloaded with personal information represented significant privacy and liability issues. As a result there was move to digital certificates that contained some sort of indirect (and/or obfuscated) lookup value ... and were frequently referred to as relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

however, it was trivial to show that in any situation where the indirection had to be used for some sort of lookup ... that the public key could be obtained in the same operation ... making the digital certificate redundant and superfluous

2) Some of the other digital signed work for financial transactions in the period ... the appending of a digital certificate to such a transaction was resulting in two orders magnitude payload and processing bloat (for something that was redundant and superfluous)
https://www.garlic.com/~lynn/subpubkey.html#bloat

3) The appending of the digital certificate is basically a paradigm operation that supports distribution of trusted information for offline operation (the electronic analog of physical credential, certificate, license, and/or letters of credit/introduction from sailing ship days and earlier). At the time we were working on x9.59 ... there were several claiming that the appending of digital certificates (to financial transactions) was needed to bring financial processing into the "modern age". Our reply was that moving from a fundamentally online infrastructure to an offline paradigm actually represented a regression of several decades. It was somewhat after that you started to see work on the rube goldberg OCSP standard.

....

In some respect ... trusted time-stamping is attempting to take the online financial transaction model where there are frequently strict regulations about archiving/auditing and extend it to other types of operations. In the x9.59 financial standard scenario ... the financial archiving/auditing infrastructure was extended to cover invoice, bill-of-materials, etc ... but simply adding their hash to the digital signed financial transaction (and at the same time avoiding the enormous payload and processing bloat seen in various other strategies).

Public key encrypt-then-sign or sign-then-encrypt?

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Public key encrypt-then-sign or sign-then-encrypt?
Date: Wed, 25 Apr 2007 17:26:28 -0600
To: cryptography@xxxxxxxx
Mads Rasmussen wrote:
Hugo Krawczyk [1] showed in the symmetric key setting that the encrypt-then-authenticate was the way to go about securing the integrity of an encrypted message.

What about the public key setting?

Jee Hea An, Yevgeniy Dodis and Tal Rabin claims that the order doesn't matter [2]. Encrypt-then-sign or sign-then-encrypt is equally secure. Is this really true? My feeling was that the principle from Krawczyk's paper should apply to the public key setting as well.


the discussion in this thread was about potentially long-lived document contents carrying digital signature for authentication and integrity. this is a more of a business issue than a traditional security/confidentiality issue
https://www.garlic.com/~lynn/2007h.html#15 asymmetric cryptography + digital signature
https://www.garlic.com/~lynn/2007h.html#21 asymmetric cryptography + digital signature

the contents plus digital signature might be encrypted for transmission purposes (or other confidentiality reasons).

one might contend that if the document has to always be kept encrypted ... for confidentiality reasons ... then it might be useful to apply the digital signature to the encrypted version.

however, if it is a long-term electronic document normally processed in clear-text ... then clear-text digital signature can be used for check of integrity and authentication (of the document contents) and it may only rarely or never require encryption for confidentiality

part of this is that in the symmetric key example ... encryption can be viewed as doing double duty for confidentiality and integrity .... with authentication a separate item. in the asymmetric key scenario, the digital signature is doing double duty for integrity and authentication ... with (encryption) confidentiality a separate operation ... in which, also using encryption for integrity can be viewed as redundant.

Public key encrypt-then-sign or sign-then-encrypt?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Public key encrypt-then-sign or sign-then-encrypt?
Date: Thu, 26 Apr 2007 07:36:00 -0600
To: cryptography@xxxxxxxx
Travis H. wrote:
Also there's a semantic issue; am I attesting to the plaintext, or the ciphertext? It's possible the difference could be important.

re:
https://www.garlic.com/~lynn/aadsm26.htm#62 Public key encrypt-then-sign or sign-then-encrypt?

there has been sporadic periods/attempts that effectively attempt to equate "digital signature" with "human signature" ... possibly because of semantic confusion since both terms contain the word "signature". This goes beyond digital signature being able to provide integrity and authentication (i.e. read, understood, approves, authorizes, and/or agrees).

we saw one such when we were called into help word smith the cal. state electronic signature (and later federal) legislation. misc. past posts
https://www.garlic.com/~lynn/subpubkey.html#signature

another scenario that can arise is dual-use attack ... where same private key is used to both digitally sign in authentication protocol (i.e. presented with random "challenge" from a server and private key automatically digitally signs the server presented value; the signing of the server presented random value is countermeasure to replay attacks against the server) and in the sense of human signature (read, understood, approves, authorizes, and/or agrees). The attacker injects a valid document in lieu of random data in an authentication protocol that automatically performs digital signatures.

In the 90s, there was some suggestion that possibly a payment protocol using digital signature ... in a PKI-based paradigm, the consumer would append a digital certificate indicating their agreement with the contents of what was being signed (as opposed to pure integrity and authentication). The choice of the appended digital certificate would be used to "prove" non-repudiation and subsequently also be the basis for changing the burden of proof in disputes. Since PKI-based paradigm don't provide for any integrity mechanism as to what digital certificate was originally appended ... there was possibly motivation (in such a PKI-based paradigm) for a relying-party to discover someplace in the world a copy of a signer's digital certification that would better suit the relying party's purpose (than the one that the signer actually appended) ... there would have been significant financial incentive to the relying party to change the burden of proof in disputes.

Since that period, the idea of PKI-based paradigms (and/or digital certificates) being used as basis for non-repudiation has been severely depreciated.

some of this from security acronym PAIN

P -- privacy (or sometimes CAIN, confidentiality)
A -- authentication
I -- integrity
N -- non-repudiation


encryption provides for privacy/confidentiality ... and possibly integrity.

digital signature provides for authentication and integrity

at various times in the past, some PKI-based paradigms have attempted to make claims that digital signatures also imply non-repudiation ... and could equate to imply intent and equivalence with human signature (read, understood, approves, authorizes and/or aggrees).

past posts mentioning dual-use attack and/or changing burdon-of-proof
https://www.garlic.com/~lynn/aadsm6.htm#nonreput Sender and receiver non-repudiation
https://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on
https://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#0 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#55 MD5 collision in X509 certificates
https://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
https://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/aadsm21.htm#35 [Clips] Banks Seek Better Online-Security Tools
https://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
https://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
https://www.garlic.com/~lynn/aadsm23.htm#33 Chip-and-Pin terminals were replaced by "repairworkers"?
https://www.garlic.com/~lynn/aadsm26.htm#60 crypto component services - is there a market?
https://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
https://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
https://www.garlic.com/~lynn/2001g.html#59 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2002g.html#69 Digital signature
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005.html#14 Using smart cards for signing and authorization in applets
https://www.garlic.com/~lynn/2005b.html#56 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#31 Public/Private key pair protection on Windows
https://www.garlic.com/~lynn/2005e.html#41 xml-security vs. native security
https://www.garlic.com/~lynn/2005g.html#46 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#6 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2005m.html#11 Question about authentication protocols
https://www.garlic.com/~lynn/2005o.html#3 The Chinese MD5 attack
https://www.garlic.com/~lynn/2005o.html#26 How good is TEA, REALLY?
https://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
https://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
https://www.garlic.com/~lynn/2005s.html#52 TTP and KCM
https://www.garlic.com/~lynn/2005v.html#3 ABN Tape - Found
https://www.garlic.com/~lynn/2006d.html#32 When *not* to sign an e-mail message?
https://www.garlic.com/~lynn/2006e.html#8 Beginner's Pubkey Crypto Question
https://www.garlic.com/~lynn/2006s.html#34 Basic Question
https://www.garlic.com/~lynn/2007h.html#28 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007i.html#23 John W. Backus, 82, Fortran developer, dies

Dr Geer goes to Washington

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 30, 2007 12:12 PM
Subject: Dr Geer goes to Washington
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000903.html

frequently there needs to be a paradigm shift ... i.e. building on soft limestone or unstable shale ... rather than having a strong foundation.

i was on a security panel several yrs ago with high-level executives from major after-market security add-on companies and made the analogy to the old after-market seatbelt paradigm ... that the only substantial way of addressing the opportunity is building in integrity into the underlying foundation ... and stop treating it as an after-market add-on (after-market add-on was better than nothing ... but it wouldn't be very effective at providing coverage for substantial portion of the market).
for a little drift ... also the analogy to the naked transaction/payment paradigm raised here several months ago
https://www.garlic.com/~lynn/subintegrity.html#payments

the current situation might also be compared to medical field where everything is treatment ... and there exist no preventive care & procedures (i.e. having clean water can do wonders for illnesses and death statistics) ... i.e. we are still in the dark ages compareable to bleeding the patient to let out the evil spirits.

At times, I'm even tempted to compare things to a medical treatment scenario where the doctor doesn't even bother to examine the patient ... just chooses a treatment at random.

Public key encrypt-then-sign or sign-then-encrypt?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Public key encrypt-then-sign or sign-then-encrypt?
Date: Wed, 02 May 2007 09:29:39 -0600
To: Florian Weimer <fw@xxxxxxxx>
CC: cryptography@xxxxxxxx
Florian Weimer wrote:
With sign, then encrypt, it's also possible that the receiver decrypts the message, and then leaks it, potentially giving the impression that the signer authorized the disclosure. There has been a fair bit of buzz about this confusion. But the lesson from that seems to be that signature semantics are very hard to agree upon, and most marginally successful standards sidestep the issue anyway, acting as a mere transport protocol.

re:
https://www.garlic.com/~lynn/aadsm26.htm#62 Public key encrypt-then-sign or sign-then-encrypt?
https://www.garlic.com/~lynn/aadsm26.htm#63 Public key encrypt-then-sign or sign-then-encrypt?

there is the issue for some kinds of operations of having integral authentication and integrity .... or integral authentication and privacy ... or integral privacy and integrity.

so there is the whole issue of semantic confusion with the term digital signature .... because it contains the word "signature" ... leading to confusion that it might somehow be related to human signature ... aka things like intent and a human having read, understood, agrees, approves, and/or authorizes.

on the other hand ... digital signatures can get into various kinds of dual-use attacks ... when the same private key is being used in a purely authentication protocol (server sends random data to be digitally signed ... as countermeasure to replay attack) ... and also in a authentication+integrity protocol ... where the contents being digitally signed is presumed to carry some sort of meaning (and that a digital just happens to be performed ... carries some additional implication other than authentication+integrity).

there is this slightly x-over thread from sci.crypt
https://www.garlic.com/~lynn/2007i.html#63 public key password authentication
https://www.garlic.com/~lynn/2007i.html#73 public key password authentication
https://www.garlic.com/~lynn/2007i.html#74 public key password authentication

where there is possibly the suggestion that if the only thing being performed is authentication (and doesn't require either integrity and/or privacy) ... then possibly a totally different protocol by utilized (rather than digital signature) ... to help minimize the apparent extensive (human) confusion where the same technology might be used for both authentication only operations as well as authentication plus integrity operations (and where having the word "signature" in the term also appears to contribute significant additional confusion).

however, in the x-over thread from sci.crypt ... i mention that if both authentication and integrity are both required ... that potentially if they are done as separate operation ... that there can be (security) openings provided to attackers for things like man-in-the-middle attacks.

in the "naked" transaction metaphor mentioned in these postings
https://www.garlic.com/~lynn/subintegrity.html#payments

it is possible that if authentication is performed separately from any integrity provisions applied to the actual transactions ... that it may be an opening for a man-in-the-middle attack (or other kinds of attacks)

More Tipping Point evidence - POS vendors sued

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 2, 2007 04:34 PM
Subject: More Tipping Point evidence - POS vendors sued
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000906.html

for some topic drift ... having worked on the original payment gateway using SSL to "hide" payment related information as fraud countermeasure (for what has since come to be called electronic commerce)
https://www.garlic.com/~lynn/subnetwork.html#gateway

but then got involved in x9a10 financial standard working group that in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments.
https://www.garlic.com/~lynn/x959.html#x959

one of the things looked at in x9a10 is defining x9.59 financial standard protocol to eliminate risk/fraud associated with exposure of things like account numbers, expiration dates, etc. recent post noting that eliminating the risk associated with exposing account numbers and expiration dates ... somewhat obsoleted the earlier work on electronic commerce that used SSL cryptography to hide the same information.
https://www.garlic.com/~lynn/2007i.html#65

which also goes back to long series of posts started here with regard to the naked payment/transaction metaphor (i.e. naked transactions tend to require quite a bit more hiding and protection than transactions that are more robust and armored)
https://www.garlic.com/~lynn/subintegrity.html#payments

then there is the somewhat related recent posts that somewhat raises the question whether or not some of the fraud problems is because of semantic confusion attempting to understand what various security procedures actually accomplish
https://www.garlic.com/~lynn/2007i.html#74
https://www.garlic.com/~lynn/aadsm26.htm#65

survey of RFC S/MIME signature handling

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 5, 2007 10:14 AM
Subject: survey of RFC S/MIME signature handling
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000905.html

when we were asked in to help word smith the cal state (and later federal) electronic signature act ... the lawyers had quite a bit to say about this ... some past posts
https://www.garlic.com/~lynn/subpubkey.html#signature

i've joked that it involves the (caused by) semantic confusion because the terms "digital signature" and "human signature" both contain the word "signature"

the whole idea that past certification events has anything to do with (future) intent, non-repudiation, and/or human signature (i.e. read, understood, agrees, approves, and/or authorizes) has been severely depreciated since the heyday of the enormous (semantic) confusion if the 90s.

furthermore, it can be considered that even bringing up anything to do with non-repudiation, intent, and human signature in conjunction with issuing a digital certificate is enormous misdirection and obfuscation.

the issue of certification authorities, certification process, and digital certificates are analogous to the letters of credit/introduction from the sailing ship days (and before) when the relying party had no other means of obtaining information about the party/stranger they were dealing with. in those days, relying parties realized that the letter of introduction might have something to do with the truth of what a stranger might possibly claim. However, the letter of introduction was specifically with respect to specific facts that were verified at the time the letter was written.

There was NEVER any implication that the act of certifying information included in the letter of introduction was in any way associated with the subject's subsequent human signature that carried with it any implication of intent, non-repudiation, read, understood, agrees, approves, and/or authorizes.

In fact, it was physically and temporal impossibility that the act of certifying some information at some point distant in the past had any bearing on the future human act of applying a (human) signature.

Subsequent work (after the 90s) in the area of intent, non-repudiation, having read, understood, agrees, approves, and/or authorizes ... all revolved around services that happened at the moment a signature was applied ... somewhat equivalent to having "witnesses" involved in the signing of a will (and severely depreciated any possible prior work in relating any past work of certification authorities to any future demonstration of intent).

In this subsequent work, there was nobody confused that the act of certification at some point in the past (which is what a digital certificate represents) .... was in any possible way related to the conditions around the future application of a signature. This would be on par with trying to make some connection between the issuance of a birth certificate being related to proving that some person had intended to sign a specific will. Part of the issue is that the two events; some certification and some signing (demonstrating read, understood, agrees, approves, and/or authorizes), are typically separated by quite a distance ... both physically and temporally.

H6.1: Designing (Security) Without Requirements is like Building a Road Without a Route Map to a Destination You've Never Seen

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 5, 2007 10:45 AM
Subject: H6.1: Designing (Security) Without Requirements is like Building a Road Without a Route Map to a Destination You've Never Seen
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000910.html

should i say pet-peeve?

the other aspect is not having done a detailed end-to-end threat and vulnerability analysis and then (not) stating exactly what is trying to be accomplished ... it is tempted to make a statement with regard to not knowing something ... that they don't even know that they don't know. related post about not knowing what they don't know
https://www.garlic.com/~lynn/aadsm26.htm#64 Dr Geer goes to Washington

not only is there the requirement to know what route the road is to transverse ... but there is a requirement to have detailed knowledge of the conditions involved in the route as well as what traffic the road is to carry.

for instance ... is part of the route subject to frost heaves ... and are specific countermeasures necessary. past post discussing frost heaves affecting road construction requirements:
https://www.garlic.com/~lynn/99.html#22 Roads as Runways Was: Re: BA Solves Y2K (Was: Re: Chinese Solve Y2K)
https://www.garlic.com/~lynn/2002i.html#28 trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#35 pop density was: trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002i.html#36 pop density was: trains was: Al Gore and the Internet
https://www.garlic.com/~lynn/2002j.html#42 Transportation
https://www.garlic.com/~lynn/2002j.html#68 Killer Hard Drives - Shrapnel?
https://www.garlic.com/~lynn/2003j.html#11 Idiot drivers
https://www.garlic.com/~lynn/2006h.html#45 The Pankian Metaphor

another part of road construction is knowing what kind of traffic will be involved ... for instance past posts discussing that road lifetime construction considerations are related to ton/axle loads for heavy trucks (traffic from automobiles and light trucks can be ignored) ... long winded past thread exploring the subject of heavy truck axle-load traffic affecting road construction
https://www.garlic.com/~lynn/2006g.html#5 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#6 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#10 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#12 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#15 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#19 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#26 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#32 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#35 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#46 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#49 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#53 The Pankian Metaphor
https://www.garlic.com/~lynn/2006g.html#54 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#5 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#6 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#23 The Pankian Metaphor

survey of RFC S/MIME signature handling

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 5, 2007 02:28 PM
Subject: survey of RFC S/MIME signature handling
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm26.htm#67 survey of RFC S/MIME signature handling

or to be (only slightly) more facetious ... require that all birth certificates to carry a disclaimer that the document in no way is met to carry any implication as to the validity of any signatures that the named person may place on wills (at any time in the future). the birth certificate disclaimer then would have to be extended to include the enumeration of all possible documents on which a person might place their signature.

WSJ: Soft evidence on a crypto-related breach

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 7, 2007 05:47 PM
Subject: WSJ: Soft evidence on a crypto-related breach
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000911.html

aside from the issues AADS and X9.59 financial standard protocol
https://www.garlic.com/~lynn/x959.html

providing transaction armoring for naked transactions
https://www.garlic.com/~lynn/subintegrity.html#payments

so they are no longer vulnerable to evesdropping and replay attacks
https://www.garlic.com/~lynn/subintegrity.html#harvest

there is this recent item:

New Weakness in 802.11 WEP
http://developers.slashdot.org/developers/01/07/27/1734259.shtml?tid=93

which claims that it has an attack against what is being proposed for WEP2.

the referenced website:
http://ebiquity.org/article.php?sid=189

may be suffering from having been "slashdot'ed" ... since it hasen't been responding.


AADS Postings and Posting Index, - previous - next - home