Misc AADS & X9.59 Discussions

AADS Postings and Posting Index, previous - home


2007: year in review
2008: The year of hack the vote?
Death of antivirus software imminent
Why Security Modelling doesn't work -- the OODA-loop of today's battle
Death of antivirus software imminent
Why Security Modelling doesn't work -- the OODA-loop of today's battle
Death of antivirus software imminent
Why Security Modelling doesn't work -- the OODA-loop of today's battle
Death of antivirus software imminent
Death of antivirus software imminent
Why Security Modelling doesn't work -- the OODA-loop of today's battle
Death of antivirus software imminent
#4.2 Simplicity is Inversely Proportional to the Number of Designers
Break the rules of governance and lose 4.9 billion
Break the rules of governance and lose 4.9 billion
Dutch Transport Card Broken
Dutch Transport Card Broken
Lack of fraud reporting paths considered harmful
Lack of fraud reporting paths considered harmful
Lack of fraud reporting paths considered harmful
Fixing SSL (was Re: Dutch Transport Card Broken)
Dutch Transport Card Broken
Dutch Transport Card Broken
Dutch Transport Card Broken
Fixing SSL (was Re: Dutch Transport Card Broken)
middle banking in a english muddle
Fixing SSL (was Re: Dutch Transport Card Broken)
Break the rules of governance and lose 4.9 billion
middle banking in a english muddle
Chip&PIN cards: 1 in 5 cloned?
Fixing SSL (was Re: Dutch Transport Card Broken)
Fixing SSL (was Re: Dutch Transport Card Broken)
How does the smart telco deal with the bounty in its hands?
on Revocation of Signing Certs and Public Key Signing itself
on Revocation of Signing Certs and Public Key Signing itself
H2.1 Protocols Divide Naturally Into Two Parts
Say it ain't so? MITM protection on SSH shows its paces
Attack on Brit retail payments -- some takeways
The Trouble with Threat Modelling
Format Wars: XML v. JSON
Attack on Brit retail payments -- some takeways
Trojan with Everything, To Go!
Trojan with Everything, To Go!
Realistic dynamics of contactless
Realistic dynamics of contactless
Realistic dynamics of contactless
The bond that fell to Earth
delegating SSL certificates
World's biggest PKI goes open source: DogTag is released
Price point
Liability for breaches: do we need new laws?
Liability for breaches: do we need new laws?
Pogo reports: big(gest) bank breach was covered up?
Pogo reports: big(gest) bank breach was covered up?
Liability for breaches: do we need new laws?
Signs of Liability: 'Zero Day Threat' blames IT and Security industry
Signs of Liability: 'Zero Day Threat' blames IT and Security industry
Who do we have to blame for the mortgage crisis in America?
Who do we have to blame for the mortgage crisis in America?
Information Security Vs. Businesss Resilience
Seeking expert on credit card fraud prevention - particularly CNP/online transactions
Is Basel 2 out...Basel 3 in?
Who do we have to blame for the mortgage crisis in America?
Is Basel 2 out...Basel 3 in?
Seeking expert on credit card fraud prevention - particularly CNP/online transactions
Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?
Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?
Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?
Which is the strongest currency in the world? Now? Projected for the next 3 years?
VCs have a self-destruction gene, let's tweak it
VCs have a self-destruction gene, let's tweak it
Paypal -- Practical Approaches to Phishing -- open white paper
What are the current INNOVATIVE ICT Security Services, that are in demand or highly marketable at the moment
"Designing and implementing malicious hardware"
Visa and MasterCard mandated PCI compliance as of Jan 1, 2008. I would like to get a feel or opinion on this subject
Fun with Data Theft/Breach Numbers
How do you define 'privileged access'?
How safe do you feel when using a debit or credit card?
(electronic commerce) SSL use
User interface, security, and "simplicity"
not crypto, but fraud detection
not crypto, but fraud detection
Can we copy trust?


2007: year in review

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: December 22, 2007 09:57 PM
Subject: 2007: year in review
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm27.htm#66 2007: year in review

some amount of new 40+ yr old technology is about server consolidation and being green

i.e.
http://www.garlic.com/~lynn/2007s.html#0 Marines look for a few less servers, via virtualization
http://www.garlic.com/~lynn/2007v.html#13 Ageing data centers limiting benefits of new technologies

however other activities involve virtual appliances (what we use to call service virtual machines) ... which are much simpler and targeted monitors. they are considered somewhat more secure because they are less complex and KISS.
http://www.garlic.com/~lynn/2007o.html#3 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007s.html#4 Why do we think virtualization is new?
http://www.garlic.com/~lynn/2007u.html#39 New, 40+ yr old, direction in operating systems

the new 40+ yr old technology is also being touted as addressing some of the existing cyber vulnerabilities. part of (simpler) virtual machine technologies ... is it can provide very strong partitioning (approaching "air gapping"). One of the major compromising vectors is via browser interaction on the internet. One of the internet browsing scenarios involves creating a brand new targeted browsing environment for each session ... which goes poof and evaporates (along with any compromises) when done.
http://www.garlic.com/~lynn/2007q.html#64 Virtual Browsers: Disposable Security

many of these virtualizing techniques date back nearly 40 yrs. some slight different topic drift (I disclaim knowledge of it at the time):
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

Now on the other hand ... given control of the machine ... virtual machine technology can hide in lots of ways that conventional compromises can't. The referenced malware discussion points out case where the bad guys are looking to see if they are in such an environment controlled by the good guys. However, there has also been discussions about potential for the reverse ... i.e. the bad guys in control ... for instance in machines located in public environments (and figure they can evade detection).

and somewhat back to 2007: year in review ... my first post of the year
http://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007

referencing article in late 2006 ... and a thread that continued thru much of 2007, mostly about how it hadn't happened.

2008: The year of hack the vote?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From:   Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: 2008: The year of hack the vote?
Date: Sat, 29 Dec 2007 15:04:37 -0500
To: cryptography@xxxxxxxx
CC: lloyd@xxxxxxxx
Jack Lloyd wrote:
The only reason this 'must' be true is because an anonymous and secure payment system is a terror which thankfully our federal governments and central banks protect us from. While Amazon and others obviously like being able to build customer profiles of everyone, I don't doubt that they would be perfectly willing to accept an anonymous payment as long as the money is good (and, of course, that the transaction costs are no more than a credit card and/or the order flow is sufficient that it is worth building support for it).

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 ... which resulted in the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959

in the same timeframe, the EU (in conjunction with eu-dpd) made statements that electronic payments at point-of-sale should be as anonymous as cash.

this was interpreted as meaning that names should be removed from payment cards (plastic and magstripe). the contention was that (because of poor authentication) retail outlets could cross-check names on the cards against some other form of "ID". the implication that removing names might help promote other integrity measures.

in the x9.59 standard, we claimed that the improved integrity allowed meeting the EU-DPD objectives. We also claimed that x9.59 was privacy agnostic i.e. it allowed for privacy. The ALL requirement given to the x9a10 financial standard working group met internet, face-to-face, point-of-sale, electronic commerce. It also met debit, credit, ACH, as well as stored-value cards ... aka the same X9.59 was applicable to ALL. In the debit/credit scenario some countries have know your customer mandates associating account numbers with individuals ... which we claimed was outside the x9.59 standard. Supposedly with appropriate regulated access to information, govs can obtain information associating account activity with individuals.

However, the very same x9.59 standard also works with stored-value/gift cards ... which doesn't have similar know your customer mandates.
http://www.garlic.com/~lynn/subpubkey.html#privacy

And in fact, most stored-value/gift cards share a lot of the same exact processing with the debit/credit processing ... the addition of x9.59 could provide for the exact same level of integrity thruout debit, credit, and stored-value/gift processing.

for other drift, in the mid-90s ... there were some number of other payment efforts, specifically for the internet, which had so much payload and processing bloat that it made it impractical past the toy demo stage
http://www.garlic.com/~lynn/subpubkey.html#bloat

related recent post on infrastructure provisioning and bloat of toy demos:
http://www.garlic.com/~lynn/2007v.html#64 folklore indeed

about the same time, there were completely different chip card oriented efforts for point-of-sale. one of the scenarios of some of the chipcard pilot projects in the late 90s and early part of this century was that they managed to increase the vulnerabilities (magstripe vis-a-vis chipcards)
http://www.garlic.com/~lynn/subintegrity.html#yescard

the common excuse from the period, was that chips cost so much that it wasn't possible to afford integrity that actually improved over magstripe. The other possible observation was that some of the chipcard efforts were so chip myopic ... that they couldn't realize that they were actually making it worse for the overall infrastructure.

A big issue for merchants isn't anonymous payments ... it is cost of doing business. This has been in the news quite a bit recently in the form of interchange fees ... recent posts
http://www.garlic.com/~lynn/2007v.html#62 folklore indeed

the other area is in the liability related to breaches (and/or the costs of countermeasures to breaches).

i've mentioned before that we had been called in to consult with small client/server startup that wanted to do payments on their server. They had this technology they called SSL and it is frequently now referred to as electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

and then we got dragged into involvement with the x9a10 financial standard working group, as part of attempting to meet the requirement to preserve the integrity of the financial infrastructure for all retail payments ... we did some detailed threat and vulnerability analysis. A big item that came out were infrastructure vulnerabilities ... breaches, skimming, harvesting, evesdropping, ... a whole slew of things.

we identified that much of the vulnerability could be attributed to the account number and transaction information has diametrically opposing requirements ... 1) it has to be readily available for large number of different business processes and 2) since the crooks can use the same information for various kinds of essentially replay attacks ... the information has to be kept confidential and never divulged.

we've also talked about this as the dual-use nature of the information ... and that even if the planet was buried under miles of (information hiding) encryption, it still wouldn't be able to prevent information leakage.

So another part of the x9.59 financial standard was to eliminate the dual-use nature of the information, making it useless for crooks ... aka x9.59 didn't do anything to prevent information leakage ... it just eliminated the information leakage as a vulnerability. a related recent post
http://www.garlic.com/~lynn/2007v.html#74 folklore indeed

from this stand-point ... the x9.59 financial standard addresses both drastically reducing fraud in the infrastructure as well as drastically reducing the infrastructure costs for fraud countermeasures.

Death of antivirus software imminent

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Death of antivirus software imminent
Date: Sat, 29 Dec 2007 18:37:03 -0500
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
CC: ' =JeffH ' <Jeff.Hodges@xxxxxxxx>
re: Storm, Nugache lead dangerous new botnet barrage
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1286808,00.html

from above:
The creators of these Trojans and bots not only have very strong software development and testing skills, but also clearly know how security vendors operate and how to outmaneuver defenses such as antivirus software, IDS and firewalls, experts say. They know that they simply need to alter their code and the messages carrying it in small ways in order to evade signature-based defenses. Dittrich and other researchers say that when they analyze the code these malware authors are putting out, what emerges is a picture of a group of skilled, professional software developers learning from their mistakes, improving their code on a weekly basis and making a lot of money in the process.

... snip ...

... and somewhat related

Virtualization still hot, death of antivirus software imminent, VC says
http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html

from above:
Another trend Maeder predicts for 2008 is, at long last, the death of antivirus software and other security products that allow employees to install and download any programs they'd like onto their PCs, and then attempt to weed out the malicious code. Instead, products that protect endpoints by only allowing IT-approved code to be installed will become the norm.

... snip ...

and post about dealing with compromised machines
http://www.garlic.com/~lynn/2007u.html#71 folklore indeed

mentioning sophistication in other ways:

Botnet-controlled Trojan robbing online bank customers
http://www.networkworld.com/news/2007/121307-zbot-trojan-robbing-banks.htm

from above:
If the attacker succeeds in getting the Trojan malware onto the victim's computer, he can piggyback on a session of online banking without even having to use the victim's name and password. The infected computer communicates back to the Trojan's command-and-controller exactly which bank the victim has an account with. It then automatically feeds code that tells the Trojan how to mimic actual online transactions with a particular bank to do wire transfers or bill payments

... snip ...

there have been some number of online banking countermeasures for specific kinds of system compromises .... like keyloggers ... but they apparently didn't bother to get promises from the crooks to only limit the kinds of attacks to those exploits.

some related comments on such compromised machines
http://www.garlic.com/~lynn/aadsm27.htm#66 2007: year in review
http://www.garlic.com/~lynn/aadsm28.htm#0 2007: year in review

Why Security Modelling doesn't work -- the OODA-loop of today's battle

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: December 30, 2007 04:27 PM
Subject: Why Security Modelling doesn't work -- the OODA-loop of today's battle
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000991.html

first, a disclaimer, in the past, I sponsored Boyd for a number of presentations ... and applying OODA-loops to other kinds of competitive situations ... some past posts mentioning Boyd and/or OODA-loops
http://www.garlic.com/~lynn/subboyd.html#boyd
and various Boyd references from around the Web
http://www.garlic.com/~lynn/subboyd.html#boyd2

the other factor ... specifically with respect to payment transaction paradigm ... is related to old security proportional to risk ... and part of the justification behind aspects of x9.59 financial standard protocol
http://www.garlic.com/~lynn/x959.html#x959

aka ... with the current paradigm, attackers can afford to outspend the defenders by possibly 100:1 ...
http://www.garlic.com/~lynn/2007v.html#86
and
http://www.garlic.com/~lynn/2007v.html#87

and for a slightly different tact ... post on "Death of antivirus software imminent"
http://www.garlic.com/~lynn/aadsm28.htm#2

Death of antivirus software imminent

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Death of antivirus software imminent
Date: Mon, 31 Dec 2007 09:31:32 -0500
To: Sherri Davidoff <alien@XXXXXXXX>
CC: cryptography@xxxxxxxx, ' =JeffH ' <Jeff.Hodges@xxxxxxxx>
Sherri Davidoff wrote:
Interesting how "virtualization" seems to imply "safe" in the public mind (and explicitly in that article) right now.... I'm sure with the increasing use of virtualization, we'll start to see more VMware-aware malware and virtual machine escapes in the wild. Another example of putting many, many eggs in the same basket.

Here's a good article about the first public VMware escape, which Intelguardians demonstrated at SANSFIRE this summer: (Note: I'm biased, having worked on this project.)
http://www.pauldotcom.com/2007/07/

What boggles my mind is that despite this, the DoD has still decided to rely on virtualization software to keep classified and unclassified info on the same physical systems:
http://www.internetnews.com/storage/article.php/3696996


re:
http://www.garlic.com/~lynn/aadsm28.htm#2 Death of antivirus software imminent

i have a different bias ... but then again a lot of it was my code that i wrote as undergraduate.

three people from the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

had come out and installed virtual machine system at the univ. the last week of jan68.

i got to rewrite lots of the code as an undergraduate over the next couple yrs. part of presentation on some of the work made at boston meeting aug68:
http://www.garlic.com/~lynn/94.html#18

i knew about quite a few of commercial uses ... including timesharing service bureaus
http://www.garlic.com/~lynn/submain.html#timeshare

but didn't find out about gov. uses until much later, minor reference:
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

other historical information
http://www.leeandmelindavarian.com/Melinda/25paper.pdf

Why Security Modelling doesn't work -- the OODA-loop of today's battle

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 2, 2008 11:02 AM
Subject: Why Security Modelling doesn't work -- the OODA-loop of today's battle
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modeling doesn't work -- the OODA-loop of today's battle

I had become acquainted with John Boyd in the early 80s and sponsored him for a number of corporate conferences. He was retired and giving talks for just his out-of-pocket expenses.

despite enormous contributions in numerous areas, much of the establishment preferred to act as if he didn't exist ... possibly because he had low tolerance for numerous things. He made the F15, F16, F18 and whole generation of airplane design what they are today ... but the air force almost acts as if he wasn't there. he was eventually adopted by the marines (adapting aerial dog fights and OODA-loops to ground warfare).

some recent long-winded posts in financial transaction related subthread ... that much of the current "risk" isn't because the information is so easy for the crooks to obtain ... but the fundamental "risk" is that the crooks can use the obtained information for fraudulent transactions.
http://www.garlic.com/~lynn/2008.html#4
http://www.garlic.com/~lynn/2008.html#5
http://www.garlic.com/~lynn/2008.html#7
http://www.garlic.com/~lynn/2008.html#8
http://www.garlic.com/~lynn/2008.html#9

this is also the previous comment that the crooks (attacking the information) can outspend (by possibly 100:1) the merchants (attempting to prevent information access).

the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959

rather than attempting to prevent all possible access to the information ... changed the paradigm and made the information useless to crooks for generating fraudulent transactions (eliminated the risk). this is somewhat the thread here this summer about the naked transaction metaphor
http://www.garlic.com/~lynn/subintegrity.html#payments

Death of antivirus software imminent

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 02 Jan 2008 12:09:50 -0500
To: Bill Frantz <frantz@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Subject: Re: Death of antivirus software imminent
Bill Frantz wrote:
My favorite virtual machine use is for the virus to install itself as a virtual machine, and run the OS in the virtual machine. This technique should be really good for hiding from virus scanners.

re:
http://www.garlic.com/~lynn/aadsm28.htm#2 Death of antivirus software imminent
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software imminent

i commented on that in reference posts mentioning that there have been uses of virtual machines to study virus/trojans ... but that some of the new generation virus/trojans are now looking to see if they are running in virtual machine (studied?).

some of the current trade-off is whether that virtual machine technology can be used to partition off basically insecure operations (which are widely recognized as being easy to compromise) and then completely discard the environment and rebuild from scratch after every session (sort of the automated equivalent of having to manually wipe an infected machine and re-install from scratch).

the counter argument is that crooks can possibly also use similar technology to hide ... once they have infected the machine. the current issue is that a lot of the antivirus/scanning techniques are becoming obsolete w/o the attackers even leveraging virtual machine technology.

The attackers can leverage the technology in an otherwise poorly defended machine. Some years ago there was a product claiming that it could operate even at a public access machine because of their completeness of their antivirus countermeasures ... even on an infected machine. I raised the issue that it would be trivial to defeat all such countermeasures using virtual machine technology. Somewhat of a skirmish resulted since they had never considered (or heard of) virtual machine technology ... for all i know there is still ongoing head-in-the-sand situation.

for little topic drift ... this blog entry:
http://financialcryptography.com/mt/archives/000991.html

and
http://www.garlic.com/~lynn/aadsm28.htm#3
http://www.garlic.com/~lynn/aadsm28.htm#5

there is some assertion that the crooks overwhelming the defenders countermeasures because they are operating significantly faster and more efficiently.

however, another interpretation is that the defenders have chosen extremely poor position to defend ... and are therefor at enormous disadvantage. it may be necessary to change the paradigm (and/or find the high ground) in order to successfully defend.

Why Security Modelling doesn't work -- the OODA-loop of today's battle

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 2, 2008 02:26 PM
Subject: Why Security Modelling doesn't work -- the OODA-loop of today's battle
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA-loop of today's battle
http://www.garlic.com/~lynn/aadsm28.htm#5 Why Security Modelling doesn't work -- the OODA-loop of today's battle

taking a slightly different "Boyd" perspective
http://www.garlic.com/~lynn/subboyd.html#boyd

some of the current problems could be attributed to not having a strong defensive position ... which gives the attackers an enormous advantage ... referenced in this thread/post
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software imminent

my wife's father graduated from west point (and then got a engineering graduate degree from berkeley) ... however, one of the things that typically is taught is how to choose your defensive position. he had been engineers for patton and frequently was ranking officer into enemy territory ... and acquired a collection of officer (silver, gold, platinum) daggers in surrenders. he also was involved in liberating some number of camps.

Death of antivirus software imminent

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Death of antivirus software imminent
Date: Wed, 02 Jan 2008 17:18:21 -0500
To: Leichter, Jerry <leichter_jerrold@xxxxxxxx>
CC: Bill Frantz <frantz@xxxxxxxx>,
Cryptography <cryptography@xxxxxxxx>
Leichter, Jerry wrote:
When IBM originally developed VMM technology, security was not a primary goal. People expected the OS to provide security, and at the time it was believed that OS's would be able to solve the security problems.

As far as I know, the first real tie of VMM's to security was in a DEC project to build a VMM for the VAX that would be secure at the Orange Book A2 level. The primary argument for this was: Existing OS's are way too complex to verify (and in any case A2 required verified design, which is impossible to apply to an already-existing design). A VMM can be small and simple enough to have a verified design, and because it runs "under" the OS and can mediate all access to the hardware, it can serve as a Reference Monitor. The thing was actually built and met its requirements (actually, it far exceeded some, especially on the performance end), but died when DEC killed the VAX in favor of the Alpha.


i always thot that i built systems that had prime objective of having high integrity and not being compromised.

as referenced in this previous post
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software imminent

this use predated
http://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

vax/vms by quite a bit. it also predated rainbow books. a lot of the stuff I did in the 60s as an undergraduate ... and I didn't find out about some uses until much later. When i was an undergraduate, I remember IBM asking if I could implement various features ... and some number of years later conjectured that possibly the requests actually originated from various gov. organizations.

as previously noted, it was used extensively in both gov. and commercial environments requiring security and integrity.

for other archeological drift ... vms inherited some number of people from the burlington mall development group
http://www.garlic.com/~lynn/2007v.html#96 source for VAX programmers
http://www.garlic.com/~lynn/2007v.html#100 source for VAX programmers

Death of antivirus software imminent

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Death of antivirus software imminent
Date: Thu, 03 Jan 2008 11:05:59 -0500
To: Leichter, Jerry <leichter_jerrold@xxxxxxxx>
CC: Bill Frantz <frantz@xxxxxxxx>, Cryptography <cryptography@xxxxxxxx>
Leichter, Jerry wrote:
Virtualization has become the magic pixie dust of the decade.

When IBM originally developed VMM technology, security was not a primary goal. People expected the OS to provide security, and at the time it was believed that OS's would be able to solve the security problems.


re:
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software iminent
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software iminent
http://www.garlic.com/~lynn/aadsm28.htm#8 Death of antivirus software iminent

the other claim was that it was assumed that basic systems were built to be secure, so it would have been quite foreign idea it would be necessary to build a secure specific system.

besides the referenced fairly wide use of gov and commercial institutions requiring high integrity systems ... the early virtual machine systems (cp67 and vm370) were also used by commercial time-sharing service bureaus. most of these created cms "padded cell" modifications, a lot of it was to prevent users from damaging themselves (as opposed to the underlying security that prevented uses from damaging the system and/or each other).

at least some of these services provided online, concurrent services to (competitive) wall street firms ... who would be using the online services for highly sensitive financial activities (as example of integrity requirements).

a little related x-over from posting in this thread
http://www.garlic.com/~lynn/2008.html#14 hacked TOPS-10 monitors

Why Security Modelling doesn't work -- the OODA-loop of today's battle

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 3, 2008 12:12 PM
Subject: Why Security Modelling doesn't work -- the OODA-loop of today's battle
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000991.html

previous posts:
http://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA-loop of today's battle
http://www.garlic.com/~lynn/aadsm28.htm#5 Why Security Modelling doesn't work -- the OODA-loop of today's battle
http://www.garlic.com/~lynn/aadsm28.htm#7 Why Security Modelling doesn't work -- the OODA-loop of today's battle

Boyd characterized US WW2 strategy as massive logistics (overwhelming enemy by 10:1 resources) and extremely rigid command and control. Part of this was claim that US entered the conflict with very few professional soldiers and quickly fielded a large number of rapidly mobilized citizens. Part of the extremely rigid command and control was to leverage the experience of the few professional soldiers and part of it was to manage the enormous logistics operation.

As a contrast, he would quote Guderian, on the eve of the blitzkrieg verbal orders only. This is related to the definition of auditors as the people that go around the battlefield after the war, stabbing the wounded. The claim was that Guderian wanted the professional "on the spot" to make decisions and not have to worry about any monday afternoon quarterbacks.

In the early 80s, Boyd claimed that the rigid command and control structure with underlying assumption that the majority of people were unskilled ... were adversely affecting US business, as the young WW2 officers came to major executive positions (and they reflected their WW2 training).

This theme was also behind his briefing Organic Design For Command and Control. I have a copy of the original version and some subsequent copies as it evolved over time.

lots of past Boyd posts
http://www.garlic.com/~lynn/subboyd.html#boyd
and some number of Boyd &/or OODA-loop references from around the web
http://www.garlic.com/~lynn/subboyd.html#boyd2

Death of antivirus software imminent

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Death of antivirus software imminent
Date: Fri, 04 Jan 2008 16:12:13 -0500
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx <cryptography@xxxxxxxx>,
Leichter, Jerry <leichter_jerrold@xxxxxxxx>
Peter Gutmann wrote:
Actually VMMs do provide some security, but not in the way you think. Since malware researchers typically run malware they're analysing inside a VM, quite a bit of malware will silently exit (or at least not exercise the "mal" part of its name) if it detects that it's running inside a VM. So you can inoculate yourself against at least some malware by running your OS inside a VM.

re:
http://www.garlic.com/~lynn/aadsm28.htm#2 Death of antivirus software imminent
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software imminent
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software imminent
http://www.garlic.com/~lynn/aadsm28.htm#8 Death of antivirus software imminent
http://www.garlic.com/~lynn/aadsm28.htm#9 Death of antivirus software imminent

when i was working on virtual machines as undergraduate 60s ... they provided security in the sense of eliminating compromises between users and the system and between different users. part of this was that they were something of a microkernel and the APIs were well defined and KISS and potential for compromises could be fairly easily understood and dealt with.

there never was much about absolutely prevent awareness of running in virtual machines ... but there was a lot of effort provided that the interface provided met the architecture and principles of operation specification for the machine ... enabling software that expected machines that met that architecture and principles of operation to work correctly (some number of features that i added for performance and/or functional enhancements contributed to being able to determine that execution wasn't on a real machine .... however, the implementations had to be done in such a way that they conformed to the official machine principles of operation specification).

i've mentioned before about getting requests from IBM for changes and features ... that years later I suspected might have originated from various gov. agencies. Some of these feature changes could be interpreted as obfuscating what kinds of activity might be going on in the rest of the environment ... potentially the result of concurrent execution by other virtual machines.

as i've mentioned, some of the commercial timesharing service bureaus using the virtual machine platform ... did make enhancements to the personal computing environment ... to limit the damage that individual users could do themselves. however, these weren't necessarily routinely used as part of standard deployments.

the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

had originated the virtual machine technology ... and also had originated the technology that was used for the internal network ... which was larger than the arpanet/internet from just about the beginning until approx. summer of '85
http://www.garlic.com/~lynn/subnetwork.html#internalnet

the same technology was also used for univ. virtual machine based network in the US (bitnet) and europe (EARN) up until it being replaced with tcp/ip
http://www.garlic.com/~lynn/subnetwork.html#bitnet

this network had a worm-type event almost exactly a year before the morris worm ... a recent post with references:
http://www.garlic.com/~lynn/2007u.html#87

#4.2 Simplicity is Inversely Proportional to the Number of Designers

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 11, 2008 03:04 PM
Subject:#4.2 Simplicity is Inversely Proportional to the Number of Designers
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000994.html

above entry refers to the previous entry:

What good are standards?
http://financialcryptography.com/mt/archives/000993.html

.... I had given a talk on assurance and the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

in trusted computing track at intel developer's forum a few years ago. during the talk, I happen to quip that it was interesting to note that over the previous couple years, the TPM design had started to look more and more like the aads chip strawman. person running the effort was in the front row and quiped back that I didn't have a committee of 200 hundred people helping me with the design.

Break the rules of governance and lose 4.9 billion

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 24, 2008 04:30 PM
Subject: Break the rules of governance and lose 4.9 billion...
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000997.html

Last week I had a post that in the early 80s, the state-of-the-art was starting to handle a lot of insider fraud with things like roles .... and then there was starting to be problems with collusion ... so there were starting to be some number of collusion countermeasures.
http://www.garlic.com/~lynn/2008b.html#26

and things are still waiting to get back to the what the state-of-the-art was working on 25yrs ago.

recent comment on this particular topic
http://www.garlic.com/~lynn/2008b.html#82

Break the rules of governance and lose 4.9 billion

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 25, 2008 05:22 AM
Subject: Break the rules of governance and lose 4.9 billion...
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm28.htm#13

There are all sorts of barriers to introducing new systems ... frequently involving disastrous past attempts. I've pontificated recently about disastrous, ill-fated attempt to deploy consumer chipcard operation with personal readers early in the decade and the chilling aftermath on any further attempts.

A lot of the current "online" transaction infrastructures started out as purely batch operations. In the 70s&80s, many of these infrastructures added front-end transaction interfaces ... but still relied on batch to complete the operations (commonly associated with "settlement") in what frequently came to be known as overnight batch windows.

In the 90s, there were billions spent on failed attempts to upgrade these facilities ... frequently with "object" oriented and parallelized implementations for something called straight through processing ... to eliminate the increasing bottleneck of the overnight batch window (globalization was decreasing the size of the window and any workload increase was frequently banging up against the processing limits of the window).

recent references
http://www.garlic.com/~lynn/2008b.html#3 on-demand computing
http://www.garlic.com/~lynn/2008b.html#74 Too much change opens up financial fault lines

Dutch Transport Card Broken

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dutch Transport Card Broken
Date: Fri, 25 Jan 2008 10:28:55 -0500
To: James A. Donald <jamesd@xxxxxxxx>
CC: Perry E. Metzger <perry@xxxxxxxx>, cryptography@xxxxxxxx
my impression has been that with lack of takeup of various kinds of security solutions that were extensively marketed in the 90s ... that the current situation has many of those same organizations heavily involved in behind the scenes lobbying

saw some of that nearly a decade ago when we were brought in to help wordsmith the cal. state electronic signature legislation which led to also be brought in on federal electronic signature legislation ... some past posts
http://www.garlic.com/~lynn/subpubkey.html#signature

some other references ...

Hackers break into transport smart card
http://www.dutchnews.nl/news/archives/2008/01/german_hackers_break_transport.php
Transport smart card hacked again (update)
http://www.dutchnews.nl/news/archives/2008/01/transport_smart_card_hacked_ag.php

Dutch Transport Card Broken

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dutch Transport Card Broken
Date: Fri, 25 Jan 2008 10:47:39 -0500
To: Aram Perez <aramperez@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Aram Perez wrote:
Not to defend the designers in any way or fashion, but I'd like to ask, How much security can you put into a plastic card, the size of a credit card, that has to perform its function in a secure manner, all in under 2 seconds (in under 1 second in parts of Asia)? And it has to do this while receiving its power via the electromagnetic field being generated by the reader.

we sort of saw that in the mid-90s when we were doing the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959

and getting comments that it wasn't possible to have both low cost and high security at the same time. we looked at it and made the semi-facetious statements that we would take a $500 milspec part and aggresively cost reduce it by 2-3 orders of magnitude while improving the security. along the way we got tapped by some in the transit industry to also be able to meet the (then) transit gate requirements (well under 1 second and do it within iso 14443 power profile).

part of it was having to walk the whole end-to-end process ... all the way back to chip design and fab manufacturing process ... little drift about walking fab in a "bunny suit"
http://www.garlic.com/~lynn/2008b.html#13

we effectively did get it on close to the RFID chip (i.e. the one that they are targeting for UPC) technology curve ... i.e. chip fabrication cost is roughly constant per wafer ... wafer size and circuit size have been leading to higher number of chips per wafer (significantly reducing cost/chip). As circuit size shrank with the corresponding shrinkage in the size of chips (that didn't have corresponding increase in number of circuits) there was a "blip" on the cost/chip curve as the area of the cuts (to separate chips in the wafer) exceeded the (decreasing) chip size. Earlier this decade there was a new cutting process that significantly reduced the "cut" area ... allowing yield of (small) chips per wafer to continue to significantly increase (allowing pushing close to four orders of magnitude reduction ... rather than 3-4 orders of magnitude reduction).

aads chip strawman references
http://www.garlic.com/~lynn/x959.html#aads

Lack of fraud reporting paths considered harmful

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Lack of fraud reporting paths considered harmful.
Date: Sat, 26 Jan 2008 23:11:25 -0500
To: Perry E. Metzger <perry@xxxxxxxx>
CC: cryptography@xxxxxxxx
Perry E. Metzger wrote:
This evening, a friend of mine who shall remain nameless who works for a large company that regularly processes customer credit card payments informed me of an interesting fact.

His firm routinely discovers attempted credit card fraud. However, since there is no way for them to report attempted fraud to the credit card network (the protocol literally does not allow for it), all they can do is refuse the transaction -- they literally have no mechanism to let the issuing bank know that the card number was likely stolen.

This seems profoundly bad. I hope that someone on the list has the right contacts to get the right people to do something about this.


some chance they are doing this to save money on transactions that aren't likely to be approved ... i.e. rather than be charged for a transaction that they send thru to the issuer that they are sure to be rejected ... they reject it upfront.

now the associations have standard procedure to perform "stand-in" when the network accepts a transaction from an acquirer but isn't able to forward it to the issuer. stand-in allows the network to decide whether to approve or reject the transaction using simplified rules. later, when contact is re-established with the issuer ... the issuer has to be informed of all the stand-in activity.

a possible simplified mechanism is to be able to generate a simulated stand-in report of rejected transactions. the issue then in such a simulated stand-in role ... for all the reasons that they chose to reject a transaction ... do they map into the standard iso 8583 codes for reasons that the issuer would reject the transaction.

Lack of fraud reporting paths considered harmful

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Lack of fraud reporting paths considered harmful.
Date: Sun, 27 Jan 2008 13:07:45 -0500
To: Ian G <iang@xxxxxxxx>
CC: John Ioannidis <ji@xxxxxxxx>, cryptography@xxxxxxxx
Ian G wrote:
There is a philosophical problem with suggesting an automated protocol method for reporting fraud, in that one might be better off ... fixing the underlying fraud.

re:
http://www.garlic.com/~lynn/aadsm28.htm#17 Lack of fraud reporting paths considered harmful

as an aside ... since the acquiring institution is financially responsible for the merchant ... they frequently have fraud detection operations running on incoming transactions ... as do the issuing institution.

however, if the merchants are prescreening transactions to save on merchant interchange fees ... then it becomes an economic issue, including not subsequently incurring costs on transactions that they had rejected during prescreening. the previous suggestion regarding simulated "stand-in" reporting would likely have to go thru as batched "non-mon" transaction (and not be burdened with standard fees).

merchant interchange fees are a continuing, ongoing issue ... for some market segments, interchange fees are even the largest expense they have ... also larger than their profit margin. for a large chain with centralized transaction processing aggregation .... even small improvements might significantly change their bottom line.

past thread mentioning there is some interaction between the amount of fraud and the size of interchange fees (i.e. signature debit has been measured at 15 times pin debit ... and signature debit interchange fees are correspondingly significantly larger, comparable to credit fees)
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#37 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#41 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#42 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#43 a fraud is a sale, Re: The bank fraud blame game

misc. other posts mentioning interchange fees:
http://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems
http://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
http://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
http://www.garlic.com/~lynn/aadsm26.htm#34 Failure of PKI in messaging
http://www.garlic.com/~lynn/aadsm27.htm#62 Fingerprint Firefox Plugin?
http://www.garlic.com/~lynn/aadsm28.htm#1 2008: The year of hack the vote?
http://www.garlic.com/~lynn/aadsm7.htm#rhose3 Rubber hose attack
http://www.garlic.com/~lynn/2005u.html#16 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
http://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#72 Free Checking
http://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007n.html#68 Poll: oldest computer thing you still use
http://www.garlic.com/~lynn/2007r.html#31 Is the media letting banks off the hook on payment card security
http://www.garlic.com/~lynn/2007r.html#40 Is the media letting banks off the hook on payment card security
http://www.garlic.com/~lynn/2007s.html#64 Is the media letting banks off the hook on payment card security
http://www.garlic.com/~lynn/2007u.html#0 folklore indeed
http://www.garlic.com/~lynn/2007v.html#62 folklore indeed
http://www.garlic.com/~lynn/2008c.html#7 Toyota Sales for 2007 May Surpass GM

Lack of fraud reporting paths considered harmful

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Lack of fraud reporting paths considered harmful.
Date: Mon, 28 Jan 2008 12:06:04 -0500
To: James A. Donald <jamesd@xxxxxxxx>
CC: Perry E. Metzger <perry@xxxxxxxx>, Ian G <iang@xxxxxxxx>,
cryptography@xxxxxxxx
James A. Donald wrote:
Why is it a mediocre solution?

The credit card number is a widely shared-secret. It has been known for centuries that widely shared-secrets have a short life expectancy and should be frequently re-issued.

The only better solution is unshared-secrets. Is that what you had in mind? Instead of the customer sharing his secret with the merchant, and the merchant checking it with the bank, customer should prove to bank that the person who knows the secret wishes to pay the merchant for the identified promise.


re:
http://www.garlic.com/~lynn/aadsm28.htm#17 Lack of fraud reporting paths considered harmful
http://www.garlic.com/~lynn/aadsm28.htm#18 Lack of fraud reporting paths considered harmful

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. The result was the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959

part of the x9.59 financial standard was to eliminate knowledge of the account number as a vulnerability.

the issue was that there are diametrically opposing requirements being placed on the account number. on one hand it had to be readily available in a large number of different places for lots of business processes. on the other hand it had to be kept confidential and never divulged to anybody (displayed, exposed, and/or used).

this led to periodic comment that even if the planet was buried under miles of information hiding encryption ... it still couldn't prevent account number leakage.

misc. posts mentioning shared-secrets
http://www.garlic.com/~lynn/subintegrity.html#secrets
and account number harvesting
http://www.garlic.com/~lynn/subintegrity.html#harvest

Fixing SSL (was Re: Dutch Transport Card Broken)

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Date: Wed, 30 Jan 2008 12:57:07 -0500
To: Philipp Gühring <pg@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Philipp Guhring wrote:
Yes, sending client certificates in plaintext while claiming that SSL/TLS is secure doesn´t work in a world of phishing and identity theft anymore.

We have the paradox situation that I have to tell people that they should use HTTPS with server-certificates and username+password inside the HTTPS session, because that´s more secure than client certificates ...

Does anyone have an idea how we can fix this flaw within SSL/TLS within a reasonable timeframe, so that it can be implemented and shipped by the vendors in this century?

(I don't think that starting from scratch and replacing SSL makes much sense, since it's just one huge flaw ...)


re:
http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken

aka ... that was part of the relying-party-only certificates from the mid-90s;
http://www.garlic.com/~lynn/subpubkey.html#rpo

i.e. the x.509 identity digital certificates from the early 90s, were becoming more and more overloaded with personal information ... and by the mid-90s, lots of institutions were starting to realize all that personal information represented significant privacy and liability issues ... and the RPO digital certificates were born.

However, it was trivial to demonstrate that (for all those business processes) that the digital certificates were redundant and superfluous (however, there was some amount of industry brain washing that digital certificates were mandatory ... especially if digital signatures was used ... even if they served no useful purpose).

this also showed up in work on pk-init for kerberos supporting digital signature authentication ... and got into the confused mess with redundant and superfluous digital certificates
http://www.garlic.com/~lynn/subpubkey.html#kerberos

and similarly digital signatures for radius
http://www.garlic.com/~lynn/subpubkey.html#radius

(between kerberos and radius, they represent possibly the majority of client authentication in the world today)

part of the confusion regarding the necessity for digital certificates could be seen in the X9F financial standards work ... the appending of even a relying-party-only digital certificate (lacking any personal information) could represent a factor of 100 times payload bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat

for a nominal electronic payment transactions (and also 100 times processing bloat). as a result, there was some standardization effort looking at "compressed" (relying-party-only) digital certificates (even tho they were serving no useful purpose), attempting to get the payload bloat down to possibly only 5-10 times (instead of 100 times). I took the opportunity to demonstrate that it would be logically possible to compress such digital certificates to zero bytes ... totally eliminating the payload bloat. then rather than advocating the elimination of totally useless, redundant and superfluous digital certificates
http://www.garlic.com/~lynn/subpubkey.html#certless

there could be an infrastructure that mandated zero-byte digital certificates appended to every transaction.

Dutch Transport Card Broken

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dutch Transport Card Broken
Date: Thu, 31 Jan 2008 14:28:30 -0500
To: 'Cryptography' <cryptography@xxxxxxxx>
Victor Du wrote:
Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds round-trips to SSL warrants some evidence (it is very temping to express this skepticism more bluntly).

With unextended SMTP for example, the minimum RTT count is:

0. SYN SYN-ACK
1. ACK 220
2. HELO 250
3. MAIL 250
4. RCPT 250
... n recipients
RCPT 250
4+n DATA 354
5+n ... stream of message content segments<CRLF.CRLF>
250

so it takes at least 6 RTTs to perform a delivery (of a short single-recipient message), but only 1 of the 6 RTTs is TCP "overhead". This is improved with PIPELINING:

0. SYN SYN-ACK
1. ACK 220
2. EHLO 250 ... PIPELINING ...
3. MAIL RCPT(n times) DATA 250 250 (n times) 354
4. ... stream of message content segments<CRLF.CRLF>
250


re:
http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch Transport Card Broken)

TCP requires minimum of seven message exchange for reliable transport .... VMTP (rfc 1045) got that down to minimum of five messages, and XTP then got it down to three messages minimum for reliable transport (disclaimer we were on the XTP technical advisory board).

i've frequently pontificated that with reliable registration of public keys in the dns system and then piggy-backing any registered public key in standard DNS response .... then it would be possible to encode a randomly generated secret key (with that public key) and the encrypted message in the XTP packet for minimum 3 packet exchange.
http://www.garlic.com/~lynn/subpubkey.html#catch22

http already went thru its period of problems of implicit assumptions with tcp. tcp sessions were assumed to be long lived and session shutdown was assumed to be relatively infrequently. non-session activity like http was always assumed to use udp for efficiency. http ignored all of that and used tcp for non-session activity. as a result, webserver systems went thru a period where the processors were spending 95+ percent of processor in the session shutdown processing. systems then were retrofited with new kind of tcp session shutdown implementation to handle the misuse by http.

the original ssl deployment was to 1) encrypt data in transit and 2) authenticate the server. the implicit assumption was that the user understood the binding between the business and the url. the browser then provided the second part, verifying the binding between the url and the server contacted (was the server that the user thot they were talking to, the server they were actually talking to).

The dependency for valid ssl operation was violated almost immediately when merchants found that ssl overhead reduced thruput by 5-10 times. the regression was instead of initial contact of the webserver (presumably url supplied by user) being ssl, ssl was moved to checkout/pay phase where the user clicked on a button (and url) provided by the webserver (not a url provided by the user). It was no longer possible to provide any authentication assurances of the webserver contacted (ssl purely being reduced to encrypting data in transmission).

we had been called in to consult with the small client/server company on using this technology (they created) called SSL for payment transactions
http://www.garlic.com/~lynn/subnetwork.html#gateway

and had to go thru detailed walk thrus of the technology as it applied to actual business processes (and the associated implicit dependencies) ... as well as detailed walk thrus of the new business operations that were calling themselves certification authorities.

the other issue that we came up for applying this SSL technology, was communication between webservers and something called the payment gateway. for this communication we mandated mutual authentication ... this was before mutual authentication had been implemented in SSL. It turns out that by the time we had it all implemented and deployed ... it also became very apparent that the things called digital certificates were redundant and superfluous.

the basic design point for digital certificates is first time communication between total strangers. the payment gateway business processes required that all the merchants had to be pre-registered with the payment gateway and the payment gateway pre-registered with all the merchants .... violating the basic justification for having digital certificates.

Dutch Transport Card Broken

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dutch Transport Card Broken
Date: Thu, 31 Jan 2008 17:50:00 -0500
To: 'Cryptography' <cryptography@xxxxxxxx>
Victor Duchovni wrote:


SMTP does not need TCP to provide reliability for the tail of the session, the application-level "." (end-of-data) and server "250" response complete a transaction, everything after that is optional, so for example Postfix will send (when PIPELINING).

DATA<CRLF> 354 Go ahead
Message-Content Lots of acks
.<CRLF>QUIT<CRLF> 250 Ok

and will disconnect after reading the "250 response" without waiting for the 221 response. The TCP 3-way shutdown (FIN, FIN-ACK, ACK) happens in the kernel in the background, the SMTP server and client are by that point handling different connections. So the reliable shutdown latency is of no consequence for application throughput.

A pipelined SMTP delivery can be completed over TCP in 5 RTTs not 7.

0. SYN SYN-ACK
1. ACK 220
2. EHLO 250
3. MAIL RCPT DATA 250 250 354
4. MSG . QUIT 250 221
5. close socket

TCP is fine, latency is primarily the result of application protocol details, not TCP overhead. The only TCP overhead above is 1 extra RTT for the connection setup. Everything else is SMTP not TCP, and running SMTP over UDP (with ideal conditions and no lost packets, ...) would save just 1 RTT.


re:
http://www.garlic.com/~lynn/aadsm28.htm#21 Dutch Transport Card Broken

sorry, I didn't say that TCP required seven round-trips for reliable exchange; the statement was that minimum TCP operation was seven packet exchange (for reliable operation) .... sort of 3.5 round-trips. That VMTP (rfc 1045) reduced that to minimum of five packet exchange (sort of 2.5 round-tips) ... and that XTP got it to a minimum of three packet exchange (sort of 1.5 round-trips) for reliable operation.

from my RFC index
http://www.garlic.com/~lynn/rfcietff.htm

rfc 1045 summary
http://www.garlic.com/~lynn/rfcidx3.htm#1045

1045 E VMTP: Versatile Message Transaction Protocol: Protocol specification, Cheriton D., 1988/02/01 (123pp) (.txt=264928) (Refs 955, 966, 969) (Ref'ed By 1050, 1072, 1105, 1106, 1190, 1263, 1323, 1453, 1458, 1700, 2018, 2375, 2757) (VMTP)

as always, clicking on the ".txt=nnn" field (in rfc summary) retrieves the actual RFC.

If there is more than minimum amount of data ... TCP might involve more than seven packet exchange ... but the minimum packet exchange is seven packets (not round-trips).

Dutch Transport Card Broken

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dutch Transport Card Broken
Date: Fri, 01 Feb 2008 09:37:59 -0500
To: Nicolas Williams <Nicolas.Williams@xxxxxxxx>
CC: 'Cryptography' <cryptography@xxxxxxxx>
Nicolas Williams wrote:
I don't have one that exists today and is practical. But we can certainly imagine possible ways to improve this situation: move parts of TLS into TCP and/or IPsec. There are proposals that come close enough to this (see the last IETF SAAG meeting's proceedings, see the IETF BTNS WG) that it's not too farfetched, but for web stuff I just don't think they're remotely likely.

my view of ipsec was that it faced a significant barrier to entry since it required upgrading lots of installed kernels all over the infrastructure (aka tcp/ip protocol stack have been integrated kernel implementations)

both SSL and VPN offered implementations that didn't require having to upgrade existing deployed kernels (something that has gotten somewhat easier in the last decade plus).

about the same time as SSL, a friend that we had worked on & off with over a couple decades introduced what was to become called VPN in gateway committee at fall '94 IETF meeting in san jose.

my view was this resulted in some amount of consternation with the ipsec forces as well as some of the router vendors. the ipsec forces were somewhat mollified by being able to refer to vpn as "lightweight" ipsec (while others then would refer to ipsec as "heavyweight" ipsec).

the initial proposal/implementation involved border routers providing authentication and (encryption) tunneling through the internet. some of the router vendors had processors that could handle the encryption load. however, there was opposition from the router vendors that didn't have products with processors that could handle the encryption load (or at least stalling until they had such a product).

in any case, uptake of both SSL and VPN ... was the significantly easier and less complex deployment ... vis-a-vis ipsec.

Fixing SSL (was Re: Dutch Transport Card Broken)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Date: Fri, 01 Feb 2008 10:13:32 -0500
To: Ian G <iang@xxxxxxxx>
CC: Eric Rescorla <ekr@xxxxxxxx>, Philipp Gühring <pg@xxxxxxxx>,
Cryptography <cryptography@xxxxxxxx>,
Rasika Dayarathna <dayarathna@xxxxxxxx>
Ian G wrote:
The PII equation is particularly daunting, echoing Lynn's early '90s experiences. I am told (but haven't really verified) that the certificate serial number is PII and therefore falls under the full weight of privacy law & regs ... this may sound ludicrous, but privacy and security are different fields with different logics. If that is true, the liability is far too high for something that should be private, but is already public by dint of its exposure in certificates. Privacy liabilities are sky-high in some places, and not only that, they are incalculable, unknowable, and vary with the person you are talking to.

So a superficial conclusion would be "don't use client certificates because of the privacy issues" although the issues are somewhat more complex than "PII revealed in SSL key exchange."

As I say, they'll plug on, as they need to prove that the cert is worth issuing. It's a data point, no more, and it doesn't exactly answer your spec above. But I'm having fun observing them trying to prove that client certs are worth any amount of effort.


the problem that digital certificates were suppose to address was first time communication between strangers ... the electronic analogy of the letters of credit/introduction from sailing ship days. this harks back to the "offline" email days of the early 80s ... dial-up electronic post-office, exchange email, hangup, and now authenticate first-time email from total stranger.

the design point assumptions are invalidated if the relying party has their own repository of information about the party being dealt with (and therefor can included that party's public key) and/or has online, timely electronic access to such information.

one of my favorite exchanges from the mid-90s was somebody claiming that adding digital certificates to the electronic payment transaction infrastructure would bring it into the modern age. my response was that it actually would regress the infrastructure at least a couple decades to the time when online, real-time transactions weren't being done. The online, real-time transaction provides much higher quality and useful information than a stale, static digital certificate (with an offline paradigm from before modern communication). Having an available repository about the party being dealt with ... including things like timely, aggregated information (recent transactions) is significantly mover valuable than the stale, static digital certificate environment (the only thing that it has going for it, is it is better than nothing in the oldtime offline environment).

misc. past posts referencing certificate-less public key operation
http://www.garlic.com/~lynn/subpubkey.html#certless

for some real topic drift ... i've mentioned x9.59 financial standard protocol that can use digital signatures for authentication w/o requiring digital certificates
http://www.garlic.com/~lynn/x959.html#x959

part of the issue included that digital certificates (even relying-party-only digital certificates) can add a factor of one hundred times payload bloat to a typical payment transaction
http://www.garlic.com/~lynn/subpubkey.html#bloat

however, we were also got involved in co-authoring the x9.99 privacy standard ... as part of that we had to look at a number of things, HIPAA, GLBA ... as well as EU-DPD. as part of that we had also done a privacy merged taxonomy and glossary ... some notes
http://www.garlic.com/~lynn/index.html#glosnote

EU had also made a statement in the mid-90s that electronic retail payments should be as anonymous as cash. The dominant use of SSL in the world today is electronic commerce between a consumer and a merchant. Passing a client certificate (with PII information) within an encrypted SSL channel to a merchant ... still exposes the information to the merchant ... also violating making purchases as anonymous as cash.

middle banking in a english muddle

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 2, 2008 01:24 PM
Subject: middle banking in a english muddle
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000999.html

for a little more topic drift, this is a reply to a recent post asking about a UK article where there was fraudulent debit card transactions on an account ... where the issued debit card had never been used (and therefor could never have been skimmed)
http://www.garlic.com/~lynn/2008b.html#67

the reply discusses a process gap/crack that appeared in the transition to (magstripe) signature-debit.

note that there was recent article that debit transactions have exceeded credit transactions:

Debit Traffic Now Bigger Than Credit Transactions for MasterCard
http://www.digitaltransactions.net/newsstory.cfm?newsid=1662

Fixing SSL (was Re: Dutch Transport Card Broken)

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Date: Sun, 03 Feb 2008 20:01:32 -0500
To: StealthMonger <StealthMonger@xxxxxxxx>
CC: cryptography@xxxxxxxx
StealthMonger wrote:
They can't be as "anonymous as cash" if the party being dealt with can be identified. And the party can be identified if the transaction is "online, real-time". Even if other clues are erased, there's still traffic analysis in this case.

What the offline paradigm has going for it is the possibility of true, untraceable anonymity through the use of anonymizing remailers and related technologies.


re:
http://www.garlic.com/~lynn/aadsm28.htm#24 Fixing SSL (was Re: Dutch Transport Card Broken)

most people who heard the statement, understood that.

i think that possibly 2nd level detail was that they didn't want PII easily associated by casual merchant. Initial response was to remove name from payment cards & magstripes. This also precluded merchants from requesting other forms of identification to see if the names matched the name on the payment card. The implication being that the payment infrastructure would have to come up with other mechanisms to improve the infrastructure integrity.

The offline payment paradigms ... while touting "true" anonymity were actually primarily justified based on other factors.

We had been asked to design and cost the dataprocessing supporting US deployments of some of the "offline" products (that were being used in Europe). Along the way, we did some business process and revenue analysis and realized that the primary motivation behind these system deployments was the float.

About the same time that there was the EU about the privacy of electronic retail payments ... there was also a statement by the EU (and some of the country central banks) that the offline products would be allowed to keep the float for a short grace period .... to help in the funding of the infrastructure deployment ... but after the grace period ... the operators would have to start paying interest on the balance held in the "offline" instruments (eliminating float from the equation). After that, much of the interest in the offline deployments drifted away.

In that time frame we had also done design, implementation and deployment of a payment transaction infrastructure supporting target marketing ... recent reference
http://www.garlic.com/~lynn/2008c.html#27 Diversity

support was for a small pilot of 60mil accounts and 1.5million transaction/day ... but capable of scaling up to 20-30 times that amount. There was significant attention paid to privacy issues and it was subject to quarterly auditing by some dozen or so privacy organizations. there had to be a large amount of sensitive treatment of the information along the lines of what HIPAA specifies for health information.

aka:
anonymized
Previously identifiable data that have been deidentified and for
which a code or other link no longer exists. An investigator would
 not be able to link anonymized information back to a specific
individual. [HIPAA] (see also anonymous, coded, directly
 identifiable, indirectly identifiable)

as part of co-authoring x9.99 financial privacy standard, one of the things we created was a privacy merged glossory and taxonomy ... including GLBA, HIPAA, and EU-DPD references some notes:
http://www.garlic.com/~lynn/index.html#glosnote

in our work on x9.59 financial transaction standard
http://www.garlic.com/~lynn/x959.html#x959

we made the statement that it was privacy agnostic ... since the transactions were tied to accounts ... but then whether or not the accounts were tied to individuals was outside the x9.59 standard
http://www.garlic.com/~lynn/subpubkey.html#x959

As a total aside ... as part of the Digicash liquidation, we were brought in to evaluate the patent portfolio.

Break the rules of governance and lose 4.9 billion

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 4, 2008 04:05 PM
Subject: Break the rules of governance and lose 4.9 billion...
Blog: Financial Cryptography
Dave Birch wrote:
I'm still puzzled where the system spending has gone though. For the past ten years, at every financial services event I've been to, bank guys have been complaining that they have no money for innovative new systems because all the money is going on compliance. They can't possibly have wasted all of the money on management consultants: some small fraction must have eventually gone on some actual controls. Somewhere in SocGen there must have been a line of code like "if value-at-risk > banks-total-capitalisation then sound-alarm" or something.

re:
http://www.garlic.com/~lynn/aadsm28.htm#13 Break the rules of governance and lose 4.9 billion
http://www.garlic.com/~lynn/aadsm28.htm#14 Break the rules of governance and lose 4.9 billion

i was at a financial conference in europe a couple of yrs ago ... one of the main topics was that sox compliance costs was starting to creep into european companies (and some companies were starting to move off american exchanges attempting to avoid sox compliance)

i took the position that much of sox was more of the same kind of auditing ... and there was a lot of fraud which was getting by the kind of auditing ... and more of the same kind of auditing wasn't going to catch it; it was going to require different approaches.

a couple recent articles on the socgen subject:

Government report alleges risk and security failures at SocGen
http://www.finextra.com/fullstory.asp?id=18037
Neglected IT Tasks May Have Led to Bank Meltdown
http://www.pcworld.com/businesscenter/article/142137/neglected_it_tasks_may_have_led_to_bank_meltdown.html
Poor password management may have led to bank meltdown
http://www.infoworld.com/article/08/02/04/Poor-password-management-may-have-led-to-bank-meltdown_1.html
and some related comments
http://www.garlic.com/~lynn/2008c.html#76

misc. past posts mentioning sox:
http://www.garlic.com/~lynn/aadsm19.htm#10 Security as a "Consumer Choice" model or as a sales (SANS) model?
http://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#10 PGP "master keys"
http://www.garlic.com/~lynn/aadsm25.htm#12 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#14 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#15 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#26 Fraudwatch - how much a Brit costs, how to be a 419-er, Sarbanes-Oxley rises as fraud rises, the real Piracy
http://www.garlic.com/~lynn/aadsm25.htm#43 Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
http://www.garlic.com/~lynn/aadsm26.htm#2 Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
http://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
http://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley
http://www.garlic.com/~lynn/2006j.html#28 Password Complexity
http://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006u.html#22 AOS: The next big thing in data storage
http://www.garlic.com/~lynn/2007b.html#63 Is Silicon Valley strangeled by SOX?
http://www.garlic.com/~lynn/2007j.html#0 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#74 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#75 IBM Unionization
http://www.garlic.com/~lynn/2007o.html#0 The Unexpected Fact about the First Computer Programmer
http://www.garlic.com/~lynn/2007r.html#61 The new urgency to fix online privacy
http://www.garlic.com/~lynn/2008.html#71 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008.html#78 As Expected, Ford Falls From 2nd Place in U.S. Sales

middle banking in a english muddle

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 6, 2008 05:23 PM
Subject: middle banking in a english muddle
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/000999.html
http://www.garlic.com/~lynn/aadsm28.htm#25 middle banking in a english muddle

Fraud: 1 in 5 Cards Cloned At ATMs and Chip & Pin
http://www.financedaily.co.uk/showNews.aspx?loadid=00951

from above:
"Card fraud is a serious concern that is still common despite preventative measures put in place to combat this ,including Chip and PIN," said Zoe Manton, head of Card Protection at CPP. "Fraud levels increased by 26% in the first six months of 2007 compared to the same period in 2006, to reach GBP264m."

... snip ...

Chip&PIN cards: 1 in 5 cloned?

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 9, 2008 09:42 AM
Subject: Chip&PIN cards: 1 in 5 cloned?
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001002.html
http://www.garlic.com/~lynn/aadsm28.htm#28
http://www.garlic.com/~lynn/2008c.html#89

A little of the "consumers favor PINs" article discussed in this post/thread
http://www.garlic.com/~lynn/2008d.html#3

including discussion of various efforts regarding various alternatives over nearly two decades

and runs into followup post
http://www.garlic.com/~lynn/2008d.html#8

which wanders into this reference over at digital money; short lead-in
How pathetic is it that when I want to buy something on the Internet using my bank card I have do mess around typing in endless details, numbers, codes, passwords and the like. It's all so 1994. In an a modern economy, that sort of thing is seen as being on a par with Babylonian clay tablets or filling out paper forms to make a SEPA Credit Transfer. But in advanced countries, there is another way:

... snip ...

aka, dates back to the payment gateway
http://www.garlic.com/~lynn/subnetwork.html#gateway
done with small client/server startup that had invented this technology SSL
http://www.garlic.com/~lynn/subpubkey.html#sslcert
that they wanted to apply to the business processes ... now frequently referred to as "electronic commerce".

Fixing SSL (was Re: Dutch Transport Card Broken)

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Date: Sat, 09 Feb 2008 21:14:23 -0500
To: David Wagner <daw@xxxxxxxx>
CC: cryptography@xxxxxxxx
David Wagner wrote:
I'd be interested in hearing your take on why SSL client certs aren't widely adopted. It seems like they could potentially help with the phishing problem (at least, the problem of theft of web authenticators -- it obviously won't help with theft of SSNs). If users don't know the authentication secret, they can't reveal it. The nice thing about using client certs instead of passwords is that users don't know the private key -- only the browser knows the secret key.

The standard concerns I've heard are: (a) SSL client supports aren't supported very well by some browsers; (b) this doesn't handle the mobility problem, where the user wants to log in from multiple different browsers. So you'd need a different mechanism for initially registering the user's browser.

By the way, it seems like one thing that might help with client certs is if they were treated a bit like cookies. Today, a website can set a cookie in your browser, and that cookie will be returned every time you later visit that website. This all happens automatically. Imagine if a website could instruct your browser to transparently generate a public/private keypair for use with that website only and send the public key to that website. Then, any time that the user returns to that website, the browser would automatically use that private key to authenticate itself. For instance, boa.com might instruct my browser to create one private key for use with *.boa.com; later, citibank.com could instruct my browser to create a private key for use with *.citibank.com. By associating the private key with a specific DNS domain (just as cookies are), this means that the privacy implications of client authentication would be comparable to the privacy implications of cookies. Also, in this scheme, there wouldn't be any need to have your public key signed by a CA; the site only needs to know your public key (e.g., your browser could send self-signed certs), which eliminates the dependence upon the third-party CAs. Any thoughts on this?


in AADS
http://www.garlic.com/~lynn/x959.html#aads
and certificate-less public key
http://www.garlic.com/~lynn/subpubkey.html#certless

we referred to the scenario as person-centric ... as a contrast to institutional-centric oriented implementations.

past posts in this thread:
http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch Transport Card Broken)
http://www.garlic.com/~lynn/aadsm28.htm#24 Fixing SSL (was Re: Dutch Transport Card Broken)
http://www.garlic.com/~lynn/aadsm28.htm#26 Fixing SSL (was Re: Dutch Transport Card Broken)

Fixing SSL (was Re: Dutch Transport Card Broken)

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Date: Sun, 10 Feb 2008 05:41:30 -0500
To: David Wagner <daw@xxxxxxxx>
CC: cryptography@xxxxxxxx
re:
http://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL

so lots of the AADS
http://www.garlic.com/~lynn/x959.html#aads

scenarios are that every place a password might appear, have a public key instead.

for various of the cookie authentication operations ... also think kerberos tickets. recent reference
http://www.garlic.com/~lynn/2008c.html#31 Kerberized authorization service

part of the scenario for cookie/ticket encryption ... involving servers, is brute force attack on the server secret key. the cookie instead of all encrypted data ... has some sort of client registration value ... analogous to an account number or userid. the cookie caries the registration value followed by the server encrypted data. the encryption part uses a derived key ... formed by combination of the server's secret key and the client's registration value. these derived key scenarios are also found in transit system operation (both magstripe and memory chip) as well as financial transactions.

the issue then is initial registration ... the part where the user chooses their userid (and/or the client registration value is otherwise selected) and supplies a password (but in this case a public key). m'soft and others have been using CAPTCHA to weed-out the non-humans, but this has come under attack. reference to recent news items
http://www.garlic.com/~lynn/2008d.html#2 Spammer' bot cracks Microsoft's CAPTCHA

the ticket/cookie carries the clients public key (and whatever other characteristics) ... which then can be used by the server(s) to perform dynamic authentication (digital signing of some server supplied, random data, countermeasure to replay attacks). this is in lieu of server having to maintain the client account record ... ala a RADIUS scenario where public key has been registered in lieu of a password (some sort of online access to RADIUS account records). various RADIUS public key in lieu of password postings:
http://www.garlic.com/~lynn/subpubkey.html#radius

the ticket/cookie scenario (with derived key encryption) is cross between dynamic server-side account record data (say RADIUS repository) and stale, static digital certificate scenario. as in the transit gate operation, the ticket/cookie could also be retrieved, decrypted, updated, re-encrypted, and returned as part of the operation. initial server hand-shakes can include server sending some random challenge data. The client returns the digital signature and their previously obtained cookie. in the straight RADIUS public key handshake scenario, just the digital signature and client userid/account-number is returned since the rest of the cookie/ticket equivalent info is online in the RADIUS account repository.

The straight RADIUS scenario would be to combine the server-side random challenge data and combine it with the client registration value (account number, userid) and whatever else the client-side digital signing requires ... and return the userid/account-number any other data and digital signature (i.e. server-side has to be able to reconstruct what the client actually digitally signed as part of verifying the digital signature). In the straight RADIUS scenario, the public key (and any associated permissions, authorization, etc) is obtained from the RADIUS repository. In cookie/ticket scenario, it is obtained from the cookie/ticket appended to the message.

The business process still has the initial registration phase ... where the original cookie is created (or in the RADIUS scenario, where the userid definitiion is initially created) and the public key is supplied (in lieu of a password).

This is also effectively the original certificate-less pk-init scenario for kerberos (aka public key in lieu of password)
http://www.garlic.com/~lynn/subpubkey.html#kerberos

The cookie scenario is standard client/server ... attempting to eliminate the server having to retain the account record on behalf of every client (as in either the RADIUS and/or KERBEROS scenario). Encrypting of the cookie data is standard ... although transit systems and financial transactions have gone to derived key for the situation ... as countermeasure to brute force attack on an infrastructure secret key.

How does the smart telco deal with the bounty in its hands?

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 11, 2008 10:22 AM
Subject: How does the smart telco deal with the bounty in its hands?
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001003.html

Over a decade ago, there was a lot of hype that telcos would take over the payment industry ... that their phone call transaction systems were positioned for handling the scaleup (that would happen with things like micropayments, cellphones, etc).

A couple yrs later (when it wasn't happening), the excuses were that the telcos weren't positioned (didn't have enuf infrastructure, experience, etc) to handle the financial liability (and fraud).

recent post mentioning the scenario
http://www.garlic.com/~lynn/aadsm27.htm#66

in that timeframe there were some number of "in-core" dbms systems developed; they supported transaction semantics ... but the default location for records were in memory ... as opposed to the default record location on disk (and memory used for caching). these products claimed something like ten times performance improvement vis-a-vis traditional disk-oriented dbms implementations (using same exact configuration and real storage size) ... and found lots of uptake among telco customers. In the past couple yrs, there has been announcements about some of the payment networks installing these products (usually associated with comments about supporting scaleup issues).

some old posts:
http://www.garlic.com/~lynn/2004e.html#25
http://www.garlic.com/~lynn/2007m.html#47

for topic drift ... some comments about early uptake of relational dbms coming with the increases in system real storage sizes (caching information used by rdbms to automatically handle stuff that required manual administration and application programming in earlier dbms implementations)
http://www.garlic.com/~lynn/2008c.html#78
http://www.garlic.com/~lynn/2008c.html#88
http://www.garlic.com/~lynn/2008d.html#11

on Revocation of Signing Certs and Public Key Signing itself

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 12, 2008 02:25 PM
Subject: on Revocation of Signing Certs and Public Key Signing itself
Blog: Financial Cryptography
the certification authorities have been looking to go up the value chain for sometime now.

the x.509 identity digital certificates from the early 90s ran into a number of issues. the paradigm is basically targeted at offline email authentication that existing in the early 80s (taking a page from the letters of credit/introduction from sailing ship days).

the paradigm ran into numerous discontinuities by the mid-90s

1) online was becoming ubiquitous so relying parties would have connectivity to authoritative agency and get timely information as to the party they were dealing with (as alternative to the stale, static information in the digital certificates)

2) attempting to increase the value of the certificates, there was direction of increasingly overload them with personal information. however, by the mid-90s, is had become apparent to most institutions that identity certificates, grossly overloaded with personal information, represented severe liability and privacy problems. the approach then was to retrench to relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
however, it was trivial to demonstrate that the repositories required as part of the RPO-paradigm, made any digital certificate redundant and superfluous

Certification authorities then looked at branching into

1) no-value applications ... possibly internet operations that couldn't justify the cost of maintaining their own repositories and/or making online transactions

2) non-repudiation

we had been called in to help word-smith the cal. electronic signature legislation (and later the federal electronic signature legislation) ... and the lawyers involved laid down the requirements for equivalence to human signature ... i.e. indication that the human had read, understood, agrees, approves, and/or authorizes
http://www.garlic.com/~lynn/subpubkey.html#signature

examing x.509 standard digital signature defined processes ... it was possible to drive large aircraft carriers thru the holes with regard to non-repudiation.

part of the efforts attempting to address some of the gaps were trusted time-stamping ... and a decade ago, we actually reviewed some number of the startups getting into trusted time-stamping.

Other gaps are related to possible "dual-use" vulnerabilities ... i.e. same private key being used for normal authentication operations as well as non-repudiation operations. In numerous purely authentication implementations, the human never actually examines the bits being digitally signed. An attack pattern involves substituting legal documents for random bits (normally used in authentication operations). The countermeasure isn't appended a disclosure to every digital signed message which claims to meet human signature requirements (since that could also be faked). The actual countermeasure would either a) never use the same key-pair for both purposes and/or b) always append a disclosure on every set of bits that have been digitally signed w/o first having been directly examined by the human ... explicitly stating that the bits are being digitally signed w/o having been read (aka every authentication message will require the disclosure appended to the bits before signing ... aka included as part of the signed bits).

on Revocation of Signing Certs and Public Key Signing itself

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 13, 2008 09:50 AM
Subject: on Revocation of Signing Certs and Public Key Signing itself
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm28.htm#33 on Revocation of Signing Certs and Public Key Signing itself

the dual-use scenario was just one of the gaps that aircraft carriers could be driven thru ... and the disclaimer appended to every non-read, digitally signed, bit-string ... was at "least" required.

as in past posts about electronic signatures
http://www.garlic.com/~lynn/subpubkey.html#signature

there are significant other requirements for indicating that something has been read, understood, agrees, approves, and/or authorizes (i.e. the disclaimer on non-read messages are just there to eliminate attackers spoofing claims that the bit-string had been read).

an example is pin-debit at point of sale ... digital signatures (aka demonstration of something you have authentication, aka possession of the respective private key) is analogous to pin entry (something you know authentication) at the POS terminal.

However, the authentication is totally separate and independent of demonstration of human having read, understood, agrees, approves, and/or authorizes. In the POS terminal scenario ... it is the pressing of the "yes" button in response to question about agreeing to the transaction. This scenario has authentication and "human signature" equivalence as totally independent operations.

as in other posts about human signatures and digital signatures ... there apparently is lots of semantic confusion caused by both terms containing the word "signature".

H2.1 Protocols Divide Naturally Into Two Parts

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 13, 2008 12:36 PM
Subject: H2.1 Protocols Divide Naturally Into Two Parts
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001004.html

part of the existing POS/ATM/etc environment involves a single round-trip transaction operation.

some of the internet implementations have ignored atomicity and commit transaction principles.

i remember sigmod conference circa 1992 in san jose where there was some discussion of the x.5xx stuff. one of the people present attempted to explain what was going on as a bunch of networking engineers attempting to re-invent 1960s database technology.

some of the past ecommerce specifications for the internet involved large amounts of protocol chatter ... on the internet side ... which was all then (effectively) thrown away as part of interfacing to payment gateway to perform the actual transaction. in at least some cases, this represented a factor of 100 times increase in both payload and processing bloat ... compared to the actual transaction.

as a result there was enormous complexity and impedance mismatch between what was being doing on the internet side ... and what was happening as part of the actual financial transaction.

for some topic drift ... this is recent post referencing working out details for distributed lock manager for massive parallel database scaleup
http://www.garlic.com/~lynn/2008c.html#81
to start drifting back to the subject ... this old post regarding meeting on massive database scaleup
http://www.garlic.com/~lynn/95.html#13

two of the people, mentioned in the above referenced meeting, later show up in a small client/server startup responsible for something called the commerce server. we were brought in as consultants because they wanted to do payment transactions on the server. it turns out that the small client/server startup had this technology called SSL that they wanted to use for the process. The resulting effort included something called a payment gateway
http://www.garlic.com/~lynn/subnetwork.html#gateway

and is now frequently referred to as electronic commerce.

However, these recent posts mentions the enormous inefficiency associated with layering SSL on top of TCP for transaction operation
http://www.garlic.com/~lynn/aadsm28.htm#11 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#21 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#22 Dutch Transport Card Broken

for other topic drift ... this is short thread about whether financial operations requires five-nines availability
http://www.garlic.com/~lynn/2008d.html#21
http://www.garlic.com/~lynn/2008d.html#30

the issue here is that a lot of payment infrastructure having authorization occurring as part of real-time transactions ... but actual settlement occurs later in some sort of batch operation (frequently in something called the overnight batch window) and requires reconciliation between the separate authorization and settlement operations.

one of the emerging issues is that for the past 10-15 yrs or so, there have been numerous efforts to re-engineer the batch settlement and combine it with the authorization function, sometimes referred to as straight-through processing.

Say it ain't so? MITM protection on SSH shows its paces

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 17, 2008 05:19 PM
Subject: Say it ain't so? MITM protection on SSH shows its paces...
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001007.html

ssh client is suppose to honor

PasswordAuthentication no
Protocol 2
StrictHostKeyChecking yes

so that it becomes even harder (explicit effort) to override and fallback to password.

note that PKI was designed to address first time communication between strangers ... where the relying party has no other mechanism for authenticating the stranger (i.e. the offline email scenario from the early 80s ... where relying party dialed local electronic post office, exchanged email and hung up ... this is the analogy to the letters of credit/introduction from the sailing ship days).

PKI doesn't actually make initial key distribution/exchange issues disappear ... they are simply obfuscated under layers of complex, expensive protocols and business processes. First off, the certification authority(s) public key has to be securely distributed to the relying parties (in a trusted manner). Most existing implementations involve certification authority public keys being included in some application distribution (and end-users have to trust that the correct keys were included in the application build and were never subsequently compromised before coming into their possession).

Then the digital certificates that are created by certification authorities ... need a trusted registration authority process ... where individuals and/or systems reliably transmit their keys to the registration authority. the registration authority then has to vet these keys before the digital certificates are created and returned.

All of these (mostly obfuscated) PKI processes don't fundamentally differ with what would happen in a purely SSH scenario (aka a remote server new key acceptance is on par with what would be needed to accept a new certification authority key or a certification authority checking out a key pursuant to creation of new digital certificate).

Any claims that the SSH model couldn't work implied that fundamental, underlying PKI implementations also couldn't work ... once the enormous obfuscating PKI business processes, costs, and complexity were stripped away.

Attack on Brit retail payments -- some takeways

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 27, 2008 07:43 AM
Subject: Attack on Brit retail payments -- some takeways
Blog: Financial Cryptography

http://financialcryptography.com/mt/archives/001009.html

recent post on this subject with some additional references
http://www.garlic.com/~lynn/2008e.html#34

as i've mentioned before, we were called in to consult with small client/server startup that wanted to do payment transactions on their server (also had invented this stuff called SSL)
http://www.garlic.com/~lynn/subnetwork.html#gateway

which is frequently now called electronic commerce.

we then also got involved with the x9a10 financial standards working group that had been give the requirement to preserve the integrity of the financial infrastructure for all retail payments. part of this included doing detailed end-to-end vulnerability and threat analysis.

various vulnerabilities/threats ... some of which were decades old

compromised card acceptor devices (both magstripe and chip) skimming attacks evesdropping attacks security and data breaches replay attacks because of associated static data paradigm

some of this has been previously discussed in the threads related to naked transactions ... misc. posts here
http://www.garlic.com/~lynn/subintegrity.html#payments

the x9a10 financial standard working group produced the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959

part of the standard was making x9.59 immune from evesdropping, security & data breaches, various skimming attacks and some of the card acceptor device compromises. x9.59 didn't do anything to hide the transaction information ... but it made it useless to the crooks for purposes of doing fraudulent transactions.

we've claimed that the major use of SSL in the world is its use in electronic commerce ... which we had previously done ... for hiding financial transactions. however, x9.59 standard turns out to eliminate needing SSL to hide electronic transactions as a fraudulent financial transacton countermeasure.

The remaining cases of compromised card acceptor devices, we had claimed would require personal transaction devices ... possibly built off of cellphone or PDA platforms using wireless interfaces (since x9.59 had already eliminated evesdropping on the internet as a vulnerability ... it would also eliminate wireless evesdropping between POS interface and a personal transaction device, as a vulnerability).

some of this can be seen in discussions involving the EU FINREAD standard from the 90s. FINREAD would be a personal card acceptor device that met some integrity evaluation criteria. However, in the FINREAD standard ... there was no provision to provide assurance (to a financial institution) that a FINREAD device was actually being used.
http://www.garlic.com/~lynn/subintegrity.html#finread

X9.59 provided provisions for things like dual-signatures ... one to authenticate the entity generating the transaction and a second to authenticate the environment integrity where the transaction originated. This is something we referred to as parameterised risk management ... being able to provide the approving financial institution additional assurance about the environment and possibly location where the transaction was performed.

The Trouble with Threat Modelling

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 10, 2008 06:33 AM
Subject: The Trouble with Threat Modelling
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001013.html

the non-repudiation schtick we saw in the 90s with payment transactions ... was that it supposedly would be used to change the burden of proof in consumer disputes ... which was worth a lot to merchants/banks (and implied that they would be willing to fork over a whole lot for digital signature infrastructure).

this is akin to some of the activity currently going on in the UK with respect to payment transaction disputes.

this was later brought home by lawyers that we dealt with when we were brought in to help wordsmith the cal. state (and later federal) electronic signature legislation.
http://www.garlic.com/~lynn/subpubkey.html#signature

where there seemed to be quite a tendency to promote semantic confusion just because the terms "human signature" and "digital signature", both contained the word "signature".

Format Wars: XML v. JSON

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 12, 2008 11:17 AM
Subject: Format Wars: XML v. JSON
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001014.html

thats nothing ... should have seen the format wars during the 90s in the financial standards bodies with *ML vis-a-vis ASN.1 .... especially the x.509 contingent ... except *MLs were being treated as the new-comer

disclaimer, *MLs were invented by G, M, & L in 1969 at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
... a decade later standardized as SGML
http://www.garlic.com/~lynn/submain.html#sgml

and then begat HTML, XML and a whole slew of other *MLs.
http://infomesh.net/html/history/early/

Attack on Brit retail payments -- some takeways

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 12, 2008 04:19 PM
Subject: Attack on Brit retail payments -- some takeways
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001009.html

originally suppose to go down ... but went up by better than 1/3rd instead:

Card fraud GLB150m worse than expected
http://www.thisismoney.co.uk/news/article.html?in_article_id=431514

also
http://www.garlic.com/~lynn/aadsm28.htm#25
http://www.garlic.com/~lynn/aadsm28.htm#28
http://www.garlic.com/~lynn/2008e.html#69
http://www.garlic.com/~lynn/aadsm28.htm#38

and more recent:
APACS Reports Card Fraud Statistics for 2007
http://www.paymentsnews.com/2008/03/apacs-reports-c.html
Increases in card fraud
http://www.loans4.co.uk/loan_news/news.php?item=281-Increases_in_card_fraud-281
New figures show rise in card fraud
http://www.computeractive.co.uk/computeractive/news/2211865/apacs-figures-show-rise-card
Card fraud abroad up claims APACS
http://www.itpro.co.uk/security/news/177357/card-fraud-abroad-up-claims-apacs.html
Credit card fraud hits record levels
http://financialadvice.co.uk/news/2/creditcards/6464/Credit-card-fraud-hits-record-levels.html
Overseas card fraud rises by 25%
http://www.bankingtimes.co.uk/12032008-overseas-card-fraud-rises-by-25/
Credit card fraud reaches record levels
http://ftadviser.com/FTAdviser/Insurance/News/article/20080312/39fdaf52-f02a-11dc-bfbb-0015171400aa/Credit-card-fraud-reaches-record-levels.jsp
Card fraud soars to record high despite chip and pin
http://news.scotsman.com/uk/Card-fraud-soars-to-record.3868258.jp
Criminal gangs fuel a record 25 per cent rise in card fraud
http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=531068&in_page_id=1770
Credit card fraud soars despite 'chip and pin'

http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2008/03/12/nfraud112.xml
Plastic card fraud goes back up
http://news.bbc.co.uk/1/hi/business/7289856.stm

Trojan with Everything, To Go!

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 13, 2008 10:18 AM
Subject: Trojan with Everything, To Go!
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001015.html

some of this dates back to EU finread terminal standard in the 90s ... which identified personal computer end-points as particularly vulnerability ... misc. past posts
http://www.garlic.com/~lynn/subintegrity.html#finread

this was before some disastrous deployment attempts brought personal computer addons into such disrepute (one of the things that USB was designed to handle) ... a few old references:
http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#50 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm27.htm#52 more on firing your MBA-less CSO

as implied, the mechanics of how the operations are performed can contribute significantly to the vulnerabilities ... discussed in the old "naked transaction" metaphor blog entries, threads, and posts:
http://www.garlic.com/~lynn/subintegrity.html#payments

and for a little more topic drift ... when there are security solutions that tend to be simple point solutions ... and not provide end-to-end coverage ... leaves enormous infrastructure vulnerability leakage:

Data Protection is Impossible
http://www.cioupdate.com/article.php/3733716

one of the x9.59 financial transaction standards characteristics
http://www.garlic.com/~lynn/x959.html

was not to try and eliminate all the places that information could leak ... but change the paradigm so that such information leakage didn't represent a threat or vulnerability.

Trojan with Everything, To Go!

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 13, 2008 02:08 PM
Subject: Trojan with Everything, To Go!
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm28.htm#41

the issue of encrypted/armored sessions somewhat assumes that the vulnerability are (session) evesdropping attacks. purely session-based protection mechanisms are significantly more vulnerable to end-point compromises

article on this trojan from jan08:

New Trojan intercepts online banking information
http://www.networkworld.com/news/2008/011708-yahoo-to-support-openid-single.html

similar trojan from dec07:

New Trojan Attacks Clients At Four Worldwide Banks
http://www.crn.com/security/204803106 Sophisticated Trojan loots business bank accounts
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9053018

article from may06 mentioning similar trojan from nov04:

How SSL-evading Trojans work
http://www.infoworld.com/article/06/05/01/77515_18FEsslmalwareworks_1.html?s=feature

both SSL and VPN showed up in IETF about the same time. The problems with home personal computers as end-point of VPN into corporate networks was well recognized in the 90s ... the issue was also part of what led to EU FINREAD standard ... much of the design predicated as countermeasure to personal computer vulnerabilities.

somebody that we had worked with on & off over 10-15 yrs had developed encrypted sessions for his own use from home and then introduced it as VPN in gateway committee at '94 IETF meeting in san jose.

about the same time, we were brought in to consult with small client/server startup that wanted to do payments on their server. two people responsible for something they called a "commerce server" ... when we were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
and cluster scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa
they had been at a large rdbms vendor ... old meeting
http://www.garlic.com/~lynn/95.html#13

the client/server startup had this technology they called SSL that they wanted to use with what has since come to be called electronic commerce ... and various aspects of electronic commerce (primarily targeted at hiding credit card numbers) is probably the majority use on the internet today.

we were then brought in to x9a10 financial working group that had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... which resulted in the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959

part of the work was detailed end-to-end threats & vulnerability analysis ... which identified a whole slew of things other than session evesdropping attacks (some also identified in the EU FINREAD standards work).

the resulting x9.59 financial standard ... armored the transaction ... previously discussed in the various naked transaction metaphor threads
http://www.garlic.com/~lynn/subintegrity.html#payments

which eliminated evesdropping as a threat ... and also eliminated the requirement for encrypted sessions as a countermeasure to fraudulent transactions. the spate of online banking trojans are various work arounds to encrypted sessions ... x9.59 armored transactions eliminates the need to have encrypted sessions ... and therefor the perception that online banking is secure based on encrypted sessions.

Armored transactions are still subject to the integrity of the originating endpoint ... something that the EU FINREAD work attempted to address as compensating process.

Realistic dynamics of contactless

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: 14 March 2008 at 05:07 PM
Subject: Realistic dynamics of contactless
Blog: Digital Money
re:
http://digitaldebateblogs.typepad.com/digital_money/2008/03/realistic-dynam.html
Transit systems are heavily subsidized. There has been fairly heavy lobbying that while gov. subsidy of transit operation isn't a bad thing ... gov. subsidies for payment system implementations aren't a good thing ... especially when there are perfectly good payment systems already available.
some number of transit systems have been told that there won't be any more gov. subsidies for payment system implementations/operations
there have been a couple recent studies claiming that consumers are decidingly NOT flocking to pin-less debit transactions ... despite the heavy tv commercials touting the benefits.
U.S. Consumers Prefer PIN Debit
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1203376639837016673&block=

Debit users say the PIN is mightier
http://blogs.consumerreports.org/money/2008/02/debitcards_pins.html

there are (at least) two issues about pin-less debit

1) studies claim that pin-less debit has 15 times the fraud of pin-debit

2) even if a card is always used as pin-debit ... the card could still be enabled for pin-less operation.

recent discussion of some problems enabling traditional pin-debit cards for pin-less operation (for a card in ireland that had never been used and therefor there was never possibility of it even being skimmed)
http://www.garlic.com/~lynn/2008b.html#67

Realistic dynamics of contactless

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: 15 March 2008 at 06:07 PM
Subject: Realistic dynamics of contactless
Blog: Digital Money
re:
http://www.garlic.com/~lynn/aadsm28.htm#43 Realistic dynamics of contactless
http://digitaldebateblogs.typepad.com/digital_money/2008/03/realistic-dynam.html

Study: Signature Debit Fraud Runs 15 Times Higher Than on PIN Debit
http://www.digitaltransactions.net/newsstory.cfm?newsid=738

long ago and far away, we were called in to work with a small client/server startup that wanted to do payment transactions on their server and they had this technology they called SSL they wanted to use ... the result is now frequently referred to as electronic commerce ... a recent x-over thread:
http://www.garlic.com/~lynn/aadsm28.htm#42 Trojan with Everything, to Go!

in this blog:
http://financialcryptography.com/mt/archives/001015.html

we then got dragged into the x9a10 financial standard working group that had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... which resulted in the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959

then we were asked to work with some of the companies that bid systems for many of the transit systems around the world. we included their requirements when we spec'ed the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads

... i.e. proximity, iso14443 power draw, transit gate elapsed time requirements ... but also having much higher integrity (and much lower cost) ... and being able to do x9.59 transaction within those specifications.

Realistic dynamics of contactless

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: 16 March 2008 at 09:44 PM
Subject: Realistic dynamics of contactless
Blog: Digital Money
re:
http://www.garlic.com/~lynn/aadsm28.htm#43
http://www.garlic.com/~lynn/aadsm28.htm#44

note that iso7816 standard was from the 80s with the possibility of portable computing chips but w/o the technology for portable input and output technologies. the solution was to have fixed stations/terminals for input/output for the portable computing devices. this paradigm required an interface standard between the fixed stations and the portable devices.

going into the early 90s, with the wider availability of portable devices with input/output capability (cellphones and PDAs) ... standardized physical interface and form factors became obsolete ... i.e. portable equipment could use contact free communication mechanisms and it would be possible to transition to form factor agnostic operation (as mentioned in the early AADS chip strawman discussions)

part of the issue was that lots of organizations and institutions had sunk billions into the iso7816 paradigm ... and were willing to recoup their investment ... even at few cents on the dollar.

this was part of the stuff we looked at in the mid-90s with regard to x9.59 financial standard and form factor agnostic contactless technologies.

The bond that fell to Earth

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: 18 March 2008 at 05:10 PM
Subject: The bond that fell to Earth
Blog: Digital Money
re:
http://digitaldebateblogs.typepad.com/digital_money/2008/03/the-bond-that-f.html

recent post in thread about mortgage backed securities
http://www.garlic.com/~lynn/2008f.html#57

(toxic) CDOs had been invented by Milken back in the late 80s to obfuscate what they represented ... longer discussion
http://www.garlic.com/~lynn/2008f.html#53

rating houses were giving them triple-A ratings.

investment banks were buying them with leverage of 20&30 to 1 (i.e. 3-5percent actual investment, this is compared to old stories that 20percent margin investment significantly contributed to crash of '29 and subsequent rules requiring minimum of 80percent) There was comment that last summer Bear had been leveraged 44-to-1 and dropped back to only 30-to-1. Some recent analysis this market is now larger than nearly all other markets combined.

Rating houses then went thru period reverting many of these (toxic) CDOs to junk status. In the crash of '29, a drop in 20percent resulted in totally wiping out investors. With 30-to-1 leverage ... it only takes a drop of 3percent to totally wipe out the original investment.

decade old post that touches on providing transparency (confluence of risk management and information security) of the underlying values in these kind of securities.
http://www.garlic.com/~lynn/aepay3.htm#riskm

delegating SSL certificates

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: delegating SSL certificates
Date: Wed, 19 Mar 2008 20:54:01 -0400
To: Bill Frantz <frantz@xxxxxxxx>
CC: cryptography@xxxxxxxx
Bill Frantz wrote:
Given the current situation, with the CAs having a monopoly on issuing certificates, there are many different public keys associated with Amazon. In addition, Amazon may chose to change the CA it uses. To handle this situation, the Petname toolbar the DN instead of a public key, which opens the Petname tool bar to spoofing by any of the 100 or so CAs configured in the standard browsers. Does anyone know what happened to Baltimore's signing key when they went out of business?

to some extent it is floundering around for an economic model.

as i've frequently commented, digital certificate is the electronic analog to letters of introduction/credit from sailing ship days when the relying party had no other recourse to contacting the authoritative agency (i.e. it was better than nothing) ... applied to the "offline email" paradigm (i.e. first time communication between two strangers when relying party calls up the electronic postoffice, exchanges email and then hangs up before processing the incoming email).

in the transition to ubiquitous internet, those digital certificates become obsolete. predating the internet, traditional mechanism was that the relying party contacts the authoritative agency as to the credentials of the person they were dealing with and either the authoritative agency was a gov. service provided the service for "free" or the authoritative agency charged the relying party for the (timely information) service. Examples are various credit rating services (charging free to relying parties doing check) or online electronic transactions (interchange fees charged to the merchant authorizing the transaction).

Some PKI interests attempted to approximate the benefits of realtime service while trying to maintain the facade that the digital certificate still represented some useful function .... stuff like OCSP.

The biggest revenue stream for the PKI business has been the electronic commerce stuff associated with SSL ... from the original design point (which was pretty much cutback to just the payment portion of the operations, violating original SSL use assumptions and introducing vulnerabilities).

It turns out that PKI revenue stream was quite bracketed because none of the institutions were willing to take on liability ... and merchants were already paying significant amounts via interchange fees ... which were effectively providing a form of liability coverage.

In the real liability situation ... there is contractual relationship between consumer and their financial institutions along with a contractual relationship between the merchant and their financial institutions ... and the associations create interlocking contractual relationships between the consumer financial institutions and the merchant financial institutions.

The PKI operations have provided none of that.

As usual, lots of past posts related SSL digital certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

quite a few of them discussing "merchant comfort certificates" ... aka w/o any actual practical coverage ... they've had to fall back to feel goody statements justifying the need for their product.

World's biggest PKI goes open source: DogTag is released

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 20, 2008 07:41 AM
Subject: World's biggest PKI goes open source: DogTag is released
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001017.html

post from yesterday in crypto mailing list
http://www.garlic.com/~lynn/aadsm28.htm#47 delegating SSL certificates

the claim has been that the business model is bigger issue than the technical issues. PKI process is the digital certificates which are the letters of credit/introduction from the sailing ship days ... where the relying party has no other recourse to information regarding first time interaction with total stranger. it was created for the offline email scenario from the early 80s, where somebody dialups the electronic postoffice, exchange email, and hang up. then the recipient has to deal with first time email from complete stranger.

with any sort of information about the party being dealt with and/or timely direct access to authoritative agency about a complete stranger ... then the digital certificates are redundant, superfluous and obsolete.

a 2nd issue with the business model was that going into the mid-90s, it was realized that the earlier x.509 identity certificates (increasingly overloaded with personal information) represented significant liability and privacy issues. as a result there was a lot of retrenchment to relying-party-only certificates containing nothing but some sort of record locator. However it was trivially shown that if the record has to be accessed ... then the digital certificate was (again) redundant and superfluous
http://www.garlic.com/~lynn/subpubkey.html#rpo
or, as in other posts can be trivially compressed to zero bytes, recent post mentioning zero byte digital certificates:
http://www.garlic.com/~lynn/2008.html#7 folklore indeed
http://www.garlic.com/~lynn/2008.html#8 folklore indeed

another issue specifically with the 3rd party PKI business model, was traditionally, a relying party has some sort of contractual relationship with the authoritative agency (say when they are doing background check with credit agency). In the 3rd party PKI business model, there is a relationship between the certification authority and the entity that the certificate has been issued for ... but no contractual relationship between the certification authority and the relying parties (effectively negating traditional business processes). In order for the gov. PKI project to address this short coming ... GSA signed contracts (as representative of gov. relying parties) with all the authorized gov. certification authorities ... creating contractual obligation between the relying parties (i.e. entities that needed to rely on the validity of the digital certificates) and the (PKI) certification authorities.

misc. past posts mentioning gov. pki project and gsa (as representative of gov. relying parties) requiring contractual relationship with all authorized certification authorities:
http://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
http://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01
http://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
http://www.garlic.com/~lynn/aadsm15.htm#8 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
http://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
http://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
http://www.garlic.com/~lynn/aadsm26.htm#34 Failure of PKI in messaging
http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)

Price point

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: 16 March 2008 at 09:44 PM
Subject: Price point
Blog: Digital Money
re:
http://digitaldebateblogs.typepad.com/digital_money/2008/03/price-point.html

there is some x-over with the recent posts
http://www.garlic.com/~lynn/aadsm28.htm#43 Realistic dynamics of contactless
http://www.garlic.com/~lynn/aadsm28.htm#44 Realistic dynamics of contactless
http://www.garlic.com/~lynn/aadsm28.htm#45 Realistic dynamics of contactless

in this blog entry
http://digitaldebateblogs.typepad.com/digital_money/2008/03/realistic-dynam.html

as part of the AADS chip strawman we had semi-facetiously claimed that we would take a $500 milspec and aggresively cost reduce it by 2-3 orders of magnitude while increasing the security.
http://www.garlic.com/~lynn/x959.html#aads

there were chipcard stored-value deployments in europe in the 90s. about the same time, there was a magstripe, point-of-sale, online stored-value offering that started deployment in the US. The EU chipcard operation basically traded off the chip-cost for doing offline transactions (because the extremely high cost and/or unavailable communications in europe) vis-a-vis the less expensive (read-only) magstripe that relied on the existing online transaction network.

The other difference in the 90s, was that the offline EU chipcard operations were branded by independent operator and were accepted by multiple different merchants. The US deployment were merchant branded and cards were only valid for a specific merchant (although at the start all implementations were provided by the same 3rd party operation).

When one of the major EU stored-value chipcard operations were looking at entry into the US market, we were asked to design, size, and cost a full-blown production operation ... and turned out while we were doing we also did the business case analysis. What we found that it looked like the prime motivation (for such an offering) was the float that went to the parent organization. It wasn't too surprising later when they were having little uptake around the world, they started making offers to split the float with individual country operations. Later, we were also not surprised when EU central banks published a notice that such stored-value operations could retain the float during startup period, but after the first couple years, the operations would have to start paying interest on unused balance in the individual accounts (modulo transit operations) ... much of the interest in doing such deployments disappeared.

For a little drift ... we claim that such an offline orientation also played significant factors for x.509 and PKI standards in the same period ... a couple recent comments here:
http://www.garlic.com/~lynn/aadsm28.htm#47 delegating SSL certificates
http://www.garlic.com/~lynn/aadsm28.htm#48 World's biggest PKI goes open source

Another issue was that many of these implementations were using decade old chip technology (while we were looking at leveraging the latest and most effective operation). At one of the transit meetings in the 90s ... a major stored-value operator showed up to discuss using their product at transit gate operation. They addressed the contactless and power consumption problems with their chip by proposing a "sleave" that contained a battery and electronics for contactless operation. However, with augmented battery power, the chip was still painfully slow. The "solution" was to create electromagnetic tunnels that extended 15ft in front of every transit turnstyle ... and have commuters walk very slow thru the tunnel to allow a transaction to complete by the time they had reached the turnstyle.

Part of the problem when we were doing end-to-end analysis of payment operations and coming up with optimal safety and optimal cost ... that such a highly efficient and optimal cost operation appeared to create too large a paradigm change for existing players in the market. It was like the existing major players couldn't easily see their place in such safe, secure, commoditized payment infrastructure.

Liability for breaches: do we need new laws?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 24, 2008 12:35 PM
Subject: Liability for breaches: do we need new laws?
Blog: Financial Cryptography
re: http://financialcryptography.com/mt/archives/001018.html

we had been been brought in to help word smith the cal. state electronic signature legislation (and later the federal legislation) ... some past posts
http://www.garlic.com/~lynn/subpubkey.html#signature

many of the parties involved were also active in the breach notification as well as the opt in/out legislative activity ... basically stuff swirling around "privacy". Some of the players had done detailed consumer surveys and found that for the most part, the privacy issue was

1) identity theft ... at the time mostly account fraud ... i.e. skimming/harvesting account numbers and performing fraudulent transactions

2) denial of service ... aka gov., commercial, private, public, etc institutions using personal information to the detriment of the individual.

much of the account fraud was coming from breaches of various kinds ... and this information wasn't being publicized ... and so the actual source of the problem wasn't being addressed ... which led to the requirement for breach notification legislation.

we didn't actually participate directly in any of the legislative activity with respect to these other efforts ... other than pointing out that the x9.59 financial standards work
http://www.garlic.com/~lynn/x959.html#x959

had eliminated breaches as an account fraud threat/vulnerability. somewhat related post over in digital money blog
http://www.garlic.com/~lynn/aadsm28.htm#49 Price point

however, later we were co-author of the x9.99 financial privacy standard ... and had to spend some amount of time looking at GLBA (with respect to opt-out notification requirement), HIPAA, EU-DPD, OECD, etc ... reference here to work on merged taxonomy and glossaries ... including one for privacy in support of the x9.99 work
http://www.garlic.com/~lynn/index.html#glosnotes

these days GLBA is getting a lot more press ... not for its opt-out/privacy ... but for its repeal of Glass-Steagall.

Liability for breaches: do we need new laws?

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 25, 2008 08:00 AM
Subject: Liability for breaches: do we need new laws?
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm28.htm#50 Liability for breaches: do we need new laws?

a little x-over
http://www.garlic.com/~lynn/2008f.html#88 Has Banking Industry Overlooked Its Biggest Breach Ever?

...

Has Banking Industry Overlooked Its Biggest Breach Ever?
http://www.darkreading.com/document.asp?doc_id=149052

from above:
Way back in July, law enforcement agencies issued a press release stating that they had indicted a former employee at Compass Bank for stealing information from the company. It now appears that the theft might be the biggest breach in banking history.

According to the privacy site PogoWasRight.org, new details about the case against former Compass employee James Kevin Real indicate that approximately 1 million customers' personal information may have been exposed in the incident.


... snip ...

Pogo reports: big(gest) bank breach was covered up?

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 26, 2008 08:05 PM
Subject: Pogo reports: big(gest) bank breach was covered up?
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001020.html
and:
http://www.garlic.com/~lynn/aadsm28.htm#50 Liability for breaches: do we need new laws?
http://www.garlic.com/~lynn/aadsm28.htm#51 Liability for breaches: do we need new laws?
http://www.garlic.com/~lynn/2008f.html#88 Has Banking Industry Overlooked Its Biggest Breach Ever?

...

Programmer who stole drive containing one million bank records gets 42 months; Only 250 customers notified of massive breach
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9072198

from above:
The Compass Bank compromise is one of the largest bank-related breaches yet revealed, in terms of the number of customer records that were potentially exposed. The incident, however, appears to have surfaced for the first time only after the Birmingham News carried a story on the sentencing last week.

... snip ...

Pogo reports: big(gest) bank breach was covered up?

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 4, 2008 06:03 PM
Subject: Pogo reports: big(gest) bank breach was covered up?
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001020.html
http://www.garlic.com/~lynn/aadsm28.htm#52 Pogo reports: big(gest) bank breach was covered up?

Insider Gets 42 Months for Stealing 1m Customer Records
http://www.infowatch.com/threats?chapter=148831545&id=207784793

from above:
According to court documents, Real stole Compass' database information in May 2007. The database included customer names, account numbers and passwords. He then used the information from the database to make counterfeit debit cards using a magnetic strip encoder and software purchased by Byrd. Between June and July 2007, the pair proceeded to use the counterfeit cards to access Compass customer accounts and withdraw funds from them, typically in amounts not exceeding $500 or so. The documents show that Real would wear disguises when making the ATM withdrawals -- in fact he was apprehended while wearing one.

... snip ...

Frequently breaches are discovered long before attackers are apprehended and all possible fraudulent activity has been identified.

In the past, breaches were kept quiet and any fraudulent activity was frequently treated as random activity. Breach notification allowed potential victims to take countermeasures (like closing account or freezing credit bureau records). There also is the possibility, publicity would help motivate preventive measures (crooks being prosecuted for fraudulent account activity but possibly never linked to breaches).

somewhat related post
http://www.garlic.com/~lynn/2008g.html#28 Hannaford case exposes holes in law, some say

The Identity Theft Resource Center Reports That Data Breaches More Than Doubled in 2008 First Quarter

http://www.foxbusiness.com/article/identity-theft-resource-center-reports-data-breaches-doubled-2008-quarter_544967_1.html
Data Breaches More Than Doubled in 2008 First Quarter
http://www.paymentsnews.com/2008/04/data-breaches-m.html
8.3 Million Records Spilled in Data Breaches This Year
http://blog.washingtonpost.com/securityfix/2008/04/83_million_records_spilled_in.html?nav=rss_blog
Data breaches more common
http://blog.seattlepi.nwsource.com/consumersmarts/archives/135617.asp
Grocery Data Breach Offers Important Endpoint Lessons
http://www.bmighty.com/blog/main/archives/2008/07/latest_figures.html

Liability for breaches: do we need new laws?

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 14, 2008 07:32 AM
Subject: Liability for breaches: do we need new laws?
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001018.html
and
http://www.garlic.com/~lynn/aadsm28.htm#50 Liability for breaches: do we need new laws?
http://www.garlic.com/~lynn/aadsm28.htm#51 Liability for breaches: do we need new laws?
http://www.garlic.com/~lynn/aadsm28.htm#52 Pogo reports: big(gest) bank breach was covered up?
http://www.garlic.com/~lynn/aadsm28.htm#53 Pogo reports: big(gest) bank breach was covered up?

recent book reference:

You won't guess who's the bad guy of ID theft

http://news.yahoo.com/s/usatoday/20080414/tc_usatoday/youwontguesswhosthebadguyofidtheft
You won't guess who's the bad guy of ID theft
http://www.usatoday.com/money/books/reviews/2008-04-13-zero-day-threat_N.htm

and comment
http://www.garlic.com/~lynn/2008h.html#4 You won't guess who's the bad guy of ID theft

Signs of Liability: 'Zero Day Threat' blames IT and Security industry

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 14, 2008 01:27 PM
Subject: Signs of Liability: 'Zero Day Threat' blames IT and Security industry
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001024.html

three financial areas ... all mentioning congressional &/or regulatory action:

breaches & ID theft:
http://www.garlic.com/~lynn/2008h.html#4 You won't guess who's the bad guy of ID theft
http://www.garlic.com/~lynn/aadsm28.htm#54 Liability for breaches: do we need new laws?

budget transparency:
http://www.garlic.com/~lynn/2008h.html#3 America's Prophet of Fiscal Doom

repeal of Glass-Steagall contributing to current write-downs
http://www.garlic.com/~lynn/2008g.html#66 independent appraisers
http://www.garlic.com/~lynn/2008g.html#67 independent appraisers
http://www.garlic.com/~lynn/2008h.html#1 subprime write-down sweepstakes

Signs of Liability: 'Zero Day Threat' blames IT and Security industry

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 16, 2008 12:25 AM
Subject: Signs of Liability: 'Zero Day Threat' blames IT and Security industry
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm28.htm#54 Liability for breaches: do we need new laws?
http://www.garlic.com/~lynn/aadsm28.htm#55 Signs of Liability: 'Zero Day Threat' blames IT and Security industry

latest in the ongoing saga

Hackers open new front in payment card data thefts; Cybercrooks are stealing info while it's in transit between systems. Can the PCI rules stop them?
http://www.arnnet.com.au/index.php/id;1285857922;fp;4194304;fpid;1

from above:
Security managers often describe their efforts to protect corporate data from being compromised as a full-fledged battle of wits against cybercrooks who are continually arming themselves with innovative tools and methods of attack.

... snip ...

this is discussed in old "naked transaction" threads ... that it will be a constant ongoing battle
http://www.garlic.com/~lynn/subintegrity.html#payments

Who do we have to blame for the mortgage crisis in America?

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 16, 2008
Subject: Who do we have to blame for the mortgage crisis in America?
Blog: Financial Markets
when financial institutions use to make a loan ... it was related to prime-rate and then they retained control of the mortgage ... so there was some attention paid to the quality of the loan.

subprime loans effectively decoupled from standard "prime rate" control mechanisms

the mortgages were then packaged as CDOs and unloaded. CDOs were used by Milken in the S&L crisis to obfuscate the value of the underlying assets. reference here:
http://articles.moneycentral.msn.com/Investing/SuperModels/AreWeHeadedForAnEpicBearMarket.aspx

now mortgage originators could make subprime loans uncoupled from prime rate ... and be able to immediately unload them as CDOs ... eliminating any necessity to pay attention to issues about loan value/quality. The only measure became how fast could loans be originated and then unloaded (and all the traditional quality, safety and soundness fell by the wayside).

long winded decade old post about the thread between risk management and information security ... including discussion about necessity for keeping adequate visibility into value of underlying components making up CDO-like instruments.
http://www.garlic.com/~lynn/aepay3.htm#riskm

In the aftermath of the crash of 29, Glass-Steagall was passed to keep the unregulated investment banking activities from polluting the safety&soundness of regulated banking. In the late 90s, Glass-Steagall was repealed. PBS website looking at the wall street fix involved in repeal of Glass-Steagall
http://www.pbs.org/wgbh/pages/frontline/shows/wallstreet

Lots of the current activities had investment banking "leveraging" CDO purchases 50 and possibly even 100 times.

article here
http://knowledge.wharton.upenn.edu/article.cfm?articleid=1933

estimates that possibly 1000 CEOs are accountable for 80% of the current lending mess & it would go a long way towards fixing things if the government could figure out how to have those CEOs loose their job.

some recent posts that piece together a number of recent business articles:
http://www.garlic.com/~lynn/2008g.html#66
http://www.garlic.com/~lynn/2008h.html#0
http://www.garlic.com/~lynn/2008h.html#1

Who do we have to blame for the mortgage crisis in America?

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 17, 2008
Subject: Who do we have to blame for the mortgage crisis in America?
Blog: Financial Markets
re:
http://www.garlic.com/~lynn/aadsm28.htm#57

This is analogy with CDO value obfuscation (showed up two decades ago in the S&L crisis) to undermining the "observe" in Boyd's OODA-loop
http://www.garlic.com/~lynn/2008g.html#4

(obfuscated) CDOs allowed the supply side (mortgage origination) to unload as fast as they could write them w/o regard to value/quality. Also enabled highly questionable subprime to greatly expand the supply side of mortgages

(obfuscated) CDOs allowed the (unregulated investment banker) demand side to repeatedly/iteratively borrow against CDO value to buy additional CDOs. Repeated 40-50 times, met that they could have CDOs with possibly only 1-2 percent actual capital (creating enormous demand for the significantly increased supply).

Repeal of Glass-Steagall then contributed ... allowing extremely risky unregulated investment banking to start to contaminate safety&soundness of regulated banking.

lots of past Boyd &/or OODA-loop posts
http://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd and/or OODA-loop
http://www.garlic.com/~lynn/subboyd.html#boyd2

Information Security Vs. Businesss Resilience

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 17, 2008
Subject: Information Security Vs. Businesss Resilience
Blog: Information Security
we actually came at it from industrial strength, business critical dataprocessing and viewed security as just part of assurance and integrity.

for a little drift, a long winded decade old post on the thread between risk management and information security
http://www.garlic.com/~lynn/aepay3.htm#riskm

we had been doing industrial strength, business critical dataprocessing for a couple decades before starting our ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp

as part of ha/cmp product we had to do some detailed availability and integrity analysis ... where security threats and vulnerabilities were something of a subset. this included looking at tcp/ip protocol and internet deployments from various facets. some of this we had a leg up on having been involved in deploying high-speed internal backbone as well as attempting to translate the technologies to NSFNET backbone ... some prior posts on that subject
http://www.garlic.com/~lynn/subnetwork.html#nsfnet
and some old email
http://www.garlic.com/~lynn/lhwemail.html#nsfnet

now two of the people that had been in the meeting mentioned in this post
http://www.garlic.com/~lynn/95.html#13

show up later (prior to the above post) at a small client/server startup responsible for something called a commerce server. we got called in to consult because they wanted to do payment transactions on the server ... and use some technology that the startup was calling SSL. Some past posts on this activity ... which frequently now is referred to as electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway

We had to do some detailed end-to-end business analysis and how various pieces of technology fit into the business processes. Part of this included doing some detailed examinations of these new things that were calling themselves certification authorities. There were some number of assumptions about how SSL needed to be deployed and used for secure operation. However, almost immediately various deployments started violating some of the fundamental assumptions ... leading to opportunities for attackers. This was behind some of our posts on the subject ... including references to SSL becoming a "comfort" feature (in contrast to fundamental security feature)
http://www.garlic.com/~lynn/subpubkey.html#sslcert

About the same time as early work in the X9A10 financial standard working group (attempting to meet the requirement to preserve the intergrity of the financial infastructure for all retail payments, that is ALL as in not just internet, not just point-of-sale, not just credit ... ALL/ANY retail payment) ... there were some other activities for internet solutions which we've some what characterized as toy internet technology demos. In most cases, they didn't provide any fundamental improvement in fraud countermeasures (compared to what was already deployed with SSL electronic commerce) ... but they did tend to increase both the payload and processing bloat by a factor of 100 times (compared to standard payment transaction)
http://www.garlic.com/~lynn/subpubkey.html#bloat

by comparison, x9.59 standard had to be a business solution as opposed to a technology toy
http://www.garlic.com/~lynn/x959.html#x959

Now having helped create the major use of SSL ... i.e. electronic commerce for hiding account numbers and transaction details ... we co-authored the x9.59 financial standard which eliminates the need for hiding this information (and therefor the major current use of SSL).

as part of marketing our ha/cmp product we coined the terms disaster survivability and geographic survivability to differentiate from disaster/recover
http://www.garlic.com/~lynn/submain.html#available

Seeking expert on credit card fraud prevention - particularly CNP/online transactions

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 17, 2008
Subject: Seeking expert on credit card fraud prevention - particularly CNP/online transactions
Blog: Information Security
Signs of Liability: 'Zero Day Threat' Blames It and Seucrity Industry
http://financialcryptography.com/mt/archives/001024.html

There are two flavors to the threat against existing payment card infrastructure ... one is the diametrically opposing requirements placed on existing transactions ... on one side they have to be kept completely confidential and never divulged and on the other side the transaction has to be available in order to execute it.

As mentioned in other references, the X9A10 financial working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. The result was x9.59 financial standard protocol
http://www.garlic.com/~lynn/x959.html#x959

One of the characteristics of X9.59 financial standard was that it did nothing to hide the transaction details ... but instead it eliminated crooks from using information from previous transaction for performing account fraud.

In addition to looking at the issue of the existing infrastructure placing diametrically opposing requirements on transaction details is something from kindergarten security 101: long winded decade old post about the thread between risk management and information security
http://www.garlic.com/~lynn/aepay3.htm#riskm

and then there is post on the topic of security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

this facet of the problem is that the value of the information to the attacker (previous transactions) can be worth 100 times more than the value to the defender. To the attacker/crook, a transaction log file is basically worth proportional to the aggregate credit limits and balances of the accounts involved in the transactions. To the merchant, a transaction log file is basically worth proportional to the aggregate net profit on the transactions. The difference between these two values can be two orders of magnitude ... basically opening the way for an attacker being able to outspend the defender/merchant by possibly 100 times (and still see significant fraud return-on-investment)

other recent posts mentioning attackers affording to significantly outspend defenders:
http://www.garlic.com/~lynn/aadsm26.htm#58 Our security sucks. Why can't we change? What's wrong with us?
http://www.garlic.com/~lynn/aadsm27.htm#3 Solution to phishing -- an idea who's time has come?
http://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA-loop of today's battle
http://www.garlic.com/~lynn/aadsm28.htm#5 Why Security Modelling doesn't work -- the OODA-loop of today's battle

Is Basel 2 out...Basel 3 in?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 18, 2008
Subject: Is Basel 2 out...Basel 3 in?
Blog: Risk Management
original basel2 draft had qualitative section (effectively demonstrating understanding of what is going on) ... in addition to traditional quantitative ... however during the review process, much of the qualitative section was eliminated.

part of the current financial shock is related to using CDOs to obfuscate the underlying value ... used two decades ago during the S&L crisis. For a little drift ... long-winded decade old post mentioning the need for much better visibility into underlying values (thread between risk management and information security)
http://www.garlic.com/~lynn/aepay3.htm#riskm

recent reference relating lack of visibility to subverting the "observe" in Boyd's OODA-loop
http://www.garlic.com/~lynn/aadsm28.htm#58

contributing was the repeal of Glass-Steagall (which had been put in place after the crash of '29 to keep unregulated risk investment banking separate from safety&soundness of regulated banking).

somewhat related ... GAO has done some studies/reports on problems in public traded companies' audit and financial statements and finding increasing number of "restatements" ... recent post with several references
http://www.garlic.com/~lynn/2008f.html#96

in the 90s there were some claims that in a highly regulated and stable business ... there evolves a large number of people who are purely doing things by rote as learned behavior w/o actually needing to understand what it is they are doing. this then puts them extremely at risk to people who have a more fundamental understanding of what is going on and can manipulate the infrastructure ... like what happened with the use of CDOs in the S&L crisis.

in theory, the qualitative section in early Basel II drafts could be interpreted as requiring some minimum understanding ... somewhat analogous to ISO9000.

there were some snide remarks that the emasculation of the qualitative section allowed preserving a general state of ignorance.

roll forward two decades after CDOs were used in the S&L crisis and find that they are being used again in very similar manner.

Who do we have to blame for the mortgage crisis in America?

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 19, 2008
Subject: Who do we have to blame for the mortgage crisis in America?
Blog: Financial Markets
re:
http://www.garlic.com/~lynn/aadsm28.htm#57
http://www.garlic.com/~lynn/aadsm28.htm#58

For the past couple weeks various news articles and business shows have been ridiculing both UBS and citigroup regarding the "write-down" sweepstakes ... noting that UBS was in the lead but citigroup hadn't been fully heard from yet.

recent additional writedowns from citigroup:

Citigroup cuts value of investments by $14B in 1Q
http://biz.yahoo.com/ap/080418/earns_citigroup.html?.v=6

the previous reference regarding long-winded decade-old post
http://www.garlic.com/~lynn/aepay3.htm#riskm

... also mentioned that two decades ago in the S&L crisis, citigroup needed capital infusion to continue operating because of problems with variable rate mortgages (ARMs)

roll forward a decade, there is both repeal of Glass-Steagall (passed in the wake of crash of '29 to keep risky unregulated investment banking separate from safety&soundness of regulated banking) ... and tied to large citigroup merger

recent news articles about comments that the citigroup merger didn't benefit the employees, customers and/or investors:

John Reed, Architect Of Citi Merger, Calls Deal Mistake

http://money.cnn.com/news/newsfeeds/articles/djf500/200804032006DOWJONESDJONLINE001187_FORTUNE5.htm
John Reed on Citigroup: A Decade Long Disaster
http://seekingalpha.com/article/71270-john-reed-on-citigroup-a-decade-long-disaster

other reference
http://www.garlic.com/~lynn/2008g.html#66

and references that in this round that citigroup already received capital infusion from sovereign wealth funds ... but some time ago they mentioned that citigroup look liked it was going to need more, but they weren't going to provide it
http://www.garlic.com/~lynn/2008g.html#13
http://www.garlic.com/~lynn/2008g.html#20

Is Basel 2 out...Basel 3 in?

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 19, 2008
Subject: Is Basel 2 out...Basel 3 in?
Blog: Finance and Accounting
recent (Basel II) article:

How New Global Banking Rules Could Deepen the US Crisis
http://www.businessweek.com/magazine/content/08_17/b4081083014665.htm?chan=globalbiz_europe+index+page_finance%2C+markets+%2Bamp%3B+investing

and a little additional CDO comment
http://www.garlic.com/~lynn/aadsm28.htm#62

Seeking expert on credit card fraud prevention - particularly CNP/online transactions

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 19, 2008
Subject: Seeking expert on credit card fraud prevention - particularly CNP/online transactions
Blog: Information Security
re:
http://www.garlic.com/~lynn/aadsm28.htm#60

some recent PCI refs:

Payment Application Data Security Standard (PA-DSS)
https://www.pcisecuritystandards.org/tech/pa-dss.htm

but also this:

PCI Compliance gets clarified and neutered (further)
http://blogs.zdnet.com/security/?p=1035

from above:
At one point, I thought that PCI certification was a great thing. Now I realize that it's not really about security at all -- it's about money and responsibility and transferring ownership of risk.

... snip ...

but as noted in discussion about kindergarten security 101 ... as long as the subject matter remains so much more valuable to the crooks; the attacker can still afford to outspend the defenders 100-to-1,

one of the things that was part of x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959

was about changing the paradigm and removing any value of the information (to the attackers)

Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 19, 2008
Subject: Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?
Blog: Information Security
there is similar question in "risk management" category

archived version of my answers
http://www.garlic.com/~lynn/aadsm28.htm#61
http://www.garlic.com/~lynn/aadsm28.htm#63

there was also a recent question in "personal finance" category specifically about mortgage mess ... archived version of my answers
http://www.garlic.com/~lynn/aadsm28.htm#57
http://www.garlic.com/~lynn/aadsm28.htm#58
http://www.garlic.com/~lynn/aadsm28.htm#62

Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 20, 2008
Subject: Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?
Blog: Information Security
re:
http://www.garlic.com/~lynn/aadsm28.htm#65 Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?

there are a number of issues It isn't so much that Basel is faulty ... but 1) incomplete, 2) unregulated activity being allowed to contaminate regulated activity, 3) increasing failures in audit process.

for another analogy ... besides the one i've been using about CDOs being used to obfuscate the "observe" in Boyd's OODA-loop ... past post on the subject:
http://www.garlic.com/~lynn/2008g.html#4
for additional drift, various URLs from around the web mentioning Boyd and/or OODA-loop
http://www.garlic.com/~lynn/subboyd.html#boyd2

in any case, draw the analogy between CDOs and cryptographic algorithms. Big part of the design of cryptographic algorithms is to make it extremely computationally difficult to recover the encrypted information. CDOs were used in the S&L crisis to hide the real values. There were discussions during the 90s about how to provide the necessary visibility into underlying value of CDOs. Old long-winded, decade old post touching on this (and other related subjects)
http://www.garlic.com/~lynn/aepay3.htm#riskm

so some of the recent articles have focused on the computational difficulty of determining real value of the things that make up a CDO. Extending the analogy with cryptographic algorithms ... one might write an article about the race between the people designing CDOs to keep the underelying values hidden (analogous to encrypted messages) and those attempting to discover the underlying values

Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 20, 2008
Subject: Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?
Blog: Finance
re:
http://www.garlic.com/~lynn/aadsm28.htm#66

so if you are needing another metaphor/analogy besides

CDOs used to obfuscate the underlying value as means of subverting the "observe" in Boyd's OODA-loop
http://www.garlic.com/~lynn/2008g.html#4

or CDOs as a type of "encryption" hiding the underlying value with a race between making more powerful algorithms and those breaking encryption.
http://www.garlic.com/~lynn/aadsm28.htm#66

another metaphor/analogy is fuzzy values. CDOs are being used for obfuscating underlying values ... so an evaluation may come up with several unknowns. In some cases, it may be possible to assign some probable bounds on the unkown value ... something likely in a range between some lower bound and some upper bound.

There are a number of things that may be considered regarding such "fuzzy" values:

Which is the strongest currency in the world? Now? Projected for the next 3 years?

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 21, 2008
Subject: Which is the strongest currency in the world? Now? Projected for the next 3 years?
Blog: Economics
comptroller general (appointed in late 90s for 15yr term) has been on this for some time:

America's Prophet of Fiscal Doom
http://www.usnews.com/articles/business/economy/2008/04/11/americas-prophet-of-fiscal-doom.html

from above:

Second, in the current subprime situation, there was a lack of adequate transparency as to the magnitude of these transactions and the nature of the risk.... You have the exact same thing with regard to the federal government's off-balance-sheet obligations. The problem is not current deficits and debt levels. The problem is where we're headed in the $44 trillion-plus in unfunded obligations for Social Security and Medicare that's growing $2 trillion plus a year.... Cash is key. We are already negative cash flow for Medicare. We're going to go negative cash flow for Social Security within the next 10 years...though Social Security is not the real problem. It's healthcare that's going to bankrupt the country.

... snip ...

other comments on off-balance-sheet obligations ... long-winded, decade old post
http://www.garlic.com/~lynn/aepay3.htm#riskm

these have been basically "pay-as-you-go" ... retiree benefits being funded by current employees.

Problem is that there is upcoming large increase in retirees with the "baby boomer" bubble retiring ... possibly four-fold increase in the number of retirees.

At the same time:

The Workplace War for Age and Talent
http://www.newswise.com/articles/view/538892

the following generation of workers is only a little over half as large.

That combination wll result in a factor of eight change in the ratio of retirees-to-workers. Some of the projected effects of global competitiveness and the declining skill/educational level of the next generation ... the effective wages of the next generation may be cut in half. That possibly can mean a change so there is only 1/16th the revenue base per retiree (available to fund these programs).

VCs have a self-destruction gene, let's tweak it

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 22, 2008 09:54 AM
Subject: VCs have a self-destruction gene, let's tweak it
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001035.html

during the internet bubble, the VCs weren't interested in owning a company ... they were looking at how fast they could flip their investment via an IPO. It was get a percentage of something really lame-brain, unload it on the public, it goes belly-up ... and then repeat with the next one (since there was still a need for a solution ... jokes in the period about no interest in start-ups that actually showed positive cash flow).

So there is counter argument ... why bother with somebody that actually thinks they have something valuable and successful ... they just want something lame-brain but with enuf of a facade that doesn't go belly-up until after they unload on the public.

As an aside, there are "angel" investors that actually look for several hundred thousand. These tend to be in it for the longer term.

Frequently the 2-10mil were looking for something that they had control and was within 24months of IPO. Once they got the investment/control ... the whole focus was the packaging of the IPO (how fast and how much)

Now for real topic drift. The large corporate CSOs use to come out of gov. service having dealt with physical security issues. Not too long out of school ... I got paired with one such brand new corporate CSO (recently of gov. service) and got to run around talking about electronic/computer related assurance/integrity on and off for several months (i didn't view it particularly security specific ... it just was part of industrial strength, business critical data processing)

10-15yrs later ... when computer security was becoming more fashionable and they needed people to fill newly created "security" positions ... they tended to be the people that weren't needed/wanted for doing anything else.

VCs have a self-destruction gene, let's tweak it

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 22, 2008 09:54 AM
Subject: VCs have a self-destruction gene, let's tweak it
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm28.htm#69 VCs have a self-destruction gene, let's tweak it

there is some temptation to draw comparison between packaging of startups for IPOs during the internet bubble to the packaging of subprime mortgages as CDOs.

I've used the analogy of CDOs as subverting the "observe" in boyd's OODA-loop. past posts mentioning Boyd &/or OODA-loop
http://www.garlic.com/~lynn/subboyd.html#boyd

Milken had used CDOs two decades ago during the S&L crisis to obfuscate the mortgage values. Long winded decade old post mentioning need for greater visibility into underlying value in CDO-like instruments
http://www.garlic.com/~lynn/aepay3.htm#riskm

Mortgage originators used to have some interest in the quality of mortgages ... since their revenue came from mortgage performance. Along came CDOs, and they could unload the mortgages w/o regard to the quality. Their only interest became how fast they could originate mortgages (w/o regard to quality) ... and their revenue purely became how fast they could originate mortgages and unload as CDOs.

a couple recent references:
http://www.garlic.com/~lynn/2008g.html#4 CDOs subverting Boyd's OODA-loop
http://www.garlic.com/~lynn/aadsm28.htm#61 Is Basel 2 out...Basel 3 in?
http://www.garlic.com/~lynn/aadsm28.htm#66 Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?
http://www.garlic.com/~lynn/aadsm28.htm#67 Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?

Paypal -- Practical Approaches to Phishing -- open white paper

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 22, 2008 05:15 PM
Subject: Paypal -- Practical Approaches to Phishing -- open white paper
Blog: Financial Cryptography
re:
http://financialcryptography.com/mt/archives/001037.html

majority of the information involved in the naked transaction metaphor
http://www.garlic.com/~lynn/subintegrity.html#payments

has additional issues. This is the kindergarten security 101 theme related to security proportional to risk.

a couple recent posts
http://www.garlic.com/~lynn/aadsm28.htm#60 Seeking expert on credit card fraud prevention - particularly CNP/online transactions
http://www.garlic.com/~lynn/aadsm28.htm#64 Seeking expert on credit card fraud prevention - particularly CNP/online transactions

a large amount of the information subject to common leakage/breaches (resulting in fraudulent activity) is worth upwards of one hundred times more to the attackers than the typical value to the defenders. the result is that frequently the attackers can afford to spend 100 times more than the defenders can afford to spend. older post discussing the subject
http://www.garlic.com/~lynn/2001h.html#61

the solution to naked transaction metaphor includes changing the paradigm ... both armoring the transaction as well as eliminating the value of the information to the attacker (since in the current paradigm ... the attacker will always have the incentive to significantly outspend the defender).

What are the current INNOVATIVE ICT Security Services, that are in demand or highly marketable at the moment

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 23, 2008
Subject: What are the current INNOVATIVE ICT Security Services, that are in demand or highly marketable at the moment.
Blog: Information Security
One of the issues is something I've referred to as kindergarten security 101 ... one of the most wide spread issues is where there is a massive paradigm problem attempting to prevent information leakage involving information that is worth 100 times more to the attacker than the defender ... and therefor it is practical for the attack to outspend the defender by 100-to-1

archived replies in recent thread
http://www.garlic.com/~lynn/aadsm28.htm#60
http://www.garlic.com/~lynn/aadsm28.htm#64

We had been asked to consult with a small client/server startup that wanted to do payment transactions on their server and had this technology called SSL that they wanted to use. One of the things needed was mapping the technology to business processes ... including having to do some detailed audits of this new operations calling themselves certification authorities. That effort is now frequently referred to as electronic commerce.
http://www.garlic.com/~lynn/subnetwork.html#gateway

We then got asked to work in the X9A10 financial standard working group which had been given the requirement in the mid-90s to preserve the integrity of the financial infrastructure for all retail payments (not just internet, not just point-of-sale, not just credit, ... all, as in ALL). The result was the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959

The prevalent use of SSL in the world is for electronic commerce as part of hiding the account number and transaction details because of the vulnerability that crooks can take the information and use it as a kind of replay attack for fraudulent transactions. One of the things that x9.59 standard did was eliminate that vulnerability ... crooks were no longer able to take account numbers and information from previous (x9.59) transactions and use it to perform fraudulent transactions.

X9.59 didn't address any of the issues related to hiding the information ... it just eliminated the vulnerabilities (fraudulent transactions) related to the leakage of that information.

"Designing and implementing malicious hardware"

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: "Designing and implementing malicious hardware"
Date: Sat, 26 Apr 2008 11:22:06 -0400
To: Leichter, Jerry <leichter_jerrold@xxxxxxxx>
CC: Jacob Appelbaum <jacob@xxxxxxxx>, Cryptography <cryptography@xxxxxxxx>
Leichter, Jerry wrote:
While analysis of the actual silicon will clearly have to be part of any solution, it's going to be much harder than that:

1. Critical circuitry will likely be "tamper-resistant". Tamper-resistance techniques make it hard to see what's there, too. So, paradoxically, the very mechanisms used to protect circuitry against one attack make it more vulnerable to another. What this highlights, perhaps, is the need for "transparent" tamper-resistance techniques, which prevent tampering but don't interfere with inspec- tion.


traditional approach is to make the compromise more expensive that any reasonable expectation of benefit (security proportional to risk).

helping bracket expected fraud ROI is an infrastructure that can (quickly) invalidate (identified) compromised units. there has been some issues with these kinds of infrastructures since they have also been identified with being able to support DRM (& other kinds of anti-piracy) efforts.

disclaimer: we actually have done some number of patents (that are assigned) in this area
http://www.garlic.com/~lynn/aadssummary.htm

Visa and MasterCard mandated PCI compliance as of Jan 1, 2008. I would like to get a feel or opinion on this subject

Refed: **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 26, 2008
Subject: Visa and MasterCard mandated PCI compliance as of Jan 1, 2008. I would like to get a feel or opinion on this subject.
Blog: Accounting
a couple recent references that have appeared in answers to similar question

Payment Application Data Security Standard (PA-DSS)
https://www.pcisecuritystandards.org/tech/pa-dss.htm

PCI Compliance gets clarified and neutered (further)
http://blogs.zdnet.com/security/?p=1035

one of the issues is this old post about security proportional to risk:
http://www.garlic.com/~lynn/2001h.html#61
and kindergarten security 101

basically an issue with crooks attacking merchant systems to harvest previous transaction information is they can potentially outspend the merchants 100-to-1. The value of the information to the merchant is basicly some part of the net profit on each transaction. The value of the information to the attacker is basically the aggregate balance and/or credit limit of each account. These two values can differ by two orders of magnitude (a factor of 100 times). As a result, the crooks attacking the system may be able to outspend the merchant, defending against the attack, by a factor of 100 times.

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 huge disparity in the difference of the value of the information to the attackers and the defenders was one of the considerations that went into the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959

Instead of hiding the information from the attackers, one of the things that x9.59 did was to make the information useless to the attackers. Whether or not the attackers could extract the information from merchant systems was not dealt with in the x9.59 standard. However, x9.59 changed the paradigm so that if crooks did obtain the information, they wouldn't be able to use it for fraudulent transactions.

large number of past posts related to breaches involving financial information
http://www.garlic.com/~lynn/subintegrity.html#fraud

we had been brought in to help word smith the cal. state electronic signature legislation (and later the federal legislation). turns out that other parties involved in the legislation were also involved in various privacy issues. they had done detailed consumer privacy surveys and had come up with the two most important privacy related items for consumers:
  1. identity theft ... mostly subcategory account fraud related to breaches of financial information that subsequently enabled fraudulent transactions
  2. denial of service ... mostly various organizations, institutions, and/or agencies making some determination to the detriment of the individual based on private personal information.
Item #1 was in large part motivation behind various breach legislation, in part because it had been very prevalent but was getting little attention. This was analogous, but different to the efforts for X9.59 ... which instead of establishing standards for protecting the information and/or requiring notification when the information was compromised .... eliminated the associated vulnerabilities and fraud that could happen when there were breaches.

Fun with Data Theft/Breach Numbers

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 29, 2008
Subject: Fun with Data Theft/Breach Numbers
Blog: Information Security
re:
http://www.linkedin.com/answers/technology/information-technology/information-security/TCH_ITS_ISC/220811-11321318

This an answer discussing the early motivation behind the CA databreach legislation ... as well as the major threat/exploit involved with majority of breaches.
http://www.linkedin.com/answers/finance-accounting/accounting/FIN_ACC/217583-723394

it is part of discussion regarding some of the breach countermeasures.

a major class of breach countermeasures is attempting to increase the security to prevent those breaches.

however, we've also periodically pointed out a major paradigm issue that we refer to as security proportional to risk ... and/or kindergarten security 101.

The big threat in most of these breaches involve being able to use the information for fraudulent transactions. A big issue in most of these cases is that the value of the information to the attacker is worth possibly 100 times more than the value to the defender. The value of the information to the merchant is basically some portion of the net profit on each transaction. The value of the information to the criminals is basically the aggregate of the credit limit &/or balance for each account. These two values can differ by two orders of magnitude ... allowing an attacker to outspend the defender by a factor of 100 times ... and still be able to make a profit out of the fraud.

We had been called into consult wiith a small client/server startup that wanted to do payments on their server and had this technology called SSL they wanted to use ... which is now frequently referred to as electronic commerce
http://www.linkedin.com/answers/technology/software-development/TCH_SFT/220603-19547889

about the same time, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... and we got involved. The result was the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959

one of the issues that we looked at was the huge disparity of the value of the information to the merchant compared to the value of the information to the crooks in the current infrastructure. part of the x9.59 standard wasn't to further "hide" the information (as had been done in the electronic commerce work) ... but change the paradigm and eliminate the value of the information to the crooks (aka even if the crooks obtained the information, they wouldn't be able to use it to perform faudulent transactions)

How do you define 'privileged access'?

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 29, 2008
Subject: How do you define 'privileged access'?
Blog: Information Security
re:
http://www.linkedin.com/answers/technology/information-technology/information-security/TCH_ITS_ISC/221154-1718348

roll-based access control was sort of developed to help address this area.

say some organization has large number of fine grain permissions (say access to information) and some number of employees; hypothetically a million permissions and ten thousand employees. worst case is somebody has to iterate thru all million permissions for each employee (say 10**6 times 10*4 problem).

RBAC is to prefigure canned answers about permissions for type of job description ... w/o having to revisit the detail for each employee.

the other issue is that at least in the early 80s, countermeasures for insider compromises was appearing ... which frequently evolved multi-party operations (and permissions were clearly separated to make sure that permissions were partitioned to require multi-party participation). Part of this was "insiders" were responsible for the majority of all compromises. Then the crooks were starting to come up with countermeasures for multi-party operations (i.e. collusion) ... which then required the development of collusion countermeasures. The problem with insiders continue up thru today ... studies showing (that even in the internet era) something like 70 percent of identity theft/fraud involve insiders (even tho there has been a lot of popular security focus on outsider threats and countermeasures).

part of RBAC paradigm then can be leveraged to clearly separate permissions to enforce multi-party operations (as countermeasure to insider threats).

as for simple flavor ... i maintain a number of merged taxonomies and glossaries
http://www.garlic.com/~lynn/index.html#glosnote

including one for Security .... simple overview:

Terms merged from: AFSEC, AJP, CC1, CC2, CC21, CIAO, FCv1, FFIEC, FJC, FTC, GAO reports, GSA, IATF V3, IEEE610, ITSEC, Intel, JTC1/SC27, KeyAll, MSC, NIST 800-30, 800-33, 800-37, 800-53, 800-60, 800-61, 800-63, 800-77, 800-82, 800-83, 800-94, 800-103, 800-115, FIPS140, NIST IR 7298 Glossary (containing terms from the following FIPS documents: 140-2, 181, 185, 188, 191, 196, 197, 198, 200, 201; and the following 800 documents: 12, 15, 16, 18, 19, 21, 24, 26, 27, 28, 30, 32, 33, 34, 35, 36, 37, 38, 40, 41, 44, 46, 47, 48, 49, 50, 53, 55, 56, 57, 58, 59, 61, 64, 65, 66, 67, 72, 79, 83, 88, 90, 94, 103), NASA, NCSC/TG004, NIAP (& CC), NSA Intrusion, CNSSI 4009, online security study, RFC1983, RFC2504, RFC2647, RFC2828, TCSEC, TDI, TNI, vulnerability testing and misc. Updated 20080311 with 800-60, 800-63, 800-82, 800-115
http://www.garlic.com/~lynn/secure.htm

in the above ... only CNSSI has specific definition for "privileged access"; i.e.

privileged access
Explicitly authorized access of a specific user, process, or computer
to a computer resource(s). [CNSSI] (see also authorized, privileged)


How safe do you feel when using a debit or credit card?

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: April 29, 2008
Subject: How safe do you feel when using a debit or credit card?
Blog: Information Security
re:
http://www.linkedin.com/answers/technology/information-technology/information-security/TCH_ITS_ISC/221018-15603749

In general, debit had been considered much more secure than credit since it included two-factor authentication (something you have and something you know).

credit has had a history of all sort of problems being single factor authentication. early on, attackers would just guess valid account numbers. Effectively exp. date has acted as countermeasure to account number guessing. something similar started out with counterfeit magstripes ... and special codes were added to magstripes as countermeasure to account number guessing.

lots of transaction harvesting started showing up ... where the crooks recorded all the information needed for counterfeit/fraudulent transactions. debit was relative immune from this since the PIN was never available. Somewhat as a result ... there has been a lot of increased security processes to protect transaction information harvesting (since it only involved single factor ... didn't have the advantage that debit had with two-factor authentication).

As market moved away from credit and more and more to debit ... "signature debit" was introduced ... i.e. being able to use debit card w/o requiring PIN. Almost overnight this exposed "signature debit" to the history of credit vulnerabilities (account guessing, harvesting, etc).

Stats have been that credit & signature debit (single factor authentication) fraud is 15 times higher than PIN-debit (two factor authentication).

PIN-debit is vulnerable to advancing technologies (by crooks). Assumption that two factor authentication being more secure is based on the different factors having independent vulnerabilities. Newer generation of attacks involving modifying end-point devices to "skim" both the transaction information and the PIN at a single time (invalidating the assumption about two-factor authentication being more secure). PIN-debit is still more secure than signature-debit & credit ... since the major breaches that have been in the news have been about large repositories of transaction information (where the PIN isn't available, security assumption about multi-factor authentication is still valid)

lots of past posts about "harvesting" vulnerability
http://www.garlic.com/~lynn/subintegrity.html#harvest

There is some tension between the merchants and the financial industry. The financial industry interchange-charges to merchants for the "higher fraud" items (credit & signature debit) are significantly higher than for PIN-deibt. For some merchants, the credit/signature-debit interchange fees are their largest expense (larger than labor, etc).

lots of past posts mentioning fraud, threats, vulnerabilities, explosts
http://www.garlic.com/~lynn/subintegrity.html#fraud

(electronic commerce) SSL use

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: (electronic commerce) SSL use
Date: Fri, 02 May 2008 15:34:19 -0400
To: cryptography@xxxxxxxx
I've periodically posted that certain assumptions were made about "safe" SSL deployment for electronic commerce that were almost immediately invalidated.

The original assumptions assumed that the enduser knew the binding between the webserver that they thot they were talking to and the corresponding URL ... which they would then type into the browser.

Then SSL would provide the assurance that the webserver that was actually being talked to, corresponded to the URL. The two pieces together than provided that the webserver, that the enduser thot they were talking to was, in fact, the webserve that they were talking to.

Almost immediately merchants invalidated the assumptions when they found that SSL represeted 4-5 times degradation in webserver thruput ... and dropped back to just using SSL for payment/checkout portion of the electronic commerce. This button clicking operation invalidated the original safety assumptions regarding the use of SSL for electronic commerce (the original contact was not validated and the URL/webserver correspondance checking was for a URL not provided by the user)

Some amount of 3rd party payment processing outsourcing appeared to have taken advantage of this feature (party doing payment processing unrelated to the original webserver). A lot of phishing email also takes advantage of the paradigm.

I was recently invited to register at a website with a non-US country domain. My registration would not even closely work since it appeared to require IE (I was told that it heavily relied on .NET) ... and since I don't have any windows machines ... I also don't have any IE browser. However in the process I thot I would poke around a little.

I prefixed the URL with https (instead of http). This got me a warning that the certificate was not for the indicated domain. When i looked at the certificate, it came from a certification authority that my browser recognized but was for a ".com" domain associated with some NIGERIAN payment processing operation.

I then checked the ip-address of the original (non-US country) domain and found it mapped to some US-based webhosting company. I then checked the ip-address of the NIGERIAN payment processing operation and found it mapped to some other US-based webhosting company.

I can only speculate that the first webhosting operation has some sort of default configuration for electronic commerce ... where SSL gets mapped to payment processing operation of this NIGERIAN payment processing operation.

User interface, security, and "simplicity"

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: User interface, security, and "simplicity"
Date: Sat, 03 May 2008 15:30:25 -0400
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: tls@xxxxxxxx, cryptography@xxxxxxxx
Peter Gutmann wrote:
I am left with the strong suspicion that SSL VPNs are "easier to configure
>and use" because a large percentage of their user population simply is not
>very sensitive to how much security is actually provided.

They're "easier to configure and use" because most users don't want to have to rebuild their entire world around PKI just to set up a tunnel from A to B.


When we got pulled in to consult with small client/server startup about doing payments on their server ... and they had this technology called SSL they wanted to use .... we eventually (also) coined the term certificate manufacturing to differentiate the common deployment ... from the common definition for PKI.

as in recent post,
http://www.garlic.com/~lynn/aadsm28.htm#78 (electronic commerce) SSL use

much of the SSL deployment in the world today ... subverts the original requirements for "safe" SSL.

as we would work through many of the actual business processes and operations ... we almost always came to the conclusion ... that even these purely "manufactured" certificates (differentiating between common SSL deployments and PKI) were redundant and superfluous. Any scenario where the client registers something about the corresponding "server" ... implies that they can also register the server's public key. Any scenario where the server preregisters anything about clients implies that they can also register the client's public key

not crypto, but fraud detection

From: Anne & Lynn Wheeler <lynn@xxxxxx>
Subject: not crypto, but fraud detection
Date: Mon, 26 May 2008 10:20:08 -0400
To: Cryptography <cryptography@xxxxxx>
Irish Bank Debit Card Skimmers Net EURO-1m
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=121179135013743148197&block=

from above:
Most of the withdrawals took place at the end of April and early May 2008. Many of the victims contacted their banks to notify them of the withdrawals, as the banks' fraud detection systems had failed to spot the suspicious activity.

... snip ...

not crypto, but fraud detection

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: not crypto, but fraud detection
Date: Tue, 27 May 2008 10:32:24 -0400
To: Allen <netsecurity@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Allen wrote:
I don't know what the policy is in Ireland, but here in the USA there is no stop loss on debit cards so the banks are not obligated to make good on fraudulent withdrawals. I believe that most have out of fear of bad PR, but you have to fight for it if it is just a few that it happens to. If this happens too much then people might stop using debit cards. I have advised my mother, 87, to not use them as she is getting a little slow on the uptake and might miss something like this if it happened to her.

Now to show how screwy the system is, I was shopping the other day and the power went off in the grocery store I was at. They had backup power so they were able to check out people; however, they couldn't use debit cards, except.... Well, the screwy thing was if you entered the charge at terminal as a credit card, even when it was only a debit card, it would accept it. I checked my bank, and sure enough the charge showed as a POS charge!

I think the logic is a little screwy and might be able to be exploited though I'm not sure how at the moment.


re:
http://www.garlic.com/~lynn/aadsm28.htm#80 not crypto, but fraud detection

in theory "signature" debit (i.e. debit transaction w/o PIN) and credit could both work ... since they both go thru the same way.

pin-debit goes thru in real time and the merchant has assurance that the transaction has been approved (and pin authenticated). as a result, the interchange fee is much lower ... because the related risk/fraud is presumed to be much lower.

signature debit and credit basically go thru the network the very same way. the machine (either the actual POS terminal or a store controller) remembers all the transactions and there is periodic batch "settlement" (end of shift, or end of day). Settled transaction may or may not have a separate, associated "real time authorization" transaction.

The merchant pays extra charge for each "real time authorization" transaction (which tend to be credit card specific regarding whether the account is active and the new transaction is within the card's credit limit or "open to buy").

the associated "interchange fee" is lower on transactions with "real time authorizations" (presumably transactions with "real time authorizations" tend to have lower risk/fraud). However, transactions may also be settled w/o an associated "real time authorization" (which will have a higher interchange fee since there is presumption of higher risk/fraud). there are some old merchant "small fraud" stories ... where the merchant claimed in the settlement transaction to have a separate "real time authorization" ... when there wasn't one (they got both the lower interchange fee w/o actually having to pay for a real-time authorization transaction ... this was before some financial institutions had the ability to reconcile the information).

All have associated risk/fraud ... one of the tricks is for the financial institution to appropriately adjust the interchange fee to cover the financial institutions associated risk.

There has been recent congressional hearings, EU anti-trust actions and merchant complaints that the financial institutions have adjusted the interchange fees way over what is needed to cover the associated risk. There were snide articles that financial institutions are making significant profits off of the risk adjusted interchange fees. 2-3 yrs ago supposedly something like 40percent of US financial institution bottom line was coming from these (risk adjusted) interchange fees ... and for many retailers it represented their single largest expense.

this has been highlighted in the significant expense going into TV spots to promote "signature debit" .... since the "interchange fee" and especially the profit is significantly higher (vis-a-vis pin-debit).

some of this was discussed in the "bank fraud blame game" thread that went on in this mailing list last june, july ... my posts archived here.
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#37 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#41 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#42 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#43 a fraud is a sale, Re: The bank fraud blame game

Can we copy trust?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Can we copy trust?
Date: Mon, 02 Jun 2008 22:29:50 -0400
To: Bill Frantz <frantz@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>, Ed Gerck <edgerck@xxxxxxxx>
Bill Frantz wrote:
really used for strangers. For people we know, recognition and memory are more compelling ways of trusting.

We can use this recognition and memory in the online world as well. SSH automatically recognizes previously used hosts. Programs such as the Pet Names Tool<http://www.waterken.com/user/PetnameTool/> recognize public keys used by web sites, and provide us with a human-recognizable name so we can remember our previous interactions with that web site. Once we can securely recognize a site, we can form our own trust decisions, without the necessity of involving third parties.


that was one of the business case problems early in SSL for electronic commerce ... namely majority of ecommerce was with repeat sites ... while design point of digital certificates is for first time communication between strangers. lots of past posts mentioning early SSL including being "comfort" item (as opposed to trust)
http://www.garlic.com/~lynn/subtopic.html#sslcert

the other factor that bounded what merchants would pay was liability in electronic commerce ... they were already paying significant interchange fees as part of protecting the consumer. certification authorities weren't looking at taking on any of that aspect.

the combination has been pushing digital certificates into the no-value market segment ... which, in turn, further limits what would could be charged for.

AADS Postings and Posting Index, - previous - home