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:
https://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.
https://www.garlic.com/~lynn/2007s.html#0 Marines look for a few less servers, via virtualization
https://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.
https://www.garlic.com/~lynn/2007o.html#3 Hypervisors May Replace Operating Systems As King Of The Data Center
https://www.garlic.com/~lynn/2007s.html#4 Why do we think virtualization is new?
https://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.
https://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):
https://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
https://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
https://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.
https://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
https://www.garlic.com/~lynn/subpubkey.html#bloat
related recent post on infrastructure provisioning and bloat of toy
demos:
https://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)
https://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
https://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
https://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
https://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
https://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
https://www.garlic.com/~lynn/aadsm27.htm#66 2007: year in review
https://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
https://www.garlic.com/~lynn/subboyd.html#boyd
and various Boyd references from around the Web
https://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
https://www.garlic.com/~lynn/x959.html#x959
aka ... with the current paradigm, attackers can afford to outspend
the defenders by possibly 100:1 ...
https://www.garlic.com/~lynn/2007v.html#86
and
https://www.garlic.com/~lynn/2007v.html#87
and for a slightly different tact ... post on "Death of antivirus
software imminent"
https://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:
https://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
https://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:
https://www.garlic.com/~lynn/94.html#18
i knew about quite a few of commercial uses ... including timesharing
service bureaus
https://www.garlic.com/~lynn/submain.html#timeshare
but didn't find out about gov. uses until much later, minor reference:
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml
other historical information
https://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:
https://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.
https://www.garlic.com/~lynn/2008.html#4
https://www.garlic.com/~lynn/2008.html#5
https://www.garlic.com/~lynn/2008.html#7
https://www.garlic.com/~lynn/2008.html#8
https://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
https://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
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#2 Death of antivirus software imminent
https://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
https://www.garlic.com/~lynn/aadsm28.htm#3
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA-loop of today's battle
https://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
https://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
https://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
https://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software imminent
this use predated
https://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
https://www.garlic.com/~lynn/2007v.html#96 source for VAX programmers
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software iminent
https://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software iminent
https://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
https://www.garlic.com/~lynn/2008.html#14 hacked TOPS-10 monitors
Why Security Modelling doesn't work -- the OODA-loop of today's battle
Refed: **, - **, - **, - **
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:
https://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA-loop of today's battle
https://www.garlic.com/~lynn/aadsm28.htm#5 Why Security Modelling doesn't work -- the OODA-loop of today's battle
https://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
https://www.garlic.com/~lynn/subboyd.html#boyd
and some number of Boyd &/or OODA-loop references from around the web
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#2 Death of antivirus software imminent
https://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software imminent
https://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software imminent
https://www.garlic.com/~lynn/aadsm28.htm#8 Death of antivirus software imminent
https://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
https://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
https://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
https://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:
https://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
https://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.
https://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
https://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:
https://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
https://www.garlic.com/~lynn/2008b.html#3 on-demand computing
https://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
https://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
https://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"
https://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
https://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:
https://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)
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#37 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#41 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#42 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#43 a fraud is a sale, Re: The bank fraud blame game
misc. other posts mentioning interchange fees:
https://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
https://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
https://www.garlic.com/~lynn/aadsm26.htm#34 Failure of PKI in messaging
https://www.garlic.com/~lynn/aadsm27.htm#62 Fingerprint Firefox Plugin?
https://www.garlic.com/~lynn/aadsm28.htm#1 2008: The year of hack the vote?
https://www.garlic.com/~lynn/aadsm7.htm#rhose3 Rubber hose attack
https://www.garlic.com/~lynn/2005u.html#16 AMD to leave x86 behind?
https://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#72 Free Checking
https://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007n.html#68 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007r.html#31 Is the media letting banks off the hook on payment card security
https://www.garlic.com/~lynn/2007r.html#40 Is the media letting banks off the hook on payment card security
https://www.garlic.com/~lynn/2007s.html#64 Is the media letting banks off the hook on payment card security
https://www.garlic.com/~lynn/2007u.html#0 folklore indeed
https://www.garlic.com/~lynn/2007v.html#62 folklore indeed
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#17 Lack of fraud reporting paths considered harmful
https://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
https://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
https://www.garlic.com/~lynn/subintegrity.html#secrets
and account number harvesting
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
https://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;
https://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
https://www.garlic.com/~lynn/subpubkey.html#kerberos
and similarly digital signatures for radius
https://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
https://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
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
https://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken
https://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.
https://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
https://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:
https://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
https://www.garlic.com/~lynn/rfcietff.htm
rfc 1045 summary
https://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
https://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
https://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
https://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
https://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)
https://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:
https://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
https://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:
https://www.garlic.com/~lynn/index.html#glosnote
in our work on x9.59 financial transaction standard
https://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
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#13 Break the rules of governance and lose 4.9 billion
https://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
https://www.garlic.com/~lynn/2008c.html#76
misc. past posts mentioning sox:
https://www.garlic.com/~lynn/aadsm19.htm#10 Security as a "Consumer Choice" model or as a sales (SANS) model?
https://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/aadsm23.htm#10 PGP "master keys"
https://www.garlic.com/~lynn/aadsm25.htm#12 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#14 Sarbanes-Oxley is what you get when you don't do FC
https://www.garlic.com/~lynn/aadsm25.htm#15 Sarbanes-Oxley is what you get when you don't do FC
https://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
https://www.garlic.com/~lynn/aadsm25.htm#43 Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
https://www.garlic.com/~lynn/aadsm26.htm#2 Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
https://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
https://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
https://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley
https://www.garlic.com/~lynn/2006j.html#28 Password Complexity
https://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006u.html#22 AOS: The next big thing in data storage
https://www.garlic.com/~lynn/2007b.html#63 Is Silicon Valley strangeled by SOX?
https://www.garlic.com/~lynn/2007j.html#0 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#74 IBM Unionization
https://www.garlic.com/~lynn/2007j.html#75 IBM Unionization
https://www.garlic.com/~lynn/2007o.html#0 The Unexpected Fact about the First Computer Programmer
https://www.garlic.com/~lynn/2007r.html#61 The new urgency to fix online privacy
https://www.garlic.com/~lynn/2008.html#71 As Expected, Ford Falls From 2nd Place in U.S. Sales
https://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
https://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
https://www.garlic.com/~lynn/aadsm28.htm#28
https://www.garlic.com/~lynn/2008c.html#89
A little of the "consumers favor PINs" article discussed in this
post/thread
https://www.garlic.com/~lynn/2008d.html#3
including discussion of various efforts regarding various alternatives
over nearly two decades
and runs into followup post
https://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
https://www.garlic.com/~lynn/subnetwork.html#gateway
done with small client/server startup that had invented this technology SSL
https://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
https://www.garlic.com/~lynn/x959.html#aads
and certificate-less public key
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch Transport Card Broken)
https://www.garlic.com/~lynn/aadsm28.htm#24 Fixing SSL (was Re: Dutch Transport Card Broken)
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL
so lots of the AADS
https://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
https://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
https://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:
https://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)
https://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 scale-up (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
https://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 scale-up
issues).
some old posts:
https://www.garlic.com/~lynn/2004e.html#25
https://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)
https://www.garlic.com/~lynn/2008c.html#78
https://www.garlic.com/~lynn/2008c.html#88
https://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
https://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
https://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:
https://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
https://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
Refed: **, - **, - **, - **, - **, - **
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
scale-up
https://www.garlic.com/~lynn/2008c.html#81
to start drifting back to the subject ... this old post regarding
meeting on massive database scale-up
https://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
https://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
https://www.garlic.com/~lynn/aadsm28.htm#11 Dutch Transport Card Broken
https://www.garlic.com/~lynn/aadsm28.htm#21 Dutch Transport Card Broken
https://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
https://www.garlic.com/~lynn/2008d.html#21
https://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
https://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)
https://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
https://www.garlic.com/~lynn/subintegrity.html#payments
the x9a10 financial standard working group produced the x9.59 financial standard
https://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.
https://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.
https://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
https://www.garlic.com/~lynn/subtopic.html#545tech
... a decade later standardized as SGML
https://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
https://www.garlic.com/~lynn/aadsm28.htm#25
https://www.garlic.com/~lynn/aadsm28.htm#28
https://www.garlic.com/~lynn/2008e.html#69
https://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!
Refed: **, - **, - **
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
https://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:
https://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#50 If your CSO lacks an MBA, fire one of you
https://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:
https://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
https://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:
https://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
https://www.garlic.com/~lynn/subtopic.html#hacmp
and cluster scale-up
https://www.garlic.com/~lynn/lhwemail.html#medusa
they had been at a large rdbms vendor ... old meeting
https://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
https://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
https://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)
https://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:
https://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:
https://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
https://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
https://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
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: 16 March 2008 at 09:44 PM
Subject: Realistic dynamics of contactless
Blog: Digital Money
re:
https://www.garlic.com/~lynn/aadsm28.htm#43
https://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
https://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
https://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.
https://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
https://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
https://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
https://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:
https://www.garlic.com/~lynn/2008.html#7 folklore indeed
https://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:
https://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01
https://www.garlic.com/~lynn/aadsm14.htm#47 UK: PKI "not working"
https://www.garlic.com/~lynn/aadsm15.htm#8 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
https://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
https://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
https://www.garlic.com/~lynn/aadsm26.htm#34 Failure of PKI in messaging
https://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
https://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
https://www.garlic.com/~lynn/aadsm28.htm#43 Realistic dynamics of contactless
https://www.garlic.com/~lynn/aadsm28.htm#44 Realistic dynamics of contactless
https://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.
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#47 delegating SSL certificates
https://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 brought in to help word smith the cal. state
electronic signature legislation (and later the federal legislation)
... some past posts
https://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
https://www.garlic.com/~lynn/x959.html#x959
had eliminated breaches as an account fraud threat/vulnerability. somewhat
related post over in digital money blog
https://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
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#50 Liability for breaches: do we need new laws?
a little x-over
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#50 Liability for breaches: do we need new laws?
https://www.garlic.com/~lynn/aadsm28.htm#51 Liability for breaches: do we need new laws?
https://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
https://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
https://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
https://www.garlic.com/~lynn/aadsm28.htm#50 Liability for breaches: do we need new laws?
https://www.garlic.com/~lynn/aadsm28.htm#51 Liability for breaches: do we need new laws?
https://www.garlic.com/~lynn/aadsm28.htm#52 Pogo reports: big(gest) bank breach was covered up?
https://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
https://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:
https://www.garlic.com/~lynn/2008h.html#4 You won't guess who's the bad guy of ID theft
https://www.garlic.com/~lynn/aadsm28.htm#54 Liability for breaches: do we need new laws?
budget transparency:
https://www.garlic.com/~lynn/2008h.html#3 America's Prophet of Fiscal Doom
repeal of Glass-Steagall contributing to current write-downs
https://www.garlic.com/~lynn/2008g.html#66 independent appraisers
https://www.garlic.com/~lynn/2008g.html#67 independent appraisers
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#54 Liability for breaches: do we need new laws?
https://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
https://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.
https://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:
https://www.garlic.com/~lynn/2008g.html#66
https://www.garlic.com/~lynn/2008h.html#0
https://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:
https://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
https://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
https://www.garlic.com/~lynn/subboyd.html#boyd
various URLs from around the web mentioning Boyd
and/or OODA-loop
https://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
https://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
https://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
https://www.garlic.com/~lynn/subnetwork.html#nsfnet
and some old email
https://www.garlic.com/~lynn/lhwemail.html#nsfnet
now two of the people that had been in the meeting mentioned in this post
https://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
https://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)
https://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)
https://www.garlic.com/~lynn/subpubkey.html#bloat
by comparison, x9.59 standard had to be a business solution as opposed
to a technology toy
https://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
https://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
https://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:
- thread between risk management and information security
- security proportional to risk
- fraud return-on-investment (ROI)
long winded decade old post about the thread between risk management
and information security
https://www.garlic.com/~lynn/aepay3.htm#riskm
and then there is post on the topic of security proportional to risk
https://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:
https://www.garlic.com/~lynn/aadsm26.htm#58 Our security sucks. Why can't we change? What's wrong with us?
https://www.garlic.com/~lynn/aadsm27.htm#3 Solution to phishing -- an idea who's time has come?
https://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA-loop of today's battle
https://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)
https://www.garlic.com/~lynn/aepay3.htm#riskm
recent reference relating lack of visibility to subverting the
"observe" in Boyd's OODA-loop
https://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
https://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:
https://www.garlic.com/~lynn/aadsm28.htm#57
https://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
https://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
https://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
https://www.garlic.com/~lynn/2008g.html#13
https://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
https://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:
https://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
https://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
https://www.garlic.com/~lynn/aadsm28.htm#61
https://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
https://www.garlic.com/~lynn/aadsm28.htm#57
https://www.garlic.com/~lynn/aadsm28.htm#58
https://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:
https://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
- Glass-Steagall was passed in the wake of crash of '29 to keep risky
unrequlated investment banking separate from safety&soundness of
regulated banking. a decade ago, Glass-Steagall was repealed, somewhat
in conjunction with large citigroup merger.
- CDOs were used by Milken two decades ago in the S&L crisis to
obfuscate the underlying (junk) value. Long-winded decade old post
mentioning the need for much better visibility into the underlying
value of CDO-like instruments ... especially those involving
variable-rate/adjustable-rate mortgages. Also in the S&L crisis,
citigroup required infusion of private funds to keep operating
(related to adjustable-rate mortgages) ... very similar to its current
situation
- GAO has done a number of reports looking at general failures of
audit process (not just at financial institutions) resulting in
significant increase in "restatements" that have been happening this
century.
- the early Basel II drafts had new qualitative section ... somewhat
demonstrating understanding of the process, a little analogous to
ISO9000. In the wake of S&L crisis there had been observation that in
heavily regulated, stable industry, it is possible for a large
percentage of the people to be doing their jobs purely by rote,
learned behavior ... w/o needing to really understand what was going
on. This puts them at risk to people who do understand the
process. There were snide remarks as the new qualitative section was
gutted that it helps preserve a general state of ignorance in the
industry.
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:
https://www.garlic.com/~lynn/2008g.html#4
for additional drift, various URLs from around the web mentioning Boyd
and/or OODA-loop
https://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)
https://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:
https://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
https://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.
https://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
https://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
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://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 dataprocessing)
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:
https://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
https://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
https://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:
https://www.garlic.com/~lynn/2008g.html#4 CDOs subverting Boyd's OODA-loop
https://www.garlic.com/~lynn/aadsm28.htm#61 Is Basel 2 out...Basel 3 in?
https://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?
https://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
https://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
https://www.garlic.com/~lynn/aadsm28.htm#60 Seeking expert on credit card fraud prevention - particularly CNP/online transactions
https://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
https://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
https://www.garlic.com/~lynn/aadsm28.htm#60
https://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.
https://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
https://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"
Refed: **, - **, - **, - **
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
https://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:
https://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
https://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
https://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:
- identity theft ... mostly subcategory account fraud related to
breaches of financial information that subsequently enabled fraudulent
transactions
- 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
https://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
https://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
https://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
https://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
https://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.
- no longer was the initial URL checked to see if the webserver
contacted was the correct webserver (i.e. SSL as countermeasure
to various ip-address and domain name hijacking)
- when the web "button" was clicked, the (potentially fraudulent)
webserver provided an URL. Now the only thing going on was that SSL
would verify that whatever webserver, the webserver claimed to be, was
the webserver it claimed.
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,
https://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:
https://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.
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#37 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#41 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#42 The bank fraud blame game
https://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)
https://www.garlic.com/~lynn/subpubkey.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