Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
previous
- home
- 2007: year in review
- 2008: The year of hack the vote?
- Death of antivirus software imminent
- Why Security Modelling doesn't work -- the OODA-loop of today's battle
- Death of antivirus software imminent
- Why Security Modelling doesn't work -- the OODA-loop of today's battle
- Death of antivirus software imminent
- Why Security Modelling doesn't work -- the OODA-loop of today's battle
- Death of antivirus software imminent
- Death of antivirus software imminent
- Why Security Modelling doesn't work -- the OODA-loop of today's battle
- Death of antivirus software imminent
- #4.2 Simplicity is Inversely Proportional to the Number of Designers
- Break the rules of governance and lose 4.9 billion
- Break the rules of governance and lose 4.9 billion
- Dutch Transport Card Broken
- Dutch Transport Card Broken
- Lack of fraud reporting paths considered harmful
- Lack of fraud reporting paths considered harmful
- Lack of fraud reporting paths considered harmful
- Fixing SSL (was Re: Dutch Transport Card Broken)
- Dutch Transport Card Broken
- Dutch Transport Card Broken
- Dutch Transport Card Broken
- Fixing SSL (was Re: Dutch Transport Card Broken)
- middle banking in a english muddle
- Fixing SSL (was Re: Dutch Transport Card Broken)
- Break the rules of governance and lose 4.9 billion
- middle banking in a english muddle
- Chip&PIN cards: 1 in 5 cloned?
- Fixing SSL (was Re: Dutch Transport Card Broken)
- Fixing SSL (was Re: Dutch Transport Card Broken)
- How does the smart telco deal with the bounty in its hands?
- on Revocation of Signing Certs and Public Key Signing itself
- on Revocation of Signing Certs and Public Key Signing itself
- H2.1 Protocols Divide Naturally Into Two Parts
- Say it ain't so? MITM protection on SSH shows its paces
- Attack on Brit retail payments -- some takeways
- The Trouble with Threat Modelling
- Format Wars: XML v. JSON
- Attack on Brit retail payments -- some takeways
- Trojan with Everything, To Go!
- Trojan with Everything, To Go!
- Realistic dynamics of contactless
- Realistic dynamics of contactless
- Realistic dynamics of contactless
- The bond that fell to Earth
- delegating SSL certificates
- World's biggest PKI goes open source: DogTag is released
- Price point
- Liability for breaches: do we need new laws?
- Liability for breaches: do we need new laws?
- Pogo reports: big(gest) bank breach was covered up?
- Pogo reports: big(gest) bank breach was covered up?
- Liability for breaches: do we need new laws?
- Signs of Liability: 'Zero Day Threat' blames IT and Security industry
- Signs of Liability: 'Zero Day Threat' blames IT and Security industry
- Who do we have to blame for the mortgage crisis in America?
- Who do we have to blame for the mortgage crisis in America?
- Information Security Vs. Businesss Resilience
- Seeking expert on credit card fraud prevention - particularly CNP/online transactions
- Is Basel 2 out...Basel 3 in?
- Who do we have to blame for the mortgage crisis in America?
- Is Basel 2 out...Basel 3 in?
- Seeking expert on credit card fraud prevention - particularly CNP/online transactions
- Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?
- Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?
- Would the Basel Committee's announced enhancement of Basel II Framework and other steps have prevented the current global financial crisis had they been implemented years ago?
- Which is the strongest currency in the world? Now? Projected for the next 3 years?
- VCs have a self-destruction gene, let's tweak it
- VCs have a self-destruction gene, let's tweak it
- Paypal -- Practical Approaches to Phishing -- open white paper
- What are the current INNOVATIVE ICT Security Services, that are in demand or highly marketable at the moment
- "Designing and implementing malicious hardware"
- Visa and MasterCard mandated PCI compliance as of Jan 1, 2008. I would like to get a feel or opinion on this subject
- Fun with Data Theft/Breach Numbers
- How do you define 'privileged access'?
- How safe do you feel when using a debit or credit card?
- (electronic commerce) SSL use
- User interface, security, and "simplicity"
- not crypto, but fraud detection
- not crypto, but fraud detection
- Can we copy trust?
2007: year in review
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: December 22, 2007 09:57 PM
Subject: 2007: year in review
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm27.htm#66 2007: year in review
some amount of new 40+ yr old technology is about server consolidation
and being green
i.e.
http://www.garlic.com/~lynn/2007s.html#0 Marines look for a few less servers, via virtualization
http://www.garlic.com/~lynn/2007v.html#13 Ageing data centers limiting benefits of new technologies
however other activities involve virtual appliances (what we use to
call service virtual machines) ... which are much simpler and targeted
monitors. they are considered somewhat more secure because they are
less complex and KISS.
http://www.garlic.com/~lynn/2007o.html#3 Hypervisors May Replace Operating Systems As King Of The Data Center
http://www.garlic.com/~lynn/2007s.html#4 Why do we think virtualization is new?
http://www.garlic.com/~lynn/2007u.html#39 New, 40+ yr old, direction in operating systems
the new 40+ yr old technology is also being touted as addressing some
of the existing cyber vulnerabilities. part of (simpler) virtual
machine technologies ... is it can provide very strong partitioning
(approaching "air gapping"). One of the major compromising vectors is
via browser interaction on the internet. One of the internet browsing
scenarios involves creating a brand new targeted browsing environment
for each session ... which goes poof and evaporates (along with any
compromises) when done.
http://www.garlic.com/~lynn/2007q.html#64 Virtual Browsers: Disposable Security
many of these virtualizing techniques date back nearly 40 yrs. some
slight different topic drift (I disclaim knowledge of it at the time):
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm
Now on the other hand ... given control of the machine ... virtual
machine technology can hide in lots of ways that conventional
compromises can't. The referenced malware discussion points out case
where the bad guys are looking to see if they are in such an
environment controlled by the good guys. However, there has also been
discussions about potential for the reverse ... i.e. the bad guys in
control ... for instance in machines located in public environments
(and figure they can evade detection).
and somewhat back to 2007: year in review ... my first post of the
year
http://www.garlic.com/~lynn/2007.html#0 Securing financial transactions a high priority for 2007
referencing article in late 2006 ... and a thread that continued thru
much of 2007, mostly about how it hadn't happened.
2008: The year of hack the vote?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: 2008: The year of hack the vote?
Date: Sat, 29 Dec 2007 15:04:37 -0500
To: cryptography@xxxxxxxx
CC: lloyd@xxxxxxxx
Jack Lloyd wrote:
The only reason this 'must' be true is because an anonymous and secure
payment system is a terror which thankfully our federal governments
and central banks protect us from. While Amazon and others obviously
like being able to build customer profiles of everyone, I don't doubt
that they would be perfectly willing to accept an anonymous payment as
long as the money is good (and, of course, that the transaction costs
are no more than a credit card and/or the order flow is sufficient
that it is worth building support for it).
in the mid-90s, the x9a10 financial standard working group had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments ... which resulted in the x9.59
standard
http://www.garlic.com/~lynn/x959.html#x959
in the same timeframe, the EU (in conjunction with eu-dpd) made
statements that electronic payments at point-of-sale should be as
anonymous as cash.
this was interpreted as meaning that names should be removed from
payment cards (plastic and magstripe). the contention was that
(because of poor authentication) retail outlets could cross-check
names on the cards against some other form of "ID". the implication
that removing names might help promote other integrity measures.
in the x9.59 standard, we claimed that the improved integrity allowed
meeting the EU-DPD objectives. We also claimed that x9.59 was privacy
agnostic i.e. it allowed for privacy. The ALL requirement given to
the x9a10 financial standard working group met internet, face-to-face,
point-of-sale, electronic commerce. It also met debit, credit, ACH, as
well as stored-value cards ... aka the same X9.59 was applicable to
ALL. In the debit/credit scenario some countries have know your
customer mandates associating account numbers with individuals
... which we claimed was outside the x9.59 standard. Supposedly with
appropriate regulated access to information, govs can obtain
information associating account activity with individuals.
However, the very same x9.59 standard also works with
stored-value/gift cards ... which doesn't have similar know your
customer mandates.
http://www.garlic.com/~lynn/subpubkey.html#privacy
And in fact, most stored-value/gift cards share a lot of the same
exact processing with the debit/credit processing ... the addition of
x9.59 could provide for the exact same level of integrity thruout
debit, credit, and stored-value/gift processing.
for other drift, in the mid-90s ... there were some number of other
payment efforts, specifically for the internet, which had so much
payload and processing bloat that it made it impractical past the toy
demo stage
http://www.garlic.com/~lynn/subpubkey.html#bloat
related recent post on infrastructure provisioning and bloat of toy
demos:
http://www.garlic.com/~lynn/2007v.html#64 folklore indeed
about the same time, there were completely different chip card
oriented efforts for point-of-sale. one of the scenarios of some of
the chipcard pilot projects in the late 90s and early part of this
century was that they managed to increase the vulnerabilities
(magstripe vis-a-vis chipcards)
http://www.garlic.com/~lynn/subintegrity.html#yescard
the common excuse from the period, was that chips cost so much that it
wasn't possible to afford integrity that actually improved over
magstripe. The other possible observation was that some of the
chipcard efforts were so chip myopic ... that they couldn't realize
that they were actually making it worse for the overall
infrastructure.
A big issue for merchants isn't anonymous payments ... it is cost of
doing business. This has been in the news quite a bit recently in the
form of interchange fees ... recent posts
http://www.garlic.com/~lynn/2007v.html#62 folklore indeed
the other area is in the liability related to breaches (and/or the
costs of countermeasures to breaches).
i've mentioned before that we had been called in to consult with small
client/server startup that wanted to do payments on their server. They
had this technology they called SSL and it is frequently now referred
to as electronic commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway
and then we got dragged into involvement with the x9a10 financial
standard working group, as part of attempting to meet the requirement
to preserve the integrity of the financial infrastructure for all
retail payments ... we did some detailed threat and vulnerability
analysis. A big item that came out were infrastructure vulnerabilities
... breaches, skimming, harvesting, evesdropping, ... a whole slew of
things.
we identified that much of the vulnerability could be attributed to
the account number and transaction information has diametrically
opposing requirements ... 1) it has to be readily available for large
number of different business processes and 2) since the crooks can use
the same information for various kinds of essentially replay attacks
... the information has to be kept confidential and never divulged.
we've also talked about this as the dual-use nature of the information
... and that even if the planet was buried under miles of (information
hiding) encryption, it still wouldn't be able to prevent information
leakage.
So another part of the x9.59 financial standard was to eliminate the
dual-use nature of the information, making it useless for crooks
... aka x9.59 didn't do anything to prevent information leakage ... it
just eliminated the information leakage as a vulnerability. a related
recent post
http://www.garlic.com/~lynn/2007v.html#74 folklore indeed
from this stand-point ... the x9.59 financial standard addresses both
drastically reducing fraud in the infrastructure as well as
drastically reducing the infrastructure costs for fraud
countermeasures.
Death of antivirus software imminent
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Death of antivirus software imminent
Date: Sat, 29 Dec 2007 18:37:03 -0500
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
CC: ' =JeffH ' <Jeff.Hodges@xxxxxxxx>
re:
Storm, Nugache lead dangerous new botnet barrage
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1286808,00.html
from above:
The creators of these Trojans and bots not only have very strong
software development and testing skills, but also clearly know how
security vendors operate and how to outmaneuver defenses such as
antivirus software, IDS and firewalls, experts say. They know that
they simply need to alter their code and the messages carrying it in
small ways in order to evade signature-based defenses. Dittrich and
other researchers say that when they analyze the code these malware
authors are putting out, what emerges is a picture of a group of
skilled, professional software developers learning from their
mistakes, improving their code on a weekly basis and making a lot of
money in the process.
... snip ...
... and somewhat related
Virtualization still hot, death of antivirus software imminent, VC says
http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html
from above:
Another trend Maeder predicts for 2008 is, at long last, the death of
antivirus software and other security products that allow employees to
install and download any programs they'd like onto their PCs, and then
attempt to weed out the malicious code. Instead, products that protect
endpoints by only allowing IT-approved code to be installed will
become the norm.
... snip ...
and post about dealing with compromised machines
http://www.garlic.com/~lynn/2007u.html#71 folklore indeed
mentioning sophistication in other ways:
Botnet-controlled Trojan robbing online bank customers
http://www.networkworld.com/news/2007/121307-zbot-trojan-robbing-banks.htm
from above:
If the attacker succeeds in getting the Trojan malware onto the
victim's computer, he can piggyback on a session of online banking
without even having to use the victim's name and password. The
infected computer communicates back to the Trojan's
command-and-controller exactly which bank the victim has an account
with. It then automatically feeds code that tells the Trojan how to
mimic actual online transactions with a particular bank to do wire
transfers or bill payments
... snip ...
there have been some number of online banking countermeasures for
specific kinds of system compromises .... like keyloggers ... but they
apparently didn't bother to get promises from the crooks to only limit
the kinds of attacks to those exploits.
some related comments on such compromised machines
http://www.garlic.com/~lynn/aadsm27.htm#66 2007: year in review
http://www.garlic.com/~lynn/aadsm28.htm#0 2007: year in review
Why Security Modelling doesn't work -- the OODA-loop of today's battle
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: December 30, 2007 04:27 PM
Subject: Why Security Modelling doesn't work -- the OODA-loop of today's battle
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000991.html
first, a disclaimer, in the past, I sponsored Boyd for a number of
presentations ... and applying OODA-loops to other kinds of
competitive situations ... some past posts mentioning Boyd and/or
OODA-loops
http://www.garlic.com/~lynn/subboyd.html#boyd
and various Boyd references from around the Web
http://www.garlic.com/~lynn/subboyd.html#boyd2
the other factor ... specifically with respect to payment transaction
paradigm ... is related to old security proportional to risk ... and
part of the justification behind aspects of x9.59 financial standard
protocol
http://www.garlic.com/~lynn/x959.html#x959
aka ... with the current paradigm, attackers can afford to outspend
the defenders by possibly 100:1 ...
http://www.garlic.com/~lynn/2007v.html#86
and
http://www.garlic.com/~lynn/2007v.html#87
and for a slightly different tact ... post on "Death of antivirus
software imminent"
http://www.garlic.com/~lynn/aadsm28.htm#2
Death of antivirus software imminent
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Death of antivirus software imminent
Date: Mon, 31 Dec 2007 09:31:32 -0500
To: Sherri Davidoff <alien@XXXXXXXX>
CC: cryptography@xxxxxxxx, ' =JeffH ' <Jeff.Hodges@xxxxxxxx>
Sherri Davidoff wrote:
Interesting how "virtualization" seems to imply "safe" in the public
mind (and explicitly in that article) right now.... I'm sure with the
increasing use of virtualization, we'll start to see more VMware-aware
malware and virtual machine escapes in the wild. Another example of
putting many, many eggs in the same basket.
Here's a good article about the first public VMware escape, which
Intelguardians demonstrated at SANSFIRE this summer:
(Note: I'm biased, having worked on this project.)
http://www.pauldotcom.com/2007/07/
What boggles my mind is that despite this, the DoD has still decided to
rely on virtualization software to keep classified and unclassified info
on the same physical systems:
http://www.internetnews.com/storage/article.php/3696996
re:
http://www.garlic.com/~lynn/aadsm28.htm#2 Death of antivirus software imminent
i have a different bias ... but then again a lot of it was my code
that i wrote as undergraduate.
three people from the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
had come out and installed virtual machine system at the univ. the
last week of jan68.
i got to rewrite lots of the code as an undergraduate over the next
couple yrs. part of presentation on some of the work made at boston
meeting aug68:
http://www.garlic.com/~lynn/94.html#18
i knew about quite a few of commercial uses ... including timesharing
service bureaus
http://www.garlic.com/~lynn/submain.html#timeshare
but didn't find out about gov. uses until much later, minor reference:
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm
other historical information
http://www.princeton.edu/~melinda/25paper.pdf
Why Security Modelling doesn't work -- the OODA-loop of today's battle
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 2, 2008 11:02 AM
Subject: Why Security Modelling doesn't work -- the OODA-loop of today's battle
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modeling doesn't work -- the OODA-loop of today's battle
I had become acquainted with John Boyd in the early 80s and sponsored
him for a number of corporate conferences. He was retired and giving
talks for just his out-of-pocket expenses.
despite enormous contributions in numerous areas, much of the
establishment preferred to act as if he didn't exist ... possibly
because he had low tolerance for numerous things. He made the F15,
F16, F18 and whole generation of airplane design what they are today
... but the air force almost acts as if he wasn't there. he was
eventually adopted by the marines (adapting aerial dog fights and
OODA-loops to ground warfare).
some recent long-winded posts in financial transaction related
subthread ... that much of the current "risk" isn't because the
information is so easy for the crooks to obtain ... but the
fundamental "risk" is that the crooks can use the obtained information
for fraudulent transactions.
http://www.garlic.com/~lynn/2008.html#4
http://www.garlic.com/~lynn/2008.html#5
http://www.garlic.com/~lynn/2008.html#7
http://www.garlic.com/~lynn/2008.html#8
http://www.garlic.com/~lynn/2008.html#9
this is also the previous comment that the crooks (attacking the
information) can outspend (by possibly 100:1) the merchants
(attempting to prevent information access).
the x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
rather than attempting to prevent all possible access to the
information ... changed the paradigm and made the information useless
to crooks for generating fraudulent transactions (eliminated the
risk). this is somewhat the thread here this summer about the naked
transaction metaphor
http://www.garlic.com/~lynn/subintegrity.html#payments
Death of antivirus software imminent
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 02 Jan 2008 12:09:50 -0500
To: Bill Frantz <frantz@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Subject: Re: Death of antivirus software imminent
Bill Frantz wrote:
My favorite virtual machine use is for the virus to install itself
as a virtual machine, and run the OS in the virtual machine. This
technique should be really good for hiding from virus scanners.
re:
http://www.garlic.com/~lynn/aadsm28.htm#2 Death of antivirus software imminent
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software imminent
i commented on that in reference posts mentioning that there have been
uses of virtual machines to study virus/trojans ... but that some of
the new generation virus/trojans are now looking to see if they are
running in virtual machine (studied?).
some of the current trade-off is whether that virtual machine
technology can be used to partition off basically insecure operations
(which are widely recognized as being easy to compromise) and then
completely discard the environment and rebuild from scratch after
every session (sort of the automated equivalent of having to manually
wipe an infected machine and re-install from scratch).
the counter argument is that crooks can possibly also use similar
technology to hide ... once they have infected the machine. the
current issue is that a lot of the antivirus/scanning techniques are
becoming obsolete w/o the attackers even leveraging virtual machine
technology.
The attackers can leverage the technology in an otherwise poorly
defended machine. Some years ago there was a product claiming that it
could operate even at a public access machine because of their
completeness of their antivirus countermeasures ... even on an
infected machine. I raised the issue that it would be trivial to
defeat all such countermeasures using virtual machine technology.
Somewhat of a skirmish resulted since they had never considered (or
heard of) virtual machine technology ... for all i know there is still
ongoing head-in-the-sand situation.
for little topic drift ... this blog entry:
https://financialcryptography.com/mt/archives/000991.html
and
http://www.garlic.com/~lynn/aadsm28.htm#3
http://www.garlic.com/~lynn/aadsm28.htm#5
there is some assertion that the crooks overwhelming the defenders
countermeasures because they are operating significantly faster and
more efficiently.
however, another interpretation is that the defenders have chosen
extremely poor position to defend ... and are therefor at enormous
disadvantage. it may be necessary to change the paradigm (and/or find
the high ground) in order to successfully defend.
Why Security Modelling doesn't work -- the OODA-loop of today's battle
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 2, 2008 02:26 PM
Subject: Why Security Modelling doesn't work -- the OODA-loop of today's battle
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA-loop of today's battle
http://www.garlic.com/~lynn/aadsm28.htm#5 Why Security Modelling doesn't work -- the OODA-loop of today's battle
taking a slightly different "Boyd" perspective
http://www.garlic.com/~lynn/subboyd.html#boyd
some of the current problems could be attributed to not having a
strong defensive position ... which gives the attackers an enormous
advantage ... referenced in this thread/post
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software imminent
my wife's father graduated from west point (and then got a engineering
graduate degree from berkeley) ... however, one of the things that
typically is taught is how to choose your defensive position. he had
been engineers for patton and frequently was ranking officer into
enemy territory ... and acquired a collection of officer (silver,
gold, platinum) daggers in surrenders. he also was involved in
liberating some number of camps.
Death of antivirus software imminent
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Death of antivirus software imminent
Date: Wed, 02 Jan 2008 17:18:21 -0500
To: Leichter, Jerry <leichter_jerrold@xxxxxxxx>
CC: Bill Frantz <frantz@xxxxxxxx>,
Cryptography <cryptography@xxxxxxxx>
Leichter, Jerry wrote:
When IBM originally developed VMM technology, security was not a primary
goal. People expected the OS to provide security, and at the time it
was believed that OS's would be able to solve the security problems.
As far as I know, the first real tie of VMM's to security was in a DEC
project to build a VMM for the VAX that would be secure at the Orange
Book A2 level. The primary argument for this was: Existing OS's are
way too complex to verify (and in any case A2 required verified design,
which is impossible to apply to an already-existing design). A VMM can
be small and simple enough to have a verified design, and because it
runs "under" the OS and can mediate all access to the hardware, it can
serve as a Reference Monitor. The thing was actually built and met its
requirements (actually, it far exceeded some, especially on the
performance end), but died when DEC killed the VAX in favor of the
Alpha.
i always thot that i built systems that had prime objective of having
high integrity and not being compromised.
as referenced in this previous post
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software imminent
this use predated
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm
vax/vms by quite a bit. it also predated rainbow books. a lot of the
stuff I did in the 60s as an undergraduate ... and I didn't find out
about some uses until much later. When i was an undergraduate, I
remember IBM asking if I could implement various features ... and some
number of years later conjectured that possibly the requests actually
originated from various gov. organizations.
as previously noted, it was used extensively in both gov. and
commercial environments requiring security and integrity.
for other archeological drift ... vms inherited some number of people
from the burlington mall development group
http://www.garlic.com/~lynn/2007v.html#96 source for VAX programmers
http://www.garlic.com/~lynn/2007v.html#100 source for VAX programmers
Death of antivirus software imminent
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Death of antivirus software imminent
Date: Thu, 03 Jan 2008 11:05:59 -0500
To: Leichter, Jerry <leichter_jerrold@xxxxxxxx>
CC: Bill Frantz <frantz@xxxxxxxx>, Cryptography <cryptography@xxxxxxxx>
Leichter, Jerry wrote:
Virtualization has become the magic pixie dust of the decade.
When IBM originally developed VMM technology, security was not a primary
goal. People expected the OS to provide security, and at the time it
was believed that OS's would be able to solve the security problems.
re:
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software iminent
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software iminent
http://www.garlic.com/~lynn/aadsm28.htm#8 Death of antivirus software iminent
the other claim was that it was assumed that basic systems were built
to be secure, so it would have been quite foreign idea it would be
necessary to build a secure specific system.
besides the referenced fairly wide use of gov and commercial
institutions requiring high integrity systems ... the early virtual
machine systems (cp67 and vm370) were also used by commercial
time-sharing service bureaus. most of these created cms "padded cell"
modifications, a lot of it was to prevent users from damaging
themselves (as opposed to the underlying security that prevented uses
from damaging the system and/or each other).
at least some of these services provided online, concurrent services
to (competitive) wall street firms ... who would be using the online
services for highly sensitive financial activities (as example of
integrity requirements).
a little related x-over from posting in this thread
http://www.garlic.com/~lynn/2008.html#14 hacked TOPS-10 monitors
Why Security Modelling doesn't work -- the OODA-loop of today's battle
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 3, 2008 12:12 PM
Subject: Why Security Modelling doesn't work -- the OODA-loop of today's battle
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000991.html
previous posts:
http://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA-loop of today's battle
http://www.garlic.com/~lynn/aadsm28.htm#5 Why Security Modelling doesn't work -- the OODA-loop of today's battle
http://www.garlic.com/~lynn/aadsm28.htm#7 Why Security Modelling doesn't work -- the OODA-loop of today's battle
Boyd characterized US WW2 strategy as massive logistics (overwhelming
enemy by 10:1 resources) and extremely rigid command and control. Part
of this was claim that US entered the conflict with very few
professional soldiers and quickly fielded a large number of rapidly
mobilized citizens. Part of the extremely rigid command and control
was to leverage the experience of the few professional soldiers and
part of it was to manage the enormous logistics operation.
As a contrast, he would quote Guderian, on the eve of the blitzkrieg
verbal orders only. This is related to the definition of auditors as
the people that go around the battlefield after the war, stabbing the
wounded. The claim was that Guderian wanted the professional "on the
spot" to make decisions and not have to worry about any monday
afternoon quarterbacks.
In the early 80s, Boyd claimed that the rigid command and control
structure with underlying assumption that the majority of people were
unskilled ... were adversely affecting US business, as the young WW2
officers came to major executive positions (and they reflected their
WW2 training).
This theme was also behind his briefing Organic Design For Command
and Control. I have a copy of the original version and some
subsequent copies as it evolved over time.
lots of past Boyd posts
http://www.garlic.com/~lynn/subboyd.html#boyd
and some number of Boyd &/or OODA-loop references from around the web
http://www.garlic.com/~lynn/subboyd.html#boyd2
Death of antivirus software imminent
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Death of antivirus software imminent
Date: Fri, 04 Jan 2008 16:12:13 -0500
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx <cryptography@xxxxxxxx>,
Leichter, Jerry <leichter_jerrold@xxxxxxxx>
Peter Gutmann wrote:
Actually VMMs do provide some security, but not in the way you think. Since
malware researchers typically run malware they're analysing inside a VM, quite
a bit of malware will silently exit (or at least not exercise the "mal" part
of its name) if it detects that it's running inside a VM. So you can
inoculate yourself against at least some malware by running your OS inside a
VM.
re:
http://www.garlic.com/~lynn/aadsm28.htm#2 Death of antivirus software imminent
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software imminent
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software imminent
http://www.garlic.com/~lynn/aadsm28.htm#8 Death of antivirus software imminent
http://www.garlic.com/~lynn/aadsm28.htm#9 Death of antivirus software imminent
when i was working on virtual machines as undergraduate 60s ... they
provided security in the sense of eliminating compromises between
users and the system and between different users. part of this was
that they were something of a microkernel and the APIs were well
defined and KISS and potential for compromises could be fairly easily
understood and dealt with.
there never was much about absolutely prevent awareness of running in
virtual machines ... but there was a lot of effort provided that the
interface provided met the architecture and principles of operation
specification for the machine ... enabling software that expected
machines that met that architecture and principles of operation to
work correctly (some number of features that i added for performance
and/or functional enhancements contributed to being able to determine
that execution wasn't on a real machine .... however, the
implementations had to be done in such a way that they conformed to
the official machine principles of operation specification).
i've mentioned before about getting requests from IBM for changes and
features ... that years later I suspected might have originated from
various gov. agencies. Some of these feature changes could be
interpreted as obfuscating what kinds of activity might be going on in
the rest of the environment ... potentially the result of concurrent
execution by other virtual machines.
as i've mentioned, some of the commercial timesharing service bureaus
using the virtual machine platform ... did make enhancements to the
personal computing environment ... to limit the damage that individual
users could do themselves. however, these weren't necessarily
routinely used as part of standard deployments.
the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
had originated the virtual machine technology ... and also had
originated the technology that was used for the internal network
... which was larger than the arpanet/internet from just about the
beginning until approx. summer of '85
http://www.garlic.com/~lynn/subnetwork.html#internalnet
the same technology was also used for univ. virtual machine based
network in the US (bitnet) and europe (EARN) up until it being
replaced with tcp/ip
http://www.garlic.com/~lynn/subnetwork.html#bitnet
this network had a worm-type event almost exactly a year before the
morris worm ... a recent post with references:
http://www.garlic.com/~lynn/2007u.html#87
#4.2 Simplicity is Inversely Proportional to the Number of Designers
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:
https://financialcryptography.com/mt/archives/000994.html
above entry refers to the previous entry:
What good are standards?
https://financialcryptography.com/mt/archives/000993.html
.... I had given a talk on assurance and the aads chip strawman
http://www.garlic.com/~lynn/x959.html#aads
in trusted computing track at intel developer's forum a few years
ago. during the talk, I happen to quip that it was interesting to note
that over the previous couple years, the TPM design had started to
look more and more like the aads chip strawman. person running the
effort was in the front row and quiped back that I didn't have a
committee of 200 hundred people helping me with the design.
Break the rules of governance and lose 4.9 billion
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 24, 2008 04:30 PM
Subject: Break the rules of governance and lose 4.9 billion...
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000997.html
Last week I had a post that in the early 80s, the state-of-the-art was
starting to handle a lot of insider fraud with things like roles
.... and then there was starting to be problems with collusion
... so there were starting to be some number of collusion
countermeasures.
http://www.garlic.com/~lynn/2008b.html#26
and things are still waiting to get back to the what the
state-of-the-art was working on 25yrs ago.
recent comment on this particular topic
http://www.garlic.com/~lynn/2008b.html#82
Break the rules of governance and lose 4.9 billion
Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: January 25, 2008 05:22 AM
Subject: Break the rules of governance and lose 4.9 billion...
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm28.htm#13
There are all sorts of barriers to introducing new systems
... frequently involving disastrous past attempts. I've pontificated
recently about disastrous, ill-fated attempt to deploy consumer
chipcard operation with personal readers early in the decade and the
chilling aftermath on any further attempts.
A lot of the current "online" transaction infrastructures started out
as purely batch operations. In the 70s&80s, many of these
infrastructures added front-end transaction interfaces ... but still
relied on batch to complete the operations (commonly associated with
"settlement") in what frequently came to be known as overnight batch
windows.
In the 90s, there were billions spent on failed attempts to upgrade
these facilities ... frequently with "object" oriented and
parallelized implementations for something called straight through
processing ... to eliminate the increasing bottleneck of the
overnight batch window (globalization was decreasing the size of the
window and any workload increase was frequently banging up against the
processing limits of the window).
recent references
http://www.garlic.com/~lynn/2008b.html#3 on-demand computing
http://www.garlic.com/~lynn/2008b.html#74 Too much change opens up financial fault lines
Dutch Transport Card Broken
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dutch Transport Card Broken
Date: Fri, 25 Jan 2008 10:28:55 -0500
To: James A. Donald <jamesd@xxxxxxxx>
CC: Perry E. Metzger <perry@xxxxxxxx>, cryptography@xxxxxxxx
my impression has been that with lack of takeup of various kinds of
security solutions that were extensively marketed in the 90s ... that
the current situation has many of those same organizations heavily
involved in behind the scenes lobbying
saw some of that nearly a decade ago when we were brought in to help
wordsmith the cal. state electronic signature legislation which led to
also be brought in on federal electronic signature legislation
... some past posts
http://www.garlic.com/~lynn/subpubkey.html#signature
some other references ...
Hackers break into transport smart card
http://www.dutchnews.nl/news/archives/2008/01/german_hackers_break_transport.php
Transport smart card hacked again (update)
http://www.dutchnews.nl/news/archives/2008/01/transport_smart_card_hacked_ag.php
Dutch Transport Card Broken
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dutch Transport Card Broken
Date: Fri, 25 Jan 2008 10:47:39 -0500
To: Aram Perez <aramperez@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Aram Perez wrote:
Not to defend the designers in any way or fashion, but I'd like to
ask, How much security can you put into a plastic card, the size of a
credit card, that has to perform its function in a secure manner, all
in under 2 seconds (in under 1 second in parts of Asia)? And it has to
do this while receiving its power via the electromagnetic field being
generated by the reader.
we sort of saw that in the mid-90s when we were doing the x9.59
financial standard
http://www.garlic.com/~lynn/x959.html#x959
and getting comments that it wasn't possible to have both low cost and
high security at the same time. we looked at it and made the
semi-facetious statements that we would take a $500 milspec part and
aggresively cost reduce it by 2-3 orders of magnitude while improving
the security. along the way we got tapped by some in the transit
industry to also be able to meet the (then) transit gate requirements
(well under 1 second and do it within iso 14443 power profile).
part of it was having to walk the whole end-to-end process ... all the
way back to chip design and fab manufacturing process ... little drift
about walking fab in a "bunny suit"
http://www.garlic.com/~lynn/2008b.html#13
we effectively did get it on close to the RFID chip (i.e. the one that
they are targeting for UPC) technology curve ... i.e. chip fabrication
cost is roughly constant per wafer ... wafer size and circuit size
have been leading to higher number of chips per wafer (significantly
reducing cost/chip). As circuit size shrank with the corresponding
shrinkage in the size of chips (that didn't have corresponding
increase in number of circuits) there was a "blip" on the cost/chip
curve as the area of the cuts (to separate chips in the wafer)
exceeded the (decreasing) chip size. Earlier this decade there was a
new cutting process that significantly reduced the "cut" area
... allowing yield of (small) chips per wafer to continue to
significantly increase (allowing pushing close to four orders of
magnitude reduction ... rather than 3-4 orders of magnitude
reduction).
aads chip strawman references
http://www.garlic.com/~lynn/x959.html#aads
Lack of fraud reporting paths considered harmful
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Lack of fraud reporting paths considered harmful.
Date: Sat, 26 Jan 2008 23:11:25 -0500
To: Perry E. Metzger <perry@xxxxxxxx>
CC: cryptography@xxxxxxxx
Perry E. Metzger wrote:
This evening, a friend of mine who shall remain nameless who works for
a large company that regularly processes customer credit card payments
informed me of an interesting fact.
His firm routinely discovers attempted credit card fraud. However,
since there is no way for them to report attempted fraud to the credit
card network (the protocol literally does not allow for it), all they
can do is refuse the transaction -- they literally have no mechanism
to let the issuing bank know that the card number was likely stolen.
This seems profoundly bad. I hope that someone on the list has the
right contacts to get the right people to do something about this.
some chance they are doing this to save money on transactions that
aren't likely to be approved ... i.e. rather than be charged for a
transaction that they send thru to the issuer that they are sure to be
rejected ... they reject it upfront.
now the associations have standard procedure to perform "stand-in"
when the network accepts a transaction from an acquirer but isn't able
to forward it to the issuer. stand-in allows the network to decide
whether to approve or reject the transaction using simplified
rules. later, when contact is re-established with the issuer ... the
issuer has to be informed of all the stand-in activity.
a possible simplified mechanism is to be able to generate a simulated
stand-in report of rejected transactions. the issue then in such a
simulated stand-in role ... for all the reasons that they chose to
reject a transaction ... do they map into the standard iso 8583 codes
for reasons that the issuer would reject the transaction.
Lack of fraud reporting paths considered harmful
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Lack of fraud reporting paths considered harmful.
Date: Sun, 27 Jan 2008 13:07:45 -0500
To: Ian G <iang@xxxxxxxx>
CC: John Ioannidis <ji@xxxxxxxx>, cryptography@xxxxxxxx
Ian G wrote:
There is a philosophical problem with suggesting an automated protocol
method for reporting fraud, in that one might be better off ... fixing
the underlying fraud.
re:
http://www.garlic.com/~lynn/aadsm28.htm#17 Lack of fraud reporting paths considered harmful
as an aside ... since the acquiring institution is financially
responsible for the merchant ... they frequently have fraud detection
operations running on incoming transactions ... as do the issuing
institution.
however, if the merchants are prescreening transactions to save on
merchant interchange fees ... then it becomes an economic issue,
including not subsequently incurring costs on transactions that they
had rejected during prescreening. the previous suggestion regarding
simulated "stand-in" reporting would likely have to go thru as batched
"non-mon" transaction (and not be burdened with standard fees).
merchant interchange fees are a continuing, ongoing issue ... for some
market segments, interchange fees are even the largest expense they
have ... also larger than their profit margin. for a large chain with
centralized transaction processing aggregation .... even small
improvements might significantly change their bottom line.
past thread mentioning there is some interaction between the amount of
fraud and the size of interchange fees (i.e. signature debit has been
measured at 15 times pin debit ... and signature debit interchange
fees are correspondingly significantly larger, comparable to credit
fees)
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#37 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#41 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#42 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#43 a fraud is a sale, Re: The bank fraud blame game
misc. other posts mentioning interchange fees:
http://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems
http://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
http://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
http://www.garlic.com/~lynn/aadsm26.htm#34 Failure of PKI in messaging
http://www.garlic.com/~lynn/aadsm27.htm#62 Fingerprint Firefox Plugin?
http://www.garlic.com/~lynn/aadsm28.htm#1 2008: The year of hack the vote?
http://www.garlic.com/~lynn/aadsm7.htm#rhose3 Rubber hose attack
http://www.garlic.com/~lynn/2005u.html#16 AMD to leave x86 behind?
http://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
http://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#72 Free Checking
http://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007n.html#68 Poll: oldest computer thing you still use
http://www.garlic.com/~lynn/2007r.html#31 Is the media letting banks off the hook on payment card security
http://www.garlic.com/~lynn/2007r.html#40 Is the media letting banks off the hook on payment card security
http://www.garlic.com/~lynn/2007s.html#64 Is the media letting banks off the hook on payment card security
http://www.garlic.com/~lynn/2007u.html#0 folklore indeed
http://www.garlic.com/~lynn/2007v.html#62 folklore indeed
http://www.garlic.com/~lynn/2008c.html#7 Toyota Sales for 2007 May Surpass GM
Lack of fraud reporting paths considered harmful
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Lack of fraud reporting paths considered harmful.
Date: Mon, 28 Jan 2008 12:06:04 -0500
To: James A. Donald <jamesd@xxxxxxxx>
CC: Perry E. Metzger <perry@xxxxxxxx>, Ian G <iang@xxxxxxxx>,
cryptography@xxxxxxxx
James A. Donald wrote:
Why is it a mediocre solution?
The credit card number is a widely shared-secret. It
has been known for centuries that widely shared-secrets
have a short life expectancy and should be frequently
re-issued.
The only better solution is unshared-secrets. Is that
what you had in mind? Instead of the customer sharing
his secret with the merchant, and the merchant checking
it with the bank, customer should prove to bank that the
person who knows the secret wishes to pay the merchant
for the identified promise.
re:
http://www.garlic.com/~lynn/aadsm28.htm#17 Lack of fraud reporting paths considered harmful
http://www.garlic.com/~lynn/aadsm28.htm#18 Lack of fraud reporting paths considered harmful
in the mid-90s the x9a10 financial standard working group was given
the requirement to preserve the integrity of the financial
infrastructure for ALL retail payments. The result was the x9.59
financial standard
http://www.garlic.com/~lynn/x959.html#x959
part of the x9.59 financial standard was to eliminate knowledge of the
account number as a vulnerability.
the issue was that there are diametrically opposing requirements being
placed on the account number. on one hand it had to be readily
available in a large number of different places for lots of business
processes. on the other hand it had to be kept confidential and never
divulged to anybody (displayed, exposed, and/or used).
this led to periodic comment that even if the planet was buried under
miles of information hiding encryption ... it still couldn't prevent
account number leakage.
misc. posts mentioning shared-secrets
http://www.garlic.com/~lynn/subintegrity.html#secrets
and account number harvesting
http://www.garlic.com/~lynn/subintegrity.html#harvest
Fixing SSL (was Re: Dutch Transport Card Broken)
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Date: Wed, 30 Jan 2008 12:57:07 -0500
To: Philipp Gühring <pg@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Philipp Guhring wrote:
Yes, sending client certificates in plaintext while claiming that SSL/TLS is
secure doesn´t work in a world of phishing and identity theft anymore.
We have the paradox situation that I have to tell people that they should use
HTTPS with server-certificates and username+password inside the HTTPS
session, because that´s more secure than client certificates ...
Does anyone have an idea how we can fix this flaw within SSL/TLS within a
reasonable timeframe, so that it can be implemented and shipped by the
vendors in this century?
(I don't think that starting from scratch and replacing SSL makes much sense,
since it's just one huge flaw ...)
re:
http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken
aka ... that was part of the relying-party-only certificates from the
mid-90s;
http://www.garlic.com/~lynn/subpubkey.html#rpo
i.e. the x.509 identity digital certificates from the early 90s, were
becoming more and more overloaded with personal information ... and by
the mid-90s, lots of institutions were starting to realize all that
personal information represented significant privacy and liability
issues ... and the RPO digital certificates were born.
However, it was trivial to demonstrate that (for all those business
processes) that the digital certificates were redundant and
superfluous (however, there was some amount of industry brain washing
that digital certificates were mandatory ... especially if digital
signatures was used ... even if they served no useful purpose).
this also showed up in work on pk-init for kerberos supporting digital
signature authentication ... and got into the confused mess with
redundant and superfluous digital certificates
http://www.garlic.com/~lynn/subpubkey.html#kerberos
and similarly digital signatures for radius
http://www.garlic.com/~lynn/subpubkey.html#radius
(between kerberos and radius, they represent possibly the majority of
client authentication in the world today)
part of the confusion regarding the necessity for digital certificates
could be seen in the X9F financial standards work ... the appending of
even a relying-party-only digital certificate (lacking any personal
information) could represent a factor of 100 times payload bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat
for a nominal electronic payment transactions (and also 100 times
processing bloat). as a result, there was some standardization effort
looking at "compressed" (relying-party-only) digital certificates
(even tho they were serving no useful purpose), attempting to get the
payload bloat down to possibly only 5-10 times (instead of 100
times). I took the opportunity to demonstrate that it would be
logically possible to compress such digital certificates to zero bytes
... totally eliminating the payload bloat. then rather than advocating
the elimination of totally useless, redundant and superfluous digital
certificates
http://www.garlic.com/~lynn/subpubkey.html#certless
there could be an infrastructure that mandated zero-byte digital
certificates appended to every transaction.
Dutch Transport Card Broken
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dutch Transport Card Broken
Date: Thu, 31 Jan 2008 14:28:30 -0500
To: 'Cryptography' <cryptography@xxxxxxxx>
Victor Du wrote:
Jumping in late, but the idea that *TCP* (and not TLS protocol design)
adds round-trips to SSL warrants some evidence (it is very temping to
express this skepticism more bluntly).
With unextended SMTP for example, the minimum RTT count is:
0. SYN SYN-ACK
1. ACK 220
2. HELO 250
3. MAIL 250
4. RCPT 250
... n recipients
RCPT 250
4+n DATA 354
5+n ... stream of message content segments<CRLF.CRLF>
250
so it takes at least 6 RTTs to perform a delivery (of a short
single-recipient message), but only 1 of the 6 RTTs is TCP
"overhead". This is improved with PIPELINING:
0. SYN SYN-ACK
1. ACK 220
2. EHLO 250 ... PIPELINING ...
3. MAIL RCPT(n times) DATA 250 250 (n times) 354
4. ... stream of message content segments<CRLF.CRLF>
250
re:
http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch Transport Card Broken)
TCP requires minimum of seven message exchange for reliable transport
.... VMTP (rfc 1045) got that down to minimum of five messages, and
XTP then got it down to three messages minimum for reliable transport
(disclaimer we were on the XTP technical advisory board).
i've frequently pontificated that with reliable registration of public
keys in the dns system and then piggy-backing any registered public
key in standard DNS response .... then it would be possible to encode
a randomly generated secret key (with that public key) and the
encrypted message in the XTP packet for minimum 3 packet exchange.
http://www.garlic.com/~lynn/subpubkey.html#catch22
http already went thru its period of problems of implicit assumptions
with tcp. tcp sessions were assumed to be long lived and session
shutdown was assumed to be relatively infrequently. non-session
activity like http was always assumed to use udp for efficiency. http
ignored all of that and used tcp for non-session activity. as a
result, webserver systems went thru a period where the processors were
spending 95+ percent of processor in the session shutdown
processing. systems then were retrofited with new kind of tcp session
shutdown implementation to handle the misuse by http.
the original ssl deployment was to 1) encrypt data in transit and 2)
authenticate the server. the implicit assumption was that the user
understood the binding between the business and the url. the browser
then provided the second part, verifying the binding between the url
and the server contacted (was the server that the user thot they were
talking to, the server they were actually talking to).
The dependency for valid ssl operation was violated almost immediately
when merchants found that ssl overhead reduced thruput by 5-10
times. the regression was instead of initial contact of the webserver
(presumably url supplied by user) being ssl, ssl was moved to
checkout/pay phase where the user clicked on a button (and url)
provided by the webserver (not a url provided by the user). It was no
longer possible to provide any authentication assurances of the
webserver contacted (ssl purely being reduced to encrypting data in
transmission).
we had been called in to consult with the small client/server company
on using this technology (they created) called SSL for payment
transactions
http://www.garlic.com/~lynn/subnetwork.html#gateway
and had to go thru detailed walk thrus of the technology as it applied
to actual business processes (and the associated implicit
dependencies) ... as well as detailed walk thrus of the new business
operations that were calling themselves certification authorities.
the other issue that we came up for applying this SSL technology, was
communication between webservers and something called the payment
gateway. for this communication we mandated mutual authentication
... this was before mutual authentication had been implemented in
SSL. It turns out that by the time we had it all implemented and
deployed ... it also became very apparent that the things called
digital certificates were redundant and superfluous.
the basic design point for digital certificates is first time
communication between total strangers. the payment gateway business
processes required that all the merchants had to be pre-registered
with the payment gateway and the payment gateway pre-registered with
all the merchants .... violating the basic justification for having
digital certificates.
Dutch Transport Card Broken
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dutch Transport Card Broken
Date: Thu, 31 Jan 2008 17:50:00 -0500
To: 'Cryptography' <cryptography@xxxxxxxx>
Victor Duchovni wrote:
SMTP does not need TCP to provide reliability for the tail of the session,
the application-level "." (end-of-data) and server "250" response complete
a transaction, everything after that is optional, so for example Postfix
will send (when PIPELINING).
DATA<CRLF> 354 Go ahead
Message-Content Lots of acks
.<CRLF>QUIT<CRLF> 250 Ok
and will disconnect after reading the "250 response" without waiting
for the 221 response. The TCP 3-way shutdown (FIN, FIN-ACK, ACK) happens
in the kernel in the background, the SMTP server and client are by that
point handling different connections. So the reliable shutdown latency
is of no consequence for application throughput.
A pipelined SMTP delivery can be completed over TCP in 5 RTTs not 7.
0. SYN SYN-ACK
1. ACK 220
2. EHLO 250
3. MAIL RCPT DATA 250 250 354
4. MSG . QUIT 250 221
5. close socket
TCP is fine, latency is primarily the result of application protocol
details, not TCP overhead. The only TCP overhead above is 1 extra RTT
for the connection setup. Everything else is SMTP not TCP, and running
SMTP over UDP (with ideal conditions and no lost packets, ...) would
save just 1 RTT.
re:
http://www.garlic.com/~lynn/aadsm28.htm#21 Dutch Transport Card Broken
sorry, I didn't say that TCP required seven round-trips for reliable
exchange; the statement was that minimum TCP operation was seven
packet exchange (for reliable operation) .... sort of 3.5
round-trips. That VMTP (rfc 1045) reduced that to minimum of five
packet exchange (sort of 2.5 round-tips) ... and that XTP got it to a
minimum of three packet exchange (sort of 1.5 round-trips) for
reliable operation.
from my RFC index
http://www.garlic.com/~lynn/rfcietff.htm
rfc 1045 summary
http://www.garlic.com/~lynn/rfcidx3.htm#1045
1045 E
VMTP: Versatile Message Transaction Protocol: Protocol specification,
Cheriton D., 1988/02/01 (123pp) (.txt=264928) (Refs 955, 966, 969)
(Ref'ed By 1050, 1072, 1105, 1106, 1190, 1263, 1323, 1453, 1458,
1700, 2018, 2375, 2757) (VMTP)
as always, clicking on the ".txt=nnn" field (in rfc summary) retrieves
the actual RFC.
If there is more than minimum amount of data ... TCP might involve
more than seven packet exchange ... but the minimum packet exchange is
seven packets (not round-trips).
Dutch Transport Card Broken
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Dutch Transport Card Broken
Date: Fri, 01 Feb 2008 09:37:59 -0500
To: Nicolas Williams <Nicolas.Williams@xxxxxxxx>
CC: 'Cryptography' <cryptography@xxxxxxxx>
Nicolas Williams wrote:
I don't have one that exists today and is practical. But we can
certainly imagine possible ways to improve this situation: move parts of
TLS into TCP and/or IPsec. There are proposals that come close enough
to this (see the last IETF SAAG meeting's proceedings, see the IETF BTNS
WG) that it's not too farfetched, but for web stuff I just don't think
they're remotely likely.
my view of ipsec was that it faced a significant barrier to entry
since it required upgrading lots of installed kernels all over the
infrastructure (aka tcp/ip protocol stack have been integrated kernel
implementations)
both SSL and VPN offered implementations that didn't require having to
upgrade existing deployed kernels (something that has gotten somewhat
easier in the last decade plus).
about the same time as SSL, a friend that we had worked on & off with
over a couple decades introduced what was to become called VPN in
gateway committee at fall '94 IETF meeting in san jose.
my view was this resulted in some amount of consternation with the
ipsec forces as well as some of the router vendors. the ipsec forces
were somewhat mollified by being able to refer to vpn as "lightweight"
ipsec (while others then would refer to ipsec as "heavyweight" ipsec).
the initial proposal/implementation involved border routers providing
authentication and (encryption) tunneling through the internet. some
of the router vendors had processors that could handle the encryption
load. however, there was opposition from the router vendors that
didn't have products with processors that could handle the encryption
load (or at least stalling until they had such a product).
in any case, uptake of both SSL and VPN ... was the significantly
easier and less complex deployment ... vis-a-vis ipsec.
Fixing SSL (was Re: Dutch Transport Card Broken)
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Date: Fri, 01 Feb 2008 10:13:32 -0500
To: Ian G <iang@xxxxxxxx>
CC: Eric Rescorla <ekr@xxxxxxxx>, Philipp Gühring <pg@xxxxxxxx>,
Cryptography <cryptography@xxxxxxxx>,
Rasika Dayarathna <dayarathna@xxxxxxxx>
Ian G wrote:
The PII equation is particularly daunting, echoing Lynn's early '90s
experiences. I am told (but haven't really verified) that the
certificate serial number is PII and therefore falls under the full
weight of privacy law & regs ... this may sound ludicrous, but privacy
and security are different fields with different logics. If that is
true, the liability is far too high for something that should be
private, but is already public by dint of its exposure in
certificates. Privacy liabilities are sky-high in some places, and
not only that, they are incalculable, unknowable, and vary with the
person you are talking to.
So a superficial conclusion would be "don't use client certificates
because of the privacy issues" although the issues are somewhat more
complex than "PII revealed in SSL key exchange."
As I say, they'll plug on, as they need to prove that the cert is
worth issuing. It's a data point, no more, and it doesn't exactly
answer your spec above. But I'm having fun observing them trying to
prove that client certs are worth any amount of effort.
the problem that digital certificates were suppose to address was
first time communication between strangers ... the electronic analogy
of the letters of credit/introduction from sailing ship days. this
harks back to the "offline" email days of the early 80s ... dial-up
electronic post-office, exchange email, hangup, and now authenticate
first-time email from total stranger.
the design point assumptions are invalidated if the relying party has
their own repository of information about the party being dealt with
(and therefor can included that party's public key) and/or has online,
timely electronic access to such information.
one of my favorite exchanges from the mid-90s was somebody claiming
that adding digital certificates to the electronic payment transaction
infrastructure would bring it into the modern age. my response was
that it actually would regress the infrastructure at least a couple
decades to the time when online, real-time transactions weren't being
done. The online, real-time transaction provides much higher quality
and useful information than a stale, static digital certificate (with
an offline paradigm from before modern communication). Having an
available repository about the party being dealt with ... including
things like timely, aggregated information (recent transactions) is
significantly mover valuable than the stale, static digital
certificate environment (the only thing that it has going for it, is
it is better than nothing in the oldtime offline environment).
misc. past posts referencing certificate-less public key operation
http://www.garlic.com/~lynn/subpubkey.html#certless
for some real topic drift ... i've mentioned x9.59 financial standard
protocol that can use digital signatures for authentication w/o
requiring digital certificates
http://www.garlic.com/~lynn/x959.html#x959
part of the issue included that digital certificates (even relying-party-only digital certificates) can add a factor of one hundred times
payload bloat to a typical payment transaction
http://www.garlic.com/~lynn/subpubkey.html#bloat
however, we were also got involved in co-authoring the x9.99 privacy
standard ... as part of that we had to look at a number of things,
HIPAA, GLBA ... as well as EU-DPD. as part of that we had also done a
privacy merged taxonomy and glossary ... some notes
http://www.garlic.com/~lynn/index.html#glosnote
EU had also made a statement in the mid-90s that electronic retail
payments should be as anonymous as cash. The dominant use of SSL in
the world today is electronic commerce between a consumer and a
merchant. Passing a client certificate (with PII information) within
an encrypted SSL channel to a merchant ... still exposes the
information to the merchant ... also violating making purchases as
anonymous as cash.
middle banking in a english muddle
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 2, 2008 01:24 PM
Subject: middle banking in a english muddle
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000999.html
for a little more topic drift, this is a reply to a recent post asking
about a UK article where there was fraudulent debit card transactions
on an account ... where the issued debit card had never been used (and
therefor could never have been skimmed)
http://www.garlic.com/~lynn/2008b.html#67
the reply discusses a process gap/crack that appeared in the
transition to (magstripe) signature-debit.
note that there was recent article that debit transactions have
exceeded credit transactions:
Debit Traffic Now Bigger Than Credit Transactions for MasterCard
http://www.digitaltransactions.net/newsstory.cfm?newsid=1662
Fixing SSL (was Re: Dutch Transport Card Broken)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Date: Sun, 03 Feb 2008 20:01:32 -0500
To: StealthMonger <StealthMonger@xxxxxxxx>
CC: cryptography@xxxxxxxx
StealthMonger wrote:
They can't be as "anonymous as cash" if the party being dealt with can
be identified. And the party can be identified if the transaction is
"online, real-time". Even if other clues are erased, there's still
traffic analysis in this case.
What the offline paradigm has going for it is the possibility of true,
untraceable anonymity through the use of anonymizing remailers and
related technologies.
re:
http://www.garlic.com/~lynn/aadsm28.htm#24 Fixing SSL (was Re: Dutch Transport Card Broken)
most people who heard the statement, understood that.
i think that possibly 2nd level detail was that they didn't want PII
easily associated by casual merchant. Initial response was to remove
name from payment cards & magstripes. This also precluded merchants
from requesting other forms of identification to see if the names
matched the name on the payment card. The implication being that the
payment infrastructure would have to come up with other mechanisms to
improve the infrastructure integrity.
The offline payment paradigms ... while touting "true" anonymity were
actually primarily justified based on other factors.
We had been asked to design and cost the dataprocessing supporting US
deployments of some of the "offline" products (that were being used in
Europe). Along the way, we did some business process and revenue
analysis and realized that the primary motivation behind these system
deployments was the float.
About the same time that there was the EU about the privacy of
electronic retail payments ... there was also a statement by the EU
(and some of the country central banks) that the offline products
would be allowed to keep the float for a short grace period .... to
help in the funding of the infrastructure deployment ... but after the
grace period ... the operators would have to start paying interest on
the balance held in the "offline" instruments (eliminating float from
the equation). After that, much of the interest in the offline
deployments drifted away.
In that time frame we had also done design, implementation and
deployment of a payment transaction infrastructure supporting target
marketing ... recent reference
http://www.garlic.com/~lynn/2008c.html#27 Diversity
support was for a small pilot of 60mil accounts and 1.5million
transaction/day ... but capable of scaling up to 20-30 times that
amount. There was significant attention paid to privacy issues and it
was subject to quarterly auditing by some dozen or so privacy
organizations. there had to be a large amount of sensitive treatment
of the information along the lines of what HIPAA specifies for health
information.
aka:
anonymized
Previously identifiable data that have been deidentified and for
which a code or other link no longer exists. An investigator would
not be able to link anonymized information back to a specific
individual. [HIPAA] (see also anonymous, coded, directly
identifiable, indirectly identifiable)
as part of co-authoring x9.99 financial privacy standard, one of the
things we created was a privacy merged glossory and taxonomy
... including GLBA, HIPAA, and EU-DPD references some notes:
http://www.garlic.com/~lynn/index.html#glosnote
in our work on x9.59 financial transaction standard
http://www.garlic.com/~lynn/x959.html#x959
we made the statement that it was privacy agnostic ... since the
transactions were tied to accounts ... but then whether or not the
accounts were tied to individuals was outside the x9.59 standard
http://www.garlic.com/~lynn/subpubkey.html#x959
As a total aside ... as part of the Digicash liquidation, we were
brought in to evaluate the patent portfolio.
Break the rules of governance and lose 4.9 billion
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 4, 2008 04:05 PM
Subject: Break the rules of governance and lose 4.9 billion...
Blog: Financial Cryptography
Dave Birch wrote:
I'm still puzzled where the system spending has gone though. For the
past ten years, at every financial services event I've been to, bank
guys have been complaining that they have no money for innovative new
systems because all the money is going on compliance. They can't
possibly have wasted all of the money on management consultants: some
small fraction must have eventually gone on some actual
controls. Somewhere in SocGen there must have been a line of code like
"if value-at-risk > banks-total-capitalisation then sound-alarm" or
something.
re:
http://www.garlic.com/~lynn/aadsm28.htm#13 Break the rules of governance and lose 4.9 billion
http://www.garlic.com/~lynn/aadsm28.htm#14 Break the rules of governance and lose 4.9 billion
i was at a financial conference in europe a couple of yrs ago ... one
of the main topics was that sox compliance costs was starting to creep
into european companies (and some companies were starting to move off
american exchanges attempting to avoid sox compliance)
i took the position that much of sox was more of the same kind of
auditing ... and there was a lot of fraud which was getting by the
kind of auditing ... and more of the same kind of auditing wasn't
going to catch it; it was going to require different approaches.
a couple recent articles on the socgen subject:
Government report alleges risk and security failures at SocGen
http://www.finextra.com/fullstory.asp?id=18037
Neglected IT Tasks May Have Led to Bank Meltdown
http://www.pcworld.com/businesscenter/article/142137/neglected_it_tasks_may_have_led_to_bank_meltdown.html
Poor password management may have led to bank meltdown
http://www.infoworld.com/article/08/02/04/Poor-password-management-may-have-led-to-bank-meltdown_1.html
and some related comments
http://www.garlic.com/~lynn/2008c.html#76
misc. past posts mentioning sox:
http://www.garlic.com/~lynn/aadsm19.htm#10 Security as a "Consumer Choice" model or as a sales (SANS) model?
http://www.garlic.com/~lynn/aadsm22.htm#26 FraudWatch - Chip&Pin, a new tenner (USD10)
http://www.garlic.com/~lynn/aadsm23.htm#10 PGP "master keys"
http://www.garlic.com/~lynn/aadsm25.htm#12 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#14 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#15 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#26 Fraudwatch - how much a Brit costs, how to be a 419-er, Sarbanes-Oxley rises as fraud rises, the real Piracy
http://www.garlic.com/~lynn/aadsm25.htm#43 Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
http://www.garlic.com/~lynn/aadsm26.htm#2 Audit Follies - Atlantic differences, branding UnTrust, thunbs on Sarbanes-Oxley, alternates
http://www.garlic.com/~lynn/2006h.html#33 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#58 Sarbanes-Oxley
http://www.garlic.com/~lynn/2006i.html#1 Sarbanes-Oxley
http://www.garlic.com/~lynn/2006j.html#28 Password Complexity
http://www.garlic.com/~lynn/2006o.html#35 the personal data theft pandemic continues
http://www.garlic.com/~lynn/2006u.html#22 AOS: The next big thing in data storage
http://www.garlic.com/~lynn/2007b.html#63 Is Silicon Valley strangeled by SOX?
http://www.garlic.com/~lynn/2007j.html#0 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#74 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#75 IBM Unionization
http://www.garlic.com/~lynn/2007o.html#0 The Unexpected Fact about the First Computer Programmer
http://www.garlic.com/~lynn/2007r.html#61 The new urgency to fix online privacy
http://www.garlic.com/~lynn/2008.html#71 As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.garlic.com/~lynn/2008.html#78 As Expected, Ford Falls From 2nd Place in U.S. Sales
middle banking in a english muddle
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 6, 2008 05:23 PM
Subject: middle banking in a english muddle
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000999.html
http://www.garlic.com/~lynn/aadsm28.htm#25 middle banking in a english muddle
Fraud: 1 in 5 Cards Cloned At ATMs and Chip & Pin
http://www.financedaily.co.uk/showNews.aspx?loadid=00951
from above:
"Card fraud is a serious concern that is still common despite
preventative measures put in place to combat this ,including Chip and
PIN," said Zoe Manton, head of Card Protection at CPP. "Fraud levels
increased by 26% in the first six months of 2007 compared to the same
period in 2006, to reach GBP264m."
... snip ...
Chip&PIN cards: 1 in 5 cloned?
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 9, 2008 09:42 AM
Subject: Chip&PIN cards: 1 in 5 cloned?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/001002.html
http://www.garlic.com/~lynn/aadsm28.htm#28
http://www.garlic.com/~lynn/2008c.html#89
A little of the "consumers favor PINs" article discussed in this
post/thread
http://www.garlic.com/~lynn/2008d.html#3
including discussion of various efforts regarding various alternatives
over nearly two decades
and runs into followup post
http://www.garlic.com/~lynn/2008d.html#8
which wanders into this reference over at digital money; short lead-in
How pathetic is it that when I want to buy something on the Internet
using my bank card I have do mess around typing in endless details,
numbers, codes, passwords and the like. It's all so 1994. In an a
modern economy, that sort of thing is seen as being on a par with
Babylonian clay tablets or filling out paper forms to make a SEPA
Credit Transfer. But in advanced countries, there is another way:
... snip ...
aka, dates back to the payment gateway
http://www.garlic.com/~lynn/subnetwork.html#gateway
done with small client/server startup that had invented this technology SSL
http://www.garlic.com/~lynn/subpubkey.html#sslcert
that they wanted to apply to the business processes ... now frequently
referred to as "electronic commerce".
Fixing SSL (was Re: Dutch Transport Card Broken)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Date: Sat, 09 Feb 2008 21:14:23 -0500
To: David Wagner <daw@xxxxxxxx>
CC: cryptography@xxxxxxxx
David Wagner wrote:
I'd be interested in hearing your take on why SSL client certs aren't
widely adopted. It seems like they could potentially help with the
phishing problem (at least, the problem of theft of web authenticators
-- it obviously won't help with theft of SSNs). If users don't know
the authentication secret, they can't reveal it. The nice thing about
using client certs instead of passwords is that users don't know the
private key -- only the browser knows the secret key.
The standard concerns I've heard are: (a) SSL client supports aren't
supported very well by some browsers; (b) this doesn't handle the
mobility problem, where the user wants to log in from multiple
different browsers. So you'd need a different mechanism for initially
registering the user's browser.
By the way, it seems like one thing that might help with client certs
is if they were treated a bit like cookies. Today, a website can set
a cookie in your browser, and that cookie will be returned every time
you later visit that website. This all happens automatically.
Imagine if a website could instruct your browser to transparently
generate a public/private keypair for use with that website only and
send the public key to that website. Then, any time that the user
returns to that website, the browser would automatically use that
private key to authenticate itself. For instance, boa.com might
instruct my browser to create one private key for use with *.boa.com;
later, citibank.com could instruct my browser to create a private key
for use with *.citibank.com. By associating the private key with a
specific DNS domain (just as cookies are), this means that the privacy
implications of client authentication would be comparable to the
privacy implications of cookies. Also, in this scheme, there wouldn't
be any need to have your public key signed by a CA; the site only
needs to know your public key (e.g., your browser could send
self-signed certs), which eliminates the dependence upon the
third-party CAs. Any thoughts on this?
in AADS
http://www.garlic.com/~lynn/x959.html#aads
and certificate-less public key
http://www.garlic.com/~lynn/subpubkey.html#certless
we referred to the scenario as person-centric ... as a contrast to
institutional-centric oriented implementations.
past posts in this thread:
http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch Transport Card Broken)
http://www.garlic.com/~lynn/aadsm28.htm#24 Fixing SSL (was Re: Dutch Transport Card Broken)
http://www.garlic.com/~lynn/aadsm28.htm#26 Fixing SSL (was Re: Dutch Transport Card Broken)
Fixing SSL (was Re: Dutch Transport Card Broken)
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Date: Sun, 10 Feb 2008 05:41:30 -0500
To: David Wagner <daw@xxxxxxxx>
CC: cryptography@xxxxxxxx
re:
http://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL
so lots of the AADS
http://www.garlic.com/~lynn/x959.html#aads
scenarios are that every place a password might appear, have a public
key instead.
for various of the cookie authentication operations ... also think
kerberos tickets. recent reference
http://www.garlic.com/~lynn/2008c.html#31 Kerberized authorization service
part of the scenario for cookie/ticket encryption ... involving
servers, is brute force attack on the server secret key. the cookie
instead of all encrypted data ... has some sort of client registration
value ... analogous to an account number or userid. the cookie caries
the registration value followed by the server encrypted data. the
encryption part uses a derived key ... formed by combination of the
server's secret key and the client's registration value. these derived
key scenarios are also found in transit system operation (both
magstripe and memory chip) as well as financial transactions.
the issue then is initial registration ... the part where the user
chooses their userid (and/or the client registration value is
otherwise selected) and supplies a password (but in this case a public
key). m'soft and others have been using CAPTCHA to weed-out the
non-humans, but this has come under attack. reference to recent news
items
http://www.garlic.com/~lynn/2008d.html#2 Spammer' bot cracks Microsoft's CAPTCHA
the ticket/cookie carries the clients public key (and whatever other
characteristics) ... which then can be used by the server(s) to
perform dynamic authentication (digital signing of some server
supplied, random data, countermeasure to replay attacks). this is in
lieu of server having to maintain the client account record ... ala a
RADIUS scenario where public key has been registered in lieu of a
password (some sort of online access to RADIUS account
records). various RADIUS public key in lieu of password postings:
http://www.garlic.com/~lynn/subpubkey.html#radius
the ticket/cookie scenario (with derived key encryption) is cross
between dynamic server-side account record data (say RADIUS
repository) and stale, static digital certificate scenario. as in the
transit gate operation, the ticket/cookie could also be retrieved,
decrypted, updated, re-encrypted, and returned as part of the
operation. initial server hand-shakes can include server sending some
random challenge data. The client returns the digital signature and
their previously obtained cookie. in the straight RADIUS public key
handshake scenario, just the digital signature and client
userid/account-number is returned since the rest of the cookie/ticket
equivalent info is online in the RADIUS account repository.
The straight RADIUS scenario would be to combine the server-side
random challenge data and combine it with the client registration
value (account number, userid) and whatever else the client-side
digital signing requires ... and return the userid/account-number any
other data and digital signature (i.e. server-side has to be able to
reconstruct what the client actually digitally signed as part of
verifying the digital signature). In the straight RADIUS scenario, the
public key (and any associated permissions, authorization, etc) is
obtained from the RADIUS repository. In cookie/ticket scenario, it is
obtained from the cookie/ticket appended to the message.
The business process still has the initial registration phase
... where the original cookie is created (or in the RADIUS scenario,
where the userid definitiion is initially created) and the public key
is supplied (in lieu of a password).
This is also effectively the original certificate-less pk-init scenario
for kerberos (aka public key in lieu of password)
http://www.garlic.com/~lynn/subpubkey.html#kerberos
The cookie scenario is standard client/server ... attempting to
eliminate the server having to retain the account record on behalf of
every client (as in either the RADIUS and/or KERBEROS
scenario). Encrypting of the cookie data is standard ... although
transit systems and financial transactions have gone to derived key
for the situation ... as countermeasure to brute force attack on an
infrastructure secret key.
How does the smart telco deal with the bounty in its hands?
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:
https://financialcryptography.com/mt/archives/001003.html
Over a decade ago, there was a lot of hype that telcos would take over
the payment industry ... that their phone call transaction systems
were positioned for handling the scaleup (that would happen with
things like micropayments, cellphones, etc).
A couple yrs later (when it wasn't happening), the excuses were that
the telcos weren't positioned (didn't have enuf infrastructure,
experience, etc) to handle the financial liability (and fraud).
recent post mentioning the scenario
http://www.garlic.com/~lynn/aadsm27.htm#66
in that timeframe there were some number of "in-core" dbms systems
developed; they supported transaction semantics ... but the default
location for records were in memory ... as opposed to the default
record location on disk (and memory used for caching). these products
claimed something like ten times performance improvement vis-a-vis
traditional disk-oriented dbms implementations (using same exact
configuration and real storage size) ... and found lots of uptake
among telco customers. In the past couple yrs, there has been
announcements about some of the payment networks installing these
products (usually associated with comments about supporting scaleup
issues).
some old posts:
http://www.garlic.com/~lynn/2004e.html#25
http://www.garlic.com/~lynn/2007m.html#47
for topic drift ... some comments about early uptake of relational
dbms coming with the increases in system real storage sizes (caching
information used by rdbms to automatically handle stuff that required
manual administration and application programming in earlier dbms
implementations)
http://www.garlic.com/~lynn/2008c.html#78
http://www.garlic.com/~lynn/2008c.html#88
http://www.garlic.com/~lynn/2008d.html#11
on Revocation of Signing Certs and Public Key Signing itself
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 12, 2008 02:25 PM
Subject: on Revocation of Signing Certs and Public Key Signing itself
Blog: Financial Cryptography
the certification authorities have been looking to go up the value
chain for sometime now.
the x.509 identity digital certificates from the early 90s ran into a
number of issues. the paradigm is basically targeted at offline email
authentication that existing in the early 80s (taking a page from the
letters of credit/introduction from sailing ship days).
the paradigm ran into numerous discontinuities by the mid-90s
1) online was becoming ubiquitous so relying parties would have
connectivity to authoritative agency and get timely information as to
the party they were dealing with (as alternative to the stale, static
information in the digital certificates)
2) attempting to increase the value of the certificates, there was
direction of increasingly overload them with personal information.
however, by the mid-90s, is had become apparent to most institutions
that identity certificates, grossly overloaded with personal
information, represented severe liability and privacy problems. the
approach then was to retrench to relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
however, it was trivial to demonstrate that the repositories required
as part of the RPO-paradigm, made any digital certificate redundant
and superfluous
Certification authorities then looked at branching into
1) no-value applications ... possibly internet operations that
couldn't justify the cost of maintaining their own repositories and/or
making online transactions
2) non-repudiation
we had been called in to help word-smith the cal. electronic signature
legislation (and later the federal electronic signature legislation)
... and the lawyers involved laid down the requirements for
equivalence to human signature ... i.e. indication that the human had
read, understood, agrees, approves, and/or authorizes
http://www.garlic.com/~lynn/subpubkey.html#signature
examing x.509 standard digital signature defined processes ... it was
possible to drive large aircraft carriers thru the holes with regard
to non-repudiation.
part of the efforts attempting to address some of the gaps were trusted
time-stamping ... and a decade ago, we actually reviewed some number
of the startups getting into trusted time-stamping.
Other gaps are related to possible "dual-use" vulnerabilities
... i.e. same private key being used for normal authentication
operations as well as non-repudiation operations. In numerous purely
authentication implementations, the human never actually examines the
bits being digitally signed. An attack pattern involves substituting
legal documents for random bits (normally used in authentication
operations). The countermeasure isn't appended a disclosure to every
digital signed message which claims to meet human signature
requirements (since that could also be faked). The actual
countermeasure would either a) never use the same key-pair for both
purposes and/or b) always append a disclosure on every set of bits
that have been digitally signed w/o first having been directly
examined by the human ... explicitly stating that the bits are being
digitally signed w/o having been read (aka every authentication
message will require the disclosure appended to the bits before
signing ... aka included as part of the signed bits).
on Revocation of Signing Certs and Public Key Signing itself
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 13, 2008 09:50 AM
Subject: on Revocation of Signing Certs and Public Key Signing itself
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aadsm28.htm#33 on Revocation of Signing Certs and Public Key Signing itself
the dual-use scenario was just one of the gaps that aircraft carriers
could be driven thru ... and the disclaimer appended to every
non-read, digitally signed, bit-string ... was at "least" required.
as in past posts about electronic signatures
http://www.garlic.com/~lynn/subpubkey.html#signature
there are significant other requirements for indicating that something
has been read, understood, agrees, approves, and/or authorizes
(i.e. the disclaimer on non-read messages are just there to eliminate
attackers spoofing claims that the bit-string had been read).
an example is pin-debit at point of sale ... digital signatures (aka
demonstration of something you have authentication, aka possession
of the respective private key) is analogous to pin entry (something
you know authentication) at the POS terminal.
However, the authentication is totally separate and independent of
demonstration of human having read, understood, agrees, approves,
and/or authorizes. In the POS terminal scenario ... it is the pressing
of the "yes" button in response to question about agreeing to the
transaction. This scenario has authentication and "human signature"
equivalence as totally independent operations.
as in other posts about human signatures and digital signatures
... there apparently is lots of semantic confusion caused by both
terms containing the word "signature".
H2.1 Protocols Divide Naturally Into Two Parts
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 13, 2008 12:36 PM
Subject: H2.1 Protocols Divide Naturally Into Two Parts
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/001004.html
part of the existing POS/ATM/etc environment involves a single
round-trip transaction operation.
some of the internet implementations have ignored atomicity and commit
transaction principles.
i remember sigmod conference circa 1992 in san jose where there was
some discussion of the x.5xx stuff. one of the people present
attempted to explain what was going on as a bunch of networking
engineers attempting to re-invent 1960s database technology.
some of the past ecommerce specifications for the internet involved
large amounts of protocol chatter ... on the internet side ... which
was all then (effectively) thrown away as part of interfacing to
payment gateway to perform the actual transaction. in at least some
cases, this represented a factor of 100 times increase in both payload
and processing bloat ... compared to the actual transaction.
as a result there was enormous complexity and impedance mismatch
between what was being doing on the internet side ... and what
was happening as part of the actual financial transaction.
for some topic drift ... this is recent post referencing working out
details for distributed lock manager for massive parallel database
scaleup
http://www.garlic.com/~lynn/2008c.html#81
to start drifting back to the subject ... this old post regarding
meeting on massive database scaleup
http://www.garlic.com/~lynn/95.html#13
two of the people, mentioned in the above referenced meeting, later show
up in a small client/server startup responsible for something called
the commerce server. we were brought in as consultants because they
wanted to do payment transactions on the server. it turns out that the
small client/server startup had this technology called SSL that they
wanted to use for the process. The resulting effort included something
called a payment gateway
http://www.garlic.com/~lynn/subnetwork.html#gateway
and is now frequently referred to as electronic commerce.
However, these recent posts mentions the enormous inefficiency
associated with layering SSL on top of TCP for transaction operation
http://www.garlic.com/~lynn/aadsm28.htm#11 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#21 Dutch Transport Card Broken
http://www.garlic.com/~lynn/aadsm28.htm#22 Dutch Transport Card Broken
for other topic drift ... this is short thread about whether financial
operations requires five-nines availability
http://www.garlic.com/~lynn/2008d.html#21
http://www.garlic.com/~lynn/2008d.html#30
the issue here is that a lot of payment infrastructure having
authorization occurring as part of real-time transactions ... but
actual settlement occurs later in some sort of batch operation
(frequently in something called the overnight batch window) and
requires reconciliation between the separate authorization and
settlement operations.
one of the emerging issues is that for the past 10-15 yrs or so, there
have been numerous efforts to re-engineer the batch settlement and
combine it with the authorization function, sometimes referred to as
straight-through processing.
Say it ain't so? MITM protection on SSH shows its paces
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: February 17, 2008 05:19 PM
Subject: Say it ain't so? MITM protection on SSH shows its paces...
Blog: Financial Cryptography
re:
https://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
https://financialcryptography.com/mt/archives/001009.html
recent post on this subject with some additional references
http://www.garlic.com/~lynn/2008e.html#34
as i've mentioned before, we were called in to consult with small
client/server startup that wanted to do payment transactions on their
server (also had invented this stuff called SSL)
http://www.garlic.com/~lynn/subnetwork.html#gateway
which is frequently now called electronic commerce.
we then also got involved with the x9a10 financial standards working
group that had been give the requirement to preserve the integrity of
the financial infrastructure for all retail payments. part of this
included doing detailed end-to-end vulnerability and threat analysis.
various vulnerabilities/threats ... some of which were decades old
compromised card acceptor devices (both magstripe and chip)
skimming attacks
evesdropping attacks
security and data breaches
replay attacks because of associated static data paradigm
some of this has been previously discussed in the threads related to
naked transactions ... misc. posts here
http://www.garlic.com/~lynn/subintegrity.html#payments
the x9a10 financial standard working group produced the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
part of the standard was making x9.59 immune from evesdropping,
security & data breaches, various skimming attacks and some of the
card acceptor device compromises. x9.59 didn't do anything to hide
the transaction information ... but it made it useless to the crooks
for purposes of doing fraudulent transactions.
we've claimed that the major use of SSL in the world is its use in
electronic commerce ... which we had previously done ... for hiding
financial transactions. however, x9.59 standard turns out to eliminate
needing SSL to hide electronic transactions as a fraudulent financial
transacton countermeasure.
The remaining cases of compromised card acceptor devices, we had
claimed would require personal transaction devices ... possibly built
off of cellphone or PDA platforms using wireless interfaces (since
x9.59 had already eliminated evesdropping on the internet as a
vulnerability ... it would also eliminate wireless evesdropping
between POS interface and a personal transaction device, as a
vulnerability).
some of this can be seen in discussions involving the EU FINREAD
standard from the 90s. FINREAD would be a personal card acceptor
device that met some integrity evaluation criteria. However, in the
FINREAD standard ... there was no provision to provide assurance (to a
financial institution) that a FINREAD device was actually being used.
http://www.garlic.com/~lynn/subintegrity.html#finread
X9.59 provided provisions for things like dual-signatures ... one to
authenticate the entity generating the transaction and a second to
authenticate the environment integrity where the transaction
originated. This is something we referred to as parameterised risk
management ... being able to provide the approving financial
institution additional assurance about the environment and possibly
location where the transaction was performed.
The Trouble with Threat Modelling
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 10, 2008 06:33 AM
Subject: The Trouble with Threat Modelling
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/001013.html
the non-repudiation schtick we saw in the 90s with payment
transactions ... was that it supposedly would be used to change the
burden of proof in consumer disputes ... which was worth a lot to
merchants/banks (and implied that they would be willing to fork over a
whole lot for digital signature infrastructure).
this is akin to some of the activity currently going on in the UK with
respect to payment transaction disputes.
this was later brought home by lawyers that we dealt with when we were
brought in to help wordsmith the cal. state (and later federal)
electronic signature legislation.
http://www.garlic.com/~lynn/subpubkey.html#signature
where there seemed to be quite a tendency to promote semantic
confusion just because the terms "human signature" and "digital
signature", both contained the word "signature".
Format Wars: XML v. JSON
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 12, 2008 11:17 AM
Subject: Format Wars: XML v. JSON
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/001014.html
thats nothing ... should have seen the format wars during the 90s in
the financial standards bodies with *ML vis-a-vis ASN.1
.... especially the x.509 contingent ... except *MLs were being
treated as the new-comer
disclaimer, *MLs were invented by G, M, & L in 1969 at the science
center
http://www.garlic.com/~lynn/subtopic.html#545tech
... a decade later standardized as SGML
http://www.garlic.com/~lynn/submain.html#sgml
and then begat HTML, XML and a whole slew of other *MLs.
http://infomesh.net/html/history/early
Attack on Brit retail payments -- some takeways
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 12, 2008 04:19 PM
Subject: Attack on Brit retail payments -- some takeways
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/001009.html
originally suppose to go down ... but went up by better than 1/3rd instead:
Card fraud GLB150m worse than expected
http://www.thisismoney.co.uk/news/article.html?in_article_id=431514
also
http://www.garlic.com/~lynn/aadsm28.htm#25
http://www.garlic.com/~lynn/aadsm28.htm#28
http://www.garlic.com/~lynn/2008e.html#69
http://www.garlic.com/~lynn/aadsm28.htm#38
and more recent:
APACS Reports Card Fraud Statistics for 2007
http://www.paymentsnews.com/2008/03/apacs-reports-c.html
Increases in card fraud
http://www.loans4.co.uk/loan_news/news.php?item=281-Increases_in_card_fraud-281
New figures show rise in card fraud
http://www.computeractive.co.uk/computeractive/news/2211865/apacs-figures-show-rise-card
Card fraud abroad up claims APACS
http://www.itpro.co.uk/security/news/177357/card-fraud-abroad-up-claims-apacs.html
Credit card fraud hits record levels
http://financialadvice.co.uk/news/2/creditcards/6464/Credit-card-fraud-hits-record-levels.html
Overseas card fraud rises by 25%
http://www.bankingtimes.co.uk/12032008-overseas-card-fraud-rises-by-25/
Credit card fraud reaches record levels
http://ftadviser.com/FTAdviser/Insurance/News/article/20080312/39fdaf52-f02a-11dc-bfbb-0015171400aa/Credit-card-fraud-reaches-record-levels.jsp
Card fraud soars to record high despite chip and pin
http://news.scotsman.com/uk/Card-fraud-soars-to-record.3868258.jp
Criminal gangs fuel a record 25 per cent rise in card fraud
http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=531068&in_page_id=1770
Credit card fraud soars despite 'chip and pin'
http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2008/03/12/nfraud112.xml
Plastic card fraud goes back up
http://news.bbc.co.uk/1/hi/business/7289856.stm
Trojan with Everything, To Go!
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 13, 2008 10:18 AM
Subject: Trojan with Everything, To Go!
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/001015.html
some of this dates back to EU finread terminal standard in the 90s
... which identified personal computer end-points as particularly
vulnerability ... misc. past posts
http://www.garlic.com/~lynn/subintegrity.html#finread
this was before some disastrous deployment attempts brought personal
computer addons into such disrepute (one of the things that USB was
designed to handle) ... a few old references:
http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#50 If your CSO lacks an MBA, fire one of you
http://www.garlic.com/~lynn/aadsm27.htm#52 more on firing your MBA-less CSO
as implied, the mechanics of how the operations are performed can
contribute significantly to the vulnerabilities ... discussed in the
old "naked transaction" metaphor blog entries, threads, and posts:
http://www.garlic.com/~lynn/subintegrity.html#payments
and for a little more topic drift ... when there are security
solutions that tend to be simple point solutions ... and not provide
end-to-end coverage ... leaves enormous infrastructure vulnerability
leakage:
Data Protection is Impossible
http://www.cioupdate.com/article.php/3733716
one of the x9.59 financial transaction standards characteristics
http://www.garlic.com/~lynn/x959.html
was not to try and eliminate all the places that information could
leak ... but change the paradigm so that such information leakage
didn't represent a threat or vulnerability.
Trojan with Everything, To Go!
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: March 13, 2008 02:08 PM
Subject: Trojan with Everything, To Go!
Blog: Financial Cryptography
re:
http://www.garlic.com/~lynn/aa