Misc AADS & X9.59 Discussions


AADS Postings and Posting Index,
previous - home


H6.2 Most Standardised Security Protocols are Too Heavy
H6.2 Most Standardised Security Protocols are Too Heavy
Threatwatch: Still searching for the economic MITM
Solution to phishing -- an idea who's time has come?
Public key encrypt-then-sign or sign-then-encrypt?
Leadership, the very definition of fraud, and the court of security ideas
Leadership, the very definition of fraud, and the court of security ideas
Solution to phishing -- an idea who's time has come?
Leadership, the very definition of fraud, and the court of security ideas
Enterprise Right Management vs. Traditional Encryption Tools
K6 again, again and again. Therefore, H6.4 -- Compromise on Security before Delivery
Is this Risk Management's Waterloo?
0wned .gov machines (was Re: Russian cyberwar against Estonia?)
Is this Risk Management's Waterloo?
307 digit number factored
307 digit number factored
dnssec?
dnssec?
PKI moving to adopt the plugin model -- realignment to security based on user-needs?
307 digit number factored
307 digit number factored
307 digit number factored
A crazy thought?
Identity resurges as a debate topic
Why self describing data formats:
Why self describing data formats:
A crazy thought?
A crazy thought?
A crazy thought?
A secure Internet requires a secure network protocol
A secure Internet requires a secure network protocol
The bank fraud blame game
The bank fraud blame game
The bank fraud blame game
The bank fraud blame game
The bank fraud blame game
TPM, part 2
The bank fraud blame game
The bank fraud blame game
a fraud is a sale, Re: The bank fraud blame game
a fraud is a sale, Re: The bank fraud blame game
The bank fraud blame game
The bank fraud blame game
a fraud is a sale, Re: The bank fraud blame game
Threatwatch: how much to MITM, how quickly, how much lost
Threatwatch: how much to MITM, how quickly, how much lost
Threatwatch: how much to MITM, how quickly, how much lost
If your CSO lacks an MBA, fire one of you
If your CSO lacks an MBA, fire one of you
If your CSO lacks an MBA, fire one of you
If your CSO lacks an MBA, fire one of you
Know Your Enemy: Scott McNeally on security theater
more on firing your MBA-less CSO
Doom and Gloom spreads, security revisionism suggests "H6.5: Be an adept!"
Security can only be message-based?
Microsoft asserts itself as an uber-CA
The Uneasy Ride on the Cryptography Bandwaggon
The fundamental _barrier to entry_ in the business of payment systems
On the downside of the MBA-equiped CSO
Threatwatch - more data on cost of your identity
Retailers try to push data responsibilities back to banks
Linus: Security is "people wanking around with their opinions"
Fingerprint Firefox Plugin?
Oddly good news week: Google announces a Caps library for Javascript
How to crack RSA
MITM spotted in Tor
2007: year in review


H6.2 Most Standardised Security Protocols are Too Heavy

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2007 10:14 AM
Subject: H6.2 Most Standardised Security Protocols are Too Heavy
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000912.html

these posts mention being called in to consult with small client/server startup that wanted to do payments on their server ... and they had this technology called SSL.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

some of the work for deployment including doing some of the stuff for taking a technology and turning it into a business process. this is now frequently called electronic commerce and is probably the main use of SSL in the world today.

misc. other posts about the business process related to the digital certificates for the SSL process
https://www.garlic.com/~lynn/subpubkey.html#sslcert

i've mentioned before that we subsequently worked on x9.59 financial transaction protocol
https://www.garlic.com/~lynn/x959.html#x959

which can be considered to obsolete much of the work that we had previously done in conjunction with SSL (for what is commonly now called electronic commerce). recent post here
https://www.garlic.com/~lynn/aadsm26.htm#70 WSJ: Soft evidence on a crypto-related breach

Now this recent post makes some slight reference to issues with using a connection protocol for transaction operation
https://www.garlic.com/~lynn/2007j.html#38 Problem with TCP connection close

... for some minor historical drift ... while tcp/ip is the technology basis for the modern internet, we claim that the operational basis for the modern internet came with the NSFNET backbone. Here is some old collected email working on various aspects of NSFNET backbone ... and then not being allowed to bid (even tho subsequent NSF audit of what we already had running claimed that it was at least five yrs ahead of all NSFNET backbone bids to build something new):
https://www.garlic.com/~lynn/lhwemail.html#nsfnet

we also served on what was the "XTP" technical advisory board ... attempting to do both high-speed protocol as well as support reliable transactions. The above post references that session TCP operation requires a minimum of seven packet exchange ... and that VMTP/RFC1045 required minimum of five packet exchange. XTP only needed a minimum of three packet exchange for reliable transaction operation.

misc. posts mentioning XTP as well as folly of attempting to get an XTP high-speed protocol work item into ISO standards ... where ISO network standards had a requirement that only work on network standards could be done for things that don't violate OSI model (and turns out that both IP, internetworking protocol and LAN/MACs violate OSI).
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

now these series of posts mention that general internet public key distribution could be done as part of DNSSEC that includes registering public keys with DNS as part of domain name registration. The basic objective improves the integrity of DNS ... which the SSL domain name certification authorities rely on when they are attempting to validate SSL digital certificate applications. However, it could also be used to obsolete the need to have SSL digital certificates for public key distribution (doing real-time, online, trusted distribution) ... creating something of a catch-22 for the certification authority industry
https://www.garlic.com/~lynn/subpubkey.html#catch22

If registered public key could be piggy-backed on the standard DNS domain to ip-address response (along with any required crypto preferences) ... then the client would have the server's public key before even contacting the server (w/o any additional protocol chatter). for other topic drift some old crypto related email
https://www.garlic.com/~lynn/lhwemail.html#crypto

including one from may81 about a proposal for online network service for trusted public key distribution
https://www.garlic.com/~lynn/2006w.html#email810515

Coupled with XTP, an extremely simplified, transaction SSL is possible ... a client could generate a random secret key, encrypt transaction message with the secret key, encrypt the secret key with the server's public key ... and send the combination (encrypted transaction message and encrypted secret key) to the server in a single message

This is separate from the x9.59 transaction scenario with regard to whether it is necessary to hide/encrypt the information at all; x9.59 transaction could be sent via XTP to a server w/o requirement for hiding/encryption.

H6.2 Most Standardised Security Protocols are Too Heavy

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2007 11:42 AM
Subject: H6.2 Most Standardised Security Protocols are Too Heavy
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardized Security Protocols are Too Heavy

for a little additional topic drift ....

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 results in x9.59 financial standard protocol
https://www.garlic.com/~lynn/x959.html#x959

there were various other efforts going on in the area of secure payment protocols at the time ... attempting to improve what had already been done for electronic commerce with SSL

typical of the genre from the period ... there were protocols proposed that would increase the payload of typical payment transaction by a factor of 100 times (enormous payload bloat) as well as processing by a factor of 100 times (enormous processing bloat) ... misc. past posts mentioning some of the activity from the period that would result in enormous bloat
https://www.garlic.com/~lynn/subpubkey.html#bloat

Threatwatch: Still searching for the economic MITM

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 8, 2007 03:08 PM
Subject: Threatwatch: Still searching for the economic MITM
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000913.html

one of the issues is that the professional attackers, in it for the money ... don't divulge anything ... or go around advertising ... not like the kids that frequently are after the bragging rights.

a lot of the defenders ... when they do find a serious attack ... seem to be quite motivated not to advertise it also.

this is one of the issues behind the early cal. security breach notification legislation ... that institutions weren't making it public ... even after they found out about it.

when we were called into help word-smith the cal. electronic signature legislation ...
https://www.garlic.com/~lynn/subpubkey.html#signature

we also happen to observe some of the stuff going on around the disclosure legislation. Since then, federal legislation has been see-sawing back and forth between something the equivalent of the cal. state legislation and a federal "pre-emption" bill (nullifying state statutes) more along the lines of some of the "CAN-SPAM" characteristics.

some recent posts mentioning the subject:
https://www.garlic.com/~lynn/2007f.html#72 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#8 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#55 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
https://www.garlic.com/~lynn/2007i.html#40 Best practices for software delivery
https://www.garlic.com/~lynn/2007i.html#58 John W. Backus, 82, Fortran developer, dies

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

many of the public wireless operations ... have bootp/dhcp setup for client configuration (DNS server, ip-gateway, ip-address, etc) for initial contact that directs all the client's traffic to a special server ... which pre-empts everything until some sort of authentication is performed.

After the initial authentication ... then the client will get normal configuration update for standard internet operation, DNS server, ip-gateway, etc.

So are we talking about an attacker being able to force standard internet operation configuration (DNS server, ip-gateway, etc) w/o having to first authenticate handshake with the initial server?

Other attacks can be more serious attempting to harvest information (evesdropping, mitm reroute, etc) that can be used in replay attacks (userid/passwords, account numbers, etc).

minor recent news item

Cyber-thieves 'richer than drug dealers'
http://www.computing.co.uk/vnunet/news/2189322/cyber-thieves-richer-drug
Cyber-thieves 'richer than drug dealers'
http://www.vnunet.com/vnunet/news/2189322/cyber-thieves-richer-drug

which somewhat compliments some past articles about cyber crime now involving more money than drug crime.

Solution to phishing -- an idea who's time has come?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 9, 2007 09:15 AM
Subject: Solution to phishing -- an idea who's time has come?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000914.html

periodic recent comments that (in the current infrastructure/paradigm where replay attacks are so easy) attackers can afford to outspend defenders ... possibly as by as much as 100:1.
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies

and old standby post about security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

the real weakness is in the trivial ease that attacker can use the harvested information for financial gain ... trying to plug the holes in the ability of harvesting the information is like plugging holes in dike made of swiss cheese. what needs to be done is changing the paradigm so the holes are plugged in the ease that attackers are able to use the information for financial gain.

this is related to the frequent past observation that even if the planet was buried under miles of encryption ... it still won't prevent information leakage. misc. refs:
https://www.garlic.com/~lynn/aadsm26.htm#8 What is the point of encrypting information that is publicly visible?
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
https://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007

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

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Public key encrypt-then-sign or sign-then-encrypt?
Date: Wed, 09 May 2007 13:54:16 -0600
To: cryptography@xxxxxxxx
Travis H. wrote:
This reminds me a bit of a suggestion I once heard for protocol designers that the messages of the various steps of the protocol include a step number or something like it to prevent cut-and-paste attacks (presumably each message has some redundancy to protect the integrity/authenticity as well, like a running hash covering all the previous messages (in this direction)).

I wonder if something similar couldn't be done with digital signatures, where the input is padded with data that indicates the semantics of the signature; not unlike the forms which say "by signing here I agree that..."

This also makes it very difficult for the opponent to do any kind of chosen-plaintext trickery since the plaintext will be framed with this data that the opponent does not control, but that is also true with other padding options and such.


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

some aspects of this was discussed in old dual-use attack thread ... it possibly isn't enuf to encapsulate all scenarios where the person intends to use the digital signature in manner analogous to human signature (indicating intent, having read, understood, agrees, approves, and/or authorizes) .... then if there is ever a digital signature applied for pure authentication purposes ... say random data from a server (as countermeasure to replay attacks) ... then all such signed data should always also be bracketed by disclaimer saying that such signatures are in no way met to imply agreeing, approving, and/or authorization any message content.

the problem is that digital signatures are an authentication and integrity mechanism, and except for possible semantic confusion resulting from both "digital signature" and "human signature" containing the same word ("signature") ... there is no relationship. a danger of any mis-use of digital signatures as representing human signatures ... is if they are also used for authentication ... where the human doesn't actually physically examine and understand every bit that a signature might be applied to. if the human doesn't actually physical examine and understand every bit that they might apply a signature too ... then it becomes a requirement that all such (signed and unexamined) bits are wrapped with strong disclaimer about any existence of a digital signature is NOT met to imply read, understood, agrees, approves, and/or authorizes.

... aka any random data not examined, but signed ... could in fact contain padding and comments about aggreement ... to appear as if the signer actually wrapped it (instead of the attacker).

lots of past posts discussing "signatures" ... included having been called in to help word-smith the cal. state electronic signature legislation.
https://www.garlic.com/~lynn/subpubkey.html#signature

related and slightly facetious posting here:
https://www.garlic.com/~lynn/aadsm26.htm#69 survey of RFC S/MIME signature handling
as part of this thread
https://www.garlic.com/~lynn/aadsm26.htm#67 survey of RFC S/MIME signature handling

Leadership, the very definition of fraud, and the court of security ideas

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 10, 2007 11:09 AM
Subject: Leadership, the very definition of fraud, and the court of security ideas
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000915.html

minor topic drift in sci.crypt ng ... the thread was "open source voting" ... but the response was to some comments about financial industry having standards and standards bodies (this is before current state where sci.crypt is being bombed by somebody ... all the posts are really coming from the same id if you look at the hdrs)
https://www.garlic.com/~lynn/2007j.html#67 open source voting

Leadership, the very definition of fraud, and the court of security ideas

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 10, 2007 02:20 PM
Subject: Leadership, the very definition of fraud, and the court of security ideas
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/2007j.html#67 open source voting
https://www.garlic.com/~lynn/aadsm27.htm#5 Leadership, the very definition of fraud, and the court of security ideas

aka the original post appeared to assert that the reason that the financial industry had "open" security standards was because that the standards were "open" to lots of people looking at them ... and potentially with all the examination, would result in identifying deficiencies and result in overall better security.

an alternative possible explanation was that in a dispute or litigation ... showing that there was conformance to (some) accepted standards ... reduced what needed to be established/proven (from scratch) in resolving the dispute ... aka the use of standards is a (at least partial) defense.

better defense (in litigation) and better security are not necessarily identical.

Solution to phishing -- an idea who's time has come?

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 11, 2007 11:39 PM
Subject: Solution to phishing -- an idea who's time has come?
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#3 Solution to phishing -- an idea who's time has come?

a little topic drift ....

EU banks in secret debit card talks: document
http://biz.yahoo.com/rb/070511/banks_payments_eu.html?.v=1
EU banks in secret debit card talks
http://business.scotsman.com/latest.cfm?id=730292007
EU lawmakers back cheaper cross-border payments
http://www.neurope.eu/view_news.php?id=73543
JCC at crossroads to the future
http://www.financialmirror.com/more_news.php?id=6732&type=st&nt=Business
Payment Services Directive pushed through by Parliament
http://www.euractiv.com/en/financial-services/parliament-waives-payment-services-directive/article-163368
European Business Guide: Payment Services Directive: Parliament adopts the proposal
http://www.businessupdated.com/shownews.asp?news_id=2391&cat=Payment+Services+Directive:+Parliament+adopts+the+proposal

and for something a little different:

Hacking Citibank's Virtual Keyboard
http://news.yahoo.com/s/zd/20070511/tc_zd/207329

it does mention that the virtual keyboard is designed as a countermeasure to a hacked machine possibly having a keylogger ... and that this exploit is from 2005 (aka a different kind of keylogger variation) ... although it may actually go back a decade.

aka from

Defeating Citi-Bank Virtual Keyboard Protection
http://www.hackinthebox.org/modules.php?op=modload&name=News&file=article&sid=17684

however, the above URL from 8aug05 doesn't get the original article ... but a current reference.

Leadership, the very definition of fraud, and the court of security ideas

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 12, 2007 11:28 AM
Subject: Leadership, the very definition of fraud, and the court of security ideas
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#5 Leadership, the very definition of fraud, and the court of security ideas
https://www.garlic.com/~lynn/aadsm27.htm#6 Leadership, the very definition of fraud, and the court of security ideas

the other part is that a lot of the industry is point-solution wonderkind patches ... that don't actually correct any problem but create a paradigm of life-long patches.
https://www.garlic.com/~lynn/2007j.html#67 open source voting

this somewhat tempts to stray into the subject nothing succeeds like failure ... referenced here:
https://www.garlic.com/~lynn/aadsm26.htm#59 On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?

and misc. post postings making reference to (problems with) security point-solution (patches)
https://www.garlic.com/~lynn/2005t.html#25 Why does my address appear as part of my name?
https://www.garlic.com/~lynn/2007e.html#12 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007i.html#66 John W. Backus, 82, Fortran developer, dies

Enterprise Right Management vs. Traditional Encryption Tools

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Enterprise Right Management vs. Traditional Encryption Tools
Date: Mon, 14 May 2007 11:46:55 -0600
To: Jason Holt <jason@xxxxxxxx>
CC: Ali, Saqib <docbook.xml@xxxxxxxx>, Jon Callas <jon@xxxxxxxx>,
Cryptography <cryptography@xxxxxxxx>,  FDE@xxxxxxxx
Jason Holt wrote:
ERM/DRM/TPM are such poorly defined and implemented products that people have started referring to a "DRM fairy" who people assume will wave her wand and solve whatever problem is at hand. I used to try to draw out the mentioner's claims into a concrete proposal that everyone could objectively examine, but the conversation rarely progressed that far. So now I think that, as with other crypto proposals, the onus should now be on the proposer to clearly delineate what they're proposing and convince us that it's complete and correct, rather than us nodding our heads or lashing out at what we assume it means.

somewhat aside ... there was an effort in the very early days of the PC to look at (hardware) countermeasures to software (and other) piracy (I don't remember whether i was involved shortly before or after the actual announcement of the PC).

starting with 370, the mainframes had unique processor identifications and licensed software was configured for the specific processor. this may have been relatively easy to defeat ... but the numbers and costs involved somewhat created a barrier. It was sufficient to show that some (illegal) action had to have been taken in order to successfully prosecute.

because the costs and numbers involved with the PC were so significantly different, individual prosecution was harder to justify ... and so the hardware countermeasures needed to be much more robust. a problem with the investigation at the time was that tamper-evident technologies were way too expensive which contributed to the investigation being shelved.

somewhat in the wake of that ... there were various methods like specially encoded floppy disks as countermeasure to piracy (i.e. the floppy disks were not trivially duplicated by normal means).

K6 again, again and again. Therefore, H6.4 -- Compromise on Security before Delivery

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 15, 2007 09:39 AM
Subject: K6 again, again and again. Therefore, H6.4 -- Compromise on Security before Delivery
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000919.html

I was once at a monthly meeting where somebody talked about security evaluations (the old C2, B2, A2, etc type stuff and the newer replacement, common criteria and protection profiles). supposedly a purpose of the security evaluations would be to allow customers to make some comparable security assessment about different security products from different vendors.

One of the comments was that there had been something like 64 common criteria evaluations of particular types of product and of the 64, 62 evaluations had some sort of unpublished deviations and/or exceptions (devaluing the usefulness of security comparisons).

Is this Risk Management's Waterloo?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 18, 2007 11:37 AM
Subject: Is this Risk Management's Waterloo?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000922.html

old, long winded post about the thread between risk management and information security
https://www.garlic.com/~lynn/aepay3.htm#riskm

for little side track ... risk management is more than security issues ... "insurance" traditionally is part of a risk management toolkit and used for things far from traditional security issues. for other issues see BIS and BASEL
http://www.bis.org/publ/bcbsca.htm

in the past, i've hypothesized that there have been instances where a risk adverse organization has avoided addressing a problem (say ISP with regard to incoming/ingress from their customers ... filtering long before it got to the destination end) since they might then be held accountable if the measures weren't perfect (and then got sued). They sidestepped liability by doing nothing (at least until some sort of gov. authority steps in and mandates something)

some of these scenarios is that not doing something might put their customers at risk ... but wouldn't directly affect the institutions. doing something that turned out to be not one hundred percent perfect created more risk and liability to the institution than doing nothing.

this old post is about security (aka countermeasures) proportional to risk
https://www.garlic.com/~lynn/2001h.html#61

where the value to the attacker is several times larger than the value to the defender ... and is somewhat related to the whole "naked transaction" discussion
https://www.garlic.com/~lynn/subintegrity.html#payments

from a slightly different perspective
https://www.garlic.com/~lynn/2007k.html#12
https://www.garlic.com/~lynn/2007k.html#13

i also had these discussions/arguments in the early & mid 90s about ISPs being able to just about eliminate IP-address spoofing and DOS attacks with ingress filtering (this was before botnets and DDOS attacks).

when we were working on the financial industry privacy standard (including some of the disclosure issues), we made the comment that it was going to require some culture change for institutional risk and security professionals. traditionally, institutional risk & security professionals were looking at protection of the institution. various gov. mandates were forcing institutional risk & security professionals to start thinking about protecting the institution's customers (in some of the scenarios even protecting the customers from the institution).

0wned .gov machines (was Re: Russian cyberwar against Estonia?)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: 0wned .gov machines (was Re: Russian cyberwar against Estonia?)
Date: Sun, 20 May 2007 09:03:08 -0600
To: Ivan Krstić <krstic@xxxxxxxx>
CC: Perry E. Metzger <perry@xxxxxxxx>,
    Trei, Peter <ptrei@xxxxxxxx>,  cryptography@xxxxxxxx
Ivan Krstić wrote:
I think it's anything but surprising. There's only so much you can do to significantly improve systems security if you're unwilling to break backwards compatibility -- many of the fundamental premises of desktop security are fatally flawed, chief among them the idea that all programs execute with the full privileges of the executing user.

part of this is that many of the basic platforms providing internet connectivity evolved from disconnected/unconnected desk/table top environment ... with lots of applications assuming that they had full & free access to all resources.

attempting to leverage the same platforms for connectivity to extremely hostility and anarchy of the internet creates diametrically opposing requirements.

one countermeasure from the 60s is to use a dynamically created ("padded cell") virtual machine for internet connectivity ... with limited scope and accesses. then when the session completes ... the environment is collapsed and everything is discarded.

while the "native" system operation may have little or no defenses against the hostile internet ... the "padded cell" virtual machine environment is used to bound the scope of any penetration ... somewhat analogous to "air gapping".

recent post:
https://www.garlic.com/~lynn/2007k.html#48

somewhat older reference:
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

Is this Risk Management's Waterloo?

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 20, 2007 11:27 AM
Subject: Is this Risk Management's Waterloo?
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#11 Is this Risk Management's Waterloo?

i.e. insurance, alarms, bumpers, guard rails, etc are all types of risk management

possibility is that with regard to information systems, very few people have any fundamental understanding of related threats, vulnerabilities, etc. ... i.e. w/o any fundamental understanding how information systems operate ... any treat and vulnerability analysis will miss enormous number of issues.

for slightly related topic drift
https://www.garlic.com/~lynn/aadsm27.htm#12 Owned .gov machines (was Re: Russian cyberwar against Estonia?)

the above is specific with regard to implementations that evolved from a non-hostile and disconnected environment with few or little countermeasures.

now some of the more systems that are considered quite a bit more secure 1) have been implemented in languages other than "C" and are remarkably free of the buffer overrun/overflow types of exploits and 2) originally assumed a potentially hostile environment and so risk mitigation permeates all aspects of design and implementation.

for other drift ... my work on merged taxonomies and glossaries
https://www.garlic.com/~lynn/index.html#glosnote

I've drawn on numerous sources for merged security taxonomy and glossary
https://www.garlic.com/~lynn/secure.htm

click on "risk management" in the glossary "fastpath" and there are broad range of definitions ... some specific to information systems and others more general.

from GAO 06-91:
A continuous process of managing through a series of mitigating actions that permeate an entity's activities, the likelihood of an adverse event and its negative impact. Risk management addresses risk before mitigating action, as well as the risk that remains after countermeasures have been taken.

... snip ...

307 digit number factored

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: 307 digit number factored
Date: Mon, 21 May 2007 20:48:19 -0600
To: cryptography@xxxxxxxx
Victor Duchovni wrote:
The other issue is that sites will need multiple certs during any transition from RSA to ECC, because the entire Internet won't upgrade overnight. I am not expecting public CAs to cooperate by charging the same price for two certs (RSA and ECC) for the same subject name(s), this also may significantly impede migration.

in theory, certification authorities charge for the certification operations that they perform ... and the certificate is just a representation of that certification process.

somewhere over the yrs the term "certification authority" was truncated to "certificate authority" ... along with some impression that certificates are being sold (as opposed to certification processes).

doing quicky web search of licensing and certification agencies ... it looks like there is charge for replacing certificates/licenses ... but nothing compared to the charge for the original certification process.

of course ... the whole licenses/credentials/certificates are an offline world paradigm .... licensing, credentialing, and certifications can be validated with online, real-time operations ... obsoleting any requirement for supporting offline methodologies.

it would be really great to make it an excuse to move away from offline paradigm to real online operation ... getting totally rid of the need for domain name certificates ... DNS serving up both ip-addresses and public keys in single operation.

307 digit number factored

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: 307 digit number factored
Date: Tue, 22 May 2007 09:40:29 -0600
To: Ivan Krstić <krstic@xxxxxxxx>
CC: cryptography@xxxxxxxx
Ivan Krstić wrote:
That can't happen until we make sure you can trust DNS, which in turn can't happen until we get a concrete proposal that has clearly defined goals and isn't braindead. As has been amply pointed out, it's not clear that DNSSEC will cut it anytime soon.

re:
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored

A big part of the issue is the domain name certification authority has to trust the domain name infrastructure as to the true owner of the domain name ... when they are processing a domain name certificate application for certification (i.e. only the actual domain name owner on file with the domain name infrastructure should be able to apply for domain name certifications).

The catch-22 is that the original idea behind domain name certificates were because of integrity issues with the domain name infrastructure. However, the domain name certification industry is dependent on the integrity of the domain name infrastructure in their domain name certification process.

As a result they need to improve the integrity of the domain name infrastructure because their dependency on the domain name infrastructure in their process of certification.

So one of the proposals (somewhat backed by the domain name certification authority industry) is that domain name owners place a public key on file when they register a domain name with the domain name infrastructure. They all future communication with the domain name infrastructure can be digitally signed ... and the domain name infrastructure verifies the digital signature with the onfile public key.

This is intended to help improve the integrity of the domain name infrastructure. However, it could also offer benefits to the domain name certification authority industry. The domain name certification authority industry could also then start requiring that domain name certification applications also be digitally signed. The the domain name certification authority industry can do a real-time retrieval of the on-file public key to verify the domain name certification application digital signatures. This provides for turning a time-consuming, error-prone, and expensive identification process into a much simpler, reliable, and less expensive authentication process (enormous benefits for the domain name certification authority industry).

The issues for the domain name certification authority industry are somewhat two fold:

1) the original justification for domain name certification involved integrity issues with the domain name infrastructure. improving the integrity of the domain name infrastructure would reduce the original justification for having domain name certification

2) if the domain name certification authority industry could start relying on real-time retrieval of public keys ... then possibly the rest of the world could also ... eliminating the need for domain name certifications

some collected catch-22 posts
https://www.garlic.com/~lynn/subpubkey.html#catch22

long ago and far away, we had been called in to consult with this small client/server startup that wanted to do payment transactions and had this technology called SSL. In addition to doing stuff about working out the payment transaction operation we also had to do a lot of stuff with end-to-end business process investigation of these new business operations called certification authorities. Since then, this has frequently come to be referred to as electronic commerce. some old posts
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

and collection of posts mentioning payment processing and payment gateway
https://www.garlic.com/~lynn/subnetwork.html#gateway

Now, the original SSL infrastructure was to verify that the URL that the user entered (into the browser) corresponded to the website that the browser was talking to (i.e. the website that the user thought they were talking to was the website they were actually talking to). However, most electronic commerce sites fairly quickly found that SSL was costing them something like 90percent of their thruput. The result was that most websites transitioned to no longer using SSL for the initial user connection but reserved just for the payment process (to hide the account number information). Now the user clicks on a button (provided by the webserver) which generates a URL (provided by the webserver). Now instead of checking the URL provided by the user against the webserver ... most use of SSL now checks the URL provided by the webserver against the webserver (invalidating the original SSL security assumptions). lots of past posts about ssl digital certificate infrastructure
https://www.garlic.com/~lynn/subpubkey.html#sslcert

so it could be claimed that the way that the currently deployed SSL for the electronic commerce infrastructure doesn't really cut it either ... it is somewhat a case of the emperor's new clothes ... and the integrity of the domain name infrastructure has to be improved in any case, since it is the trust root for the whole domain name certification authority industry's certification process (but fixing the integrity of the trust root could also make additional domain name certification processes redundant and superfluous).

afterwards we did some work with the x9a10 financial standard working group that in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (i.e. all, point-of-sale, internet, credit, debit, ach, face-to-face, stored-value, aka ALL). The result was the x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959

In the security acronym "PAIN" now, we've claimed that possibly the largest use of SSL is in support of electronic commerce (to hide account number information).

however, in X9A10, a detailed end-to-end vulnerability and threat analysis was performed ... and divulging account information was identified as major exploit (requiring SSL to hide transaction information). However the majority of exploits had never been capturing information in transit (before SSL, even before the internet) ... it had always been capturing information at end-points and/or logs of previous transactions. As a result, a primary objective of X9.59 financial standard was to eliminate havesting/skimming of previous transactions as a (replay attack) vulnerability. The result was that X9.59 effectively "armors" every transaction ... in effect replaces "privacy/confidentiality" as a countermeasure with "authentication" and "integrity".

X9.59 transactions no longer have to be hidden as a fraud countermeasure. This eliminates the requirement to hide such transactions ... and therefor eliminates the major use of SSL in the world today (related to electronic commerce). X9.59 also eliminates the major threats and vulnerabilities related to the data breaches and security breaches that have been in the news recently. some related recent posts about naked transactions/payments metaphor
https://www.garlic.com/~lynn/subintegrity.html#payments

for some topic drift ... lots of the stuff being "hidden" with SSL are really transaction oriented operations ... and if domain name infrastructure could serve up public keys ... there could be significant thruput improvements in such protocols. some recent posts in a financial crypto blog
https://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardized Security Protocols are Too Heavy
https://www.garlic.com/~lynn/aadsm27.htm#1 H6.2 Most Standardized Security Protocols are Too Heavy

dnssec?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: dnssec?
Date: Tue, 22 May 2007 14:31:06 -0600
To: cryptography@metzdowd.com <cryptography@metzdowd.com>
re:
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored

sometimes i wonder if at least some of the dnssec issue doesn't turn out to be related to not having a revenue flow champion.

domain name certification business caught on fairly rapidly (as countermeasure to perceived integrity issues with domain name infrastructure).

fixing the domain name infrastructure integrity issues 1) doesn't appear to have any champion (at least motivated with significant incremental revenue flow) ... and 2) could make the existing industry doing domain name certifications obsolete, redundant and superfluous.

for other topic drift ... a recent post with some DNS related trivia ... more than a decade before DNS (about half-way down the post mentioning former MIT student)
https://www.garlic.com/~lynn/2007k.html#33 Even worse than UNIX

and for other topic drift, old email about online, real-time public key distribution (also predating DNS)
https://www.garlic.com/~lynn/2006w.html#email810515
in this post
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network

dnssec?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: dnssec?
Date: Wed, 23 May 2007 13:52:23 -0600
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
Anne & Lynn Wheeler wrote:
for other topic drift ... a recent post with some DNS related trivia ... more than a decade before DNS (about half-way down the post mentioning former MIT student)
https://www.garlic.com/~lynn/2007k.html#33 Even worse than UNIX

and for other topic drift, old email about online, real-time public key distribution (also predating DNS)
https://www.garlic.com/~lynn/2006w.html#email810515
in this post
https://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network


re:
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?

and rfc editor announcement from today .... my rfc index
https://www.garlic.com/~lynn/rfcietff.htm

https://www.garlic.com/~lynn/rfcidx8.htm#4871
4871 PS
DomainKeys Identified Mail (DKIM) Signatures, Allman E., Callas J., Delany M., Fenton J., Libbey M., Thomas M., 2007/05/22 (71pp) (.txt=166054) (Obsoletes 4870) (See Also 4870) (Refs 1847, 2045, 2047, 2440, 2821, 2822, 3447, 3490, 3766, 3833, 3851, 4033, 4234, 4686) (was draft-ietf-dkim-base-10.txt)

https://www.garlic.com/~lynn/rfcidx8.htm#4870
4870 -H
Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys), Delany M., 2007/05/22 (41pp) (.txt=87378) (Obsoleted by 4871) (See Also 4871) (Refs 1421, 3833, 3851, 4648) (was draft-delany-domainkeys-base-06.txt)


PKI moving to adopt the plugin model -- realignment to security based on user-needs?

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: May 23, 2007 06:03 PM
Subject: PKI moving to adopt the plugin model -- realignment to security based on user-needs?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000927.html

or make it obsolete, redundant and superfluous

recent thread/posts in crypto mailing list
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?

including reference to brand new RFC for fixing spam and phishing (using DNS to serve up public keys)

New antiphishing, antispam specifications unveiled
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9020940
IETF approves new weapon to fight spam, phish
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1256125,00.html

and for slight drift ... sort of DNS related trivia reference more than a decade before DNS
https://www.garlic.com/~lynn/2007k.html#33

and old email (also predating DNS) proposing online, real-time public key serving
https://www.garlic.com/~lynn/2006w.html#email810515
in this post
https://www.garlic.com/~lynn/2006w.html#12

307 digit number factored

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 307 digit number factored
Date: Wed, 23 May 2007 16:30:59 -0600
To: James A. Donald <jamesd@echeque.com>
CC: cryptography@metzdowd.com <cryptography@metzdowd.com>,
Ivan Krstić <krstic@solarsail.hcs.harvard.edu>
James A. Donald wrote:
The problem is organizational. To get one decision centrally made and imposed on everyone requires a central body capable of making decisions and imposing them on everyone, and before it can get that authority, that central body usually has to raze Atlanta and burn the crops, or inflict genocidal famine on the Ukraine. The great strength and great weakness of the internet is that it is an anarchy. Anything that requires one decision made for all, such as the domain name system, got frozen when the internet became too large for decision making by consensus, and is now extremely difficult to change. So to make changes, they have to be made incrementally: You need a CA with the proposed policy and a deal with several registrars, and that CA needs to get on the Mozilla and IE list. Nice selling point. If you register with, say OpenSRS, you would automatically get an SSL cert. Unfortunately, the certification process for a CA to get on the browser list seems to be somewhat circular - to be a CA, you have to prove you are like existing CAs, which is most easily done if you *are* an existing CA, and have no intention of changing the way you work.

re:
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored

... that could be the short term view ... as well as dealing with established operation ... having been around since before the current CA stuff started ... and somewhat involved in helping get the current infrastructure established (from the standpoint of its inception for what is now called electronic commerce ... and having to do detailed business process & technical walk thru and audit of the early certification authority players) ... the issue is more how to replace something once it was established (i.e. the current infrastructure somewhat got fast uptake ... because it didn't have alternative solutions to deal with).

re:
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?

somewhat topic drift with DNS related trivia ... more than a decade before DNS
https://www.garlic.com/~lynn/2007k.html#33

and some old email (predating dns) suggesting online, realtime public key server
https://www.garlic.com/~lynn/2006w.html#email810515
in this post
https://www.garlic.com/~lynn/2006w.html#12

307 digit number factored

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: 307 digit number factored
Date: Thu, 24 May 2007 14:07:04 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: cryptography@xxxxxxxx <cryptography@xxxxxxxx>,
    Ivan Krstić <krstic@xxxxxxxx>
re:
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored

part of the quick IETF uptake of SSL and VPN in the 94/95 time-frame was that there really wasn't any serious competition. there was ipsec ... but it was end-to-end implementation at low level ip-stack ... which were kernel implementations ... and then was faced with the whole issue of distribution, installation and support of new kernels on machines all around the world (from a variety of different vendors and different operating systems).

SSL was almost a no-brainer ... since it just involved loading/installing a new application (orders of magnitude easier than ipsec). lots of collected posts mentioning SSL and/or SSL certificates
https://www.garlic.com/~lynn/subpubkey.html#sslcert

in the same time-frame VPN was introduced at the gateway committee meeting at '94 San Jose IETF meeting. We had worked with the guy on and off since the late 70s and he originally developed the technology for his own use ... between home and office; actually both his wife and he worked for different technology companies ... he got a leased line from the house to his office ... and her company got a circuit from his office to their office. The issue was how to encrypt the wife's communication w/o having it exposed to the husband and/or the husband's company.

sort of the state-of-the art had been link encryptors ... for a little topic drift ... the internal corporate network had been larger than the arpanet/internet from just about the beginning until possibly summer of '85. the internal network required encryption on everything leaving the premise ... and in the mid-80s there were comments that the internal network had over half of all link encryptors in the world. misc. past posts mentioning the internal network.
https://www.garlic.com/~lynn/subnetwork.html#internalnet

the requirement that led to VPN was how to carry separately encrypted streams over the same link. ipsec would have solved the problem ... but again was end-to-end solution that required upgrading all the low-level ip-stacks ... which required distribution, installation (and support) of new kernel. the VPN solution was to handle the stream encryption/decryption in boundary routers (which could be tunneled over other infrastructure).

my observation was this resulted in some amount of consternation in the ipsec faction ... which they somewhat resolved by starting to refer to VPN as "lightweight ipsec" (and of course, everybody else could then refer to regular ipsec as "heavyweight ipsec").

the other problems was with various router vendors in the IETF. it was sort of divided along the lines of the vendors that had enuf horse power in their current boxes to implement and deploy VPN support ... and the other vendors whos' products didn't have enuf processing power available to do the crypto operations in support of VPN. This difference dragged out some of the VPN standardization activity within IETF.

misc. past posts mentioning "lightweight ipsec"
https://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI?
https://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch?
https://www.garlic.com/~lynn/aadsm25.htm#19 Hamiltonian path as protection against DOS
https://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN
https://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec
https://www.garlic.com/~lynn/2007d.html#37 MAC and SSL
https://www.garlic.com/~lynn/2007g.html#63 The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007h.html#67 SSL vs. SSL over tcp/ip

for other drift ... some of the people doing VPN implementations were using RSA bsafe library ported to whatever processor they were using. Some number of these put in effort to enhance the performance of bsafe library.

some of this was going on when we were in transition from working on the infrastructure that is currently frequently referred to as electronic commerce and work in the x9a10 financial standard committee. in that same time frame there were other efforts looking at "enhancing" how payment transactions could be implemented and deployed for the internet (as opposed to x9a10 standards work which had a requirement to have a standard that preserved the integrity of financial infrastructure for ALL retail payments).

One of these published some of their specification and from the specification I drew up a business operation profile and a "public key" operation profile. I then got the "public key" operation profile executed on a number of different platforms using the "speeded up" bsafe library (running four times faster) ... and reported the numbers back to the organization responsible for that specification. The people in the organization "claimed" that the performance numbers were one hundred times too slow (instead of observing that they were four times too fast). About six months later when they actually had some prototype code ... the "profile" numbers were within a couple percent of measured (the speeded up bsafe library having been returned to rsa).

307 digit number factored

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: 307 digit number factored
Date: Thu, 24 May 2007 16:25:31 -0600
To: StealthMonger <StealthMonger@xxxxxxxx>
CC: cryptography@xxxxxxxx
StealthMonger wrote:
This would destroy the protection of one who depends on off-line, message-based communication for self-defense.

Such a person may create and maintain a persistent pseudonym through untraceable chains of random latency, anonymizing remailers which thwart traffic analysis through mixing.

On-line, connection-based communication has low latency and can be traced by traffic analysis.


re:
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored

the credential/licensing/certificate paradigm was certification of strangers who have never before communicated before ... and there was no timely, available mechanism for providing information about the other party (aka the analogy of letters of credit/introduction from sailing ship days and before).

parties with previous relationship can have available information about each other based on prior relationship ... or strangers in first time communication may have access to timely sources of information about the other party.

the issue wasn't that the offline stranger paradigm didn't exist ... it just was a rapidly disappearing scenario ... aka digital certificates were somewhat modeled after the sailing ship "days" letters of credit/introduction for the early 80s offline email scenario for first time communication between complete strangers ... dial-up local electronic post-office, exchange email, hang-up ... and then potentially faced with first-time email from total stranger.

while digital certificate wasn't as high a quality information paradigm as real-time, online ... in this particular scenario, it was better than the alternative ... nothing.

the issue isn't eliminating digital certificates for the situations where they may be appropriate ... it is eliminating digital certificates for uses where they are obsolete, never intended for, redundant and/or superfluous. For all the situations where digital certificates and PKI aren't applicable (or redundant and superfluous) they tend to represent and extraneous and unnecessary business cost providing little or no added value.

in the wake of some of the original stuff (w/SSL that is frequently no referred to as electronic commerce) there was some investigations that looked at adding digital certificate kinds of processing to existing real time payment transactions
https://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored

.... some of the comments was that adding such digital certificate processing would bring payment transactions into the modern era. Our observation was that reverting to an offline PKI, digital certificate processing paradigm would set back real-time payment transactions several decades. That if you were doing real-time payment transactions that online, timely processing had significantly higher quality information processing ... real-time status of public key onfile in the account record as well as aggregated information ... recent payment transaction patterns, current balance and/or credit limit, etc. It was in the wake of that series of exchanges that you saw OCSP work start in IETF.

We observed that not only was the stale, static digital certificate addition to real-time payment transactions redundant and superfluous ... that the typical proposals of the period represented a factor of 100 times in payload size bloat (enormous payload cost addition providing no added benefit) as well as the redundant and superfluous digital certificate processing increased real-time payment transaction processing by nearly a factor of 100 times. Misc. past posts mentioning enormous redundant and superfluous stale static digital certificate added overhead
https://www.garlic.com/~lynn/subpubkey.html#bloat

A crazy thought?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A crazy thought?
Date: Sun, 27 May 2007 09:19:37 -0600
To: Allen <netsecurity@xxxxxxxx>
CC: cryptography@xxxxxxxx
Allen wrote:
Hi Gang,

In a class I was in today a statement was made that there is no way that anyone could present someone else's digital signature as their own because no one has their private key to sign it with. This was in the context of a CA certificate which had it inside. I tried to suggest that there might be scenarios that could accomplish this but was told "impossible." Not being totally clear on all the methods that bind the digital signature to an identity I let it be; however, the "impossible" mantra got me to thinking about it and wondering what vectors might make this possible.


CAs are certification authorities ... they certify some information they have checked and issue digital certificates that represent that checking ... somewhat analogous to physical licenses, credentials, certificates.

most certification authorities aren't the authoritative agency for the information that they certify ... for the most part they are simply certifying that they have checked the information with whatever authoritative agency is responsible for that information.

in that sense they are somewhat like notary ... i.e. if somebody has done some identity theft and managed to obtain a valid driver's license ... the notary isn't held responsible ... they just notarize that they checked a valid drivers license.

this is somewhat the catch-22 scenario in recent posts for ssl domain name certification authorities
https://www.garlic.com/~lynn/subpubkey.html#catch22

where they are in something of a situation because big part of the original justification for ssl domain name certificates involved integrity issues with the domain name infrastructure ... however, the domain name infrastructure is also the authoritative agency for domain name owner information, which the ssl domain name certification authority is dependent on as part of the integrity for certifying ssl domain name information. Fixing integrity issues in the domain name infrastructure ... improves the probability that correct ssl domain name certification is being performed ... but fixing integrity issues in the domain name infrastructure can also drastically reduce justification for having ssl domain name certificates.

recent posts
https://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#16 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#17 dnssec?
https://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored
https://www.garlic.com/~lynn/aadsm27.htm#21 307 digit number factored

in some cases, there is the possibility that the excessive attention to the details of the cryptographic operations is pure obfuscation that the rest of the end-to-end business processes may purely be built on a house of cards.

for additional drift, some recent posts in related thread on digital certificates in another fora (including some possible infrastructure vulnerabilities and systemic risks)
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#48 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#0 Re: John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#2 Re: John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#6 Re: John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#9 Re: John W. Backus, 82, Fortran developer, dies

Identity resurges as a debate topic

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: June 7, 2007 04:41 PM
Subject: Identity resurges as a debate topic
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000931.html

so can I kick off some here

i've somewhat interacted with some of the parties/players in the identity sphere ... part of it involves
  1. reducing principles of authentication & authorization to its fundamental, atomic (KISS) units ... as in attempting to show a way of moving from an institutional-centric hardware token (something you have) paradigm to a person-centric hardware token paradigm ... recent post on subject
    https://www.garlic.com/~lynn/2007l.html#8
  2. working the concepts into the structure of my merged security taxonomy & glossary (which some of the identity related standards work have referenced):
    https://www.garlic.com/~lynn/index.html#glosnote
in the past couple days, i got an inquiry from one of the "identity" players about expanding the security taxonomy/glossary with more identity related concepts. I've gone ahead with a start using a number of ".gov" sources ... including GSA's federated identity management manual.

authentication basically comes down to having high confidence that you are who you claim to be (aka involves identity). authorization basically comes down to permissions for the specific entity. frequently authentication and identification get confused

basically it is relatively straight-forward to aggressively cost-reduce a something you have hardware token ... even if multi-factor authentication gets involved ... with token support for something you know and/or something you are authentication ... from 3-factor authentication model
https://www.garlic.com/~lynn/subintegrity.html#3factor

lots of the complexity isn't from straight-forward authentication principles .... its getting confused with the authorization characteristics. lots of the hardware tokens aren't aggressively cost reduced ... they have lots of hand-waving about added value ... almost all of this carries with it lots of personal information. one possible scenario is that all the personal information can't be interpreted as related to "authentication" ... i.e. relying party grants permissions and privileges based on personal/privacy characteristics (aka it is getting heavily involved in authorization as "added" value).

this is left over from the offline world ... my frequent reference to explaining that the PKI digital certificate (which many of the hardware tokens are starting to emulate) is an electronic analog to physical credentials, certificates, licenses ... along the lines of the letters of credit/introduction from the sailing ship days (and earlier) when the relying party would be having first time interaction with a total stranger and unable to directly confer/check with any possible reference. the apparent tendency in the early to mid 90s was to grossly overload an x.509 identity digital certificate with enormous amounts of personal information ... as a means of aiding relying parties in authorization decisions (unrelated to any authentication and identity). it was in the mid-90s that there started to be some realization that such digital certificates, grossly overloaded with personal information represented significant privacy and liability issues. this led to the "replying-party-only" digital certificates ... which contained only sufficient information for authentication (identity)
https://www.garlic.com/~lynn/subpubkey.html#rpo

all the necessary personal information necessary for authorization then was obtained from some other source (once authentication had been performed). however it was trivial to show that relying-party-only certificates were redundant and superfluous ... since ALL the information the information for both authentication and authorization could be obtained from the same source ... and therefor it was possible to have a digital signature verification infrastructure (for both authentication and authorization) that had no need for PKI and digital certificates
https://www.garlic.com/~lynn/subpubkey.html#certless

so i would claim that the "identity" for the authentication part can be extremely simple and cost-effective (KISS). frequently it is the inclination to include enormous amounts of personal information as an aid allowing "relying parties" to base "authorization" decisions. It is also such enormous amounts of personal information that result in the privacy and liability issues.

this has led to the added value variations (digital certificates and hardware tokens) moving into the "no value" market segment ... i.e. environments where the relying party operations can't justify cost of their own information repository about individuals and/or justify online connectivity to some authoritative agency. the downside of moving into "no value" market segments is that it becomes even more difficult to justify the cost of any added value offerings.

so my tendency would be to claim that some amount of the whole swirl around "identity" ... isn't related to identity for authentication; it is all the possible enormous amounts of personal information that opens up the responsible agency for both privacy invasive liability from the individuals (possibly from data breaches) as well as any related authorization liability from relying parties (how to provide sufficient personal information so that relying parties can make authorization decisions w/o incurring any legal liability).

the other historical scenario (related to cross-domain, federated, etc) swirl around identity is all the stuff that there was in the 90s with PKIs trying to define cross-infrastructure operation for digital certificate (enormous amounts of privacy information as aid in cross-domain authorization decisions).

we had run into the same scenario nearly a decade earlier in a prior life when we were working for one of the companies that provided half of the funding/grants for MIT's Project Athena. Kerberos (authentication) was originally work done at Project Athena ... and it was one of the projects we would get to periodically review. We happened to be there when there was a week of working sessions on the initial details of Kerberos cross-domain support. More recently we sat thru a presentation on a SAML implementation where the message flows were essentially identical to what was worked out for cross-domain Kerberos (except using SAML encoded messages).

Later there was the pk-init draft for Kerberos ... registering public keys in lieu of passwords for authentication ... again a purely certificate-less public key mode of operation. Somewhat after that, there was heavy lobbying to also add definition for certificate-mode of operation to the pk-init draft. Since then, one of the principles behind that (digital certificate) lobbying effort has periodically contacted us to apologise (i.e. digital certificate mode of operation for Kerberos being redundant and superfluous). misc of past posts mentioning Kerberos
https://www.garlic.com/~lynn/subpubkey.html#kerberos

Why self describing data formats:

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Why self describing data formats:
Date: Sat, 09 Jun 2007 13:17:17 -0600
To: James A. Donald <jamesd@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
James A. Donald wrote:
Many protocols use some form of self describing data format, for example ASN.1, XML, S expressions, and bencoding.

Why?


gml (precursor to sgml, html, xml, etc)
https://www.garlic.com/~lynn/submain.html#sgml

was invented at the science center in 1969
https://www.garlic.com/~lynn/subtopic.html#545tech

... some recent (science center) topic drift/references in this post
https://www.garlic.com/~lynn/2007l.html#65 mainframe = superserver

"G", "M", & "L" were individuals at the science center ... so the requirement was to come up with an acronym from the inventors initials

so some of the historical justification for the original "markup language" paradigm can be found

originally CMS had the script command for document formating ... using "dot" format commands ... i.e. science center on 4th flr of 545 tech sq doing virtual machines, cp67, cms, the internal network, etc ... and multics on 5th flr of 545 tech sq ... draw from some common heritage to CTSS (and some of the unix heritage traces back thru multics also to CTSS).

the original GML was sort of a combination of "self-describing" data (somewhat for legal documents)
https://web.archive.org/web/20231001185033/http://www.sgmlsource.com/history/roots.htm
http://xml.coverpages.org//sgmlhist0.html

and document formating ... when GML tag formating was added to CMS script processing command. Later you find a big CMS installation at CERN ... and HTML drawing heritage from the "waterloo" clone of the CMS script command.
http://infomesh.net/html/history/early/

first webserver outside of europe was at slac (a CERN "sister" location) ... another big vm/cms installation:
http://www.slac.stanford.edu/history/earlyweb/history.shtml

recent historical post/reference
https://www.garlic.com/~lynn/2007d.html#29 old tapes

last time i checked, w3c hdqtrs was around the corner from the old science center location at 545 tech. sq.

before GML, the science center had an activity involving "performance" data from the time-sharing service (originally using virtual machine cp67 service and then transitioning to vm370) ... lots of system activity data was captured every 5-10 minutes and then archived to tape ... starting in the mid-60s ... by the mid-70s there was a decade of data spanning lots of different configurations, workloads, etc. The original intention when the system activity data was being archived was to include enuf self-describing information that the data could be interpreted many yrs later. lots of past posts about using cp67&vm370 for time-sharing services (both for internal corporate use and customers offering commercial, online time-sharing services using the platform)
https://www.garlic.com/~lynn/submain.html#timeshare

lots of past posts about long term performance monitoring, workload profiling, benchmarking and stuff leading up to things like capacity planning
https://www.garlic.com/~lynn/submain.html#benchmark

much later, you find things like ASN.1 encoding for handling interoperability of network transmitted data between platforms that might have different information representation conventions (like the whole little/big endian stuff).

one of the things swirling around digital signature activity in the mid-90s was almost religious belief that digital certificate encoding mandated ASN.1.

other digital signature operations that were less religious about PKI, x.509 identity digital certificates, etc ... were much less strict about encoding technique for digitally signed operations ... included certificate-less digital signature infrastructures
https://www.garlic.com/~lynn/subpubkey.html#certless

One of the battles during the period between XML and ASN.1 proponents during the period was that XML didn't provide for a deterministic encoding. It really was somewhat a red herring on the digital certificate ... ASN.1 side ... since they were looking at always keeping things ASN.1 encoded (not just for transmission) ... and only decoding when some specific information needed extraction.

On the other side was places like FSTC which was defining digitally signed electronic check convention (with tranmission over ACH or ISO8583). There was already a transmission standard ... which ASN.1 encoding would severely bloat ... not to mention the horrible payload bloat that was the result of any certificate-based infrastructure needing to append redundand and superfluous digital certificates.
https://www.garlic.com/~lynn/subpubkey.html#bloat

FSTC just defined appending a digital signature to existing payload. The issue then became a deterministic encoding of the information for when the digital signature was generated and verified. If you temporarily encoded the payload as XML, generated the digital signature ... and then appended the digital signature to the standard (ACH or ISO8583) payload ... the problem was that at the other end, XML didn't provide a deterministic encoding methodology so that the recipient could re-encode the payload and verify the digital signature. So FSTC eventually defined some additional rules for XML called FSML ... which then was turned over to W3C as part of XML digital signature activity.

There was something of a cultural class between the FSTC orientation and much of the x.509 standards environment. In the FSTC world ... the information is only temporarily encoded for digital signature generation and verification; the rest of the time, the data is in some native usable form. In the X.509 standards environment, the data tends to always remain encoded in ASN.1 format ... and is only (temporarily) decoded when it is actually needed to be used/accessed.

Why self describing data formats:

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: James A. Donald <jamesd@xxxxxxxx>
Subject: Re: Why self describing data formats:
Date: Sat, 09 Jun 2007 13:39:33 -0600
CC: Cryptography <cryptography@xxxxxxxx>
re:
https://www.garlic.com/~lynn/aadsm27.htm#24 Why self describing data formats:

for other archaeological trivia ... later i transferred from the science center to SJR and got to do some of the work on the original relational/sql implementation, System/R.

a few years later, the "L" in GML also transferred to SJR and worked on relational, included being involved in the development of of BLOBS (Binary Large OBjectS) for relational.

roll forward a few yrs to the acm (database) sigmod conference in san jose in the early 90s. In one of the sessions, somebody raised the question about what was all this X.500 and X.509 stuff going on in ISO ... and there was somebody from the audience that explained how it was a bunch of networking engineers trying to re-invent 1960s database technology.

today ... you can periodically find heated online discussion about XML "databases" and whether they compromise the purity of information integrity that you get from the relational paradigm. lots of past posts mentioning various things about system/r, relational database technology, etc
https://www.garlic.com/~lynn/submain.html#systemr

A crazy thought?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A crazy thought?
Date: Sat, 09 Jun 2007 14:27:21 -0600
To: Allen <netsecurity@xxxxxxxx>
CC: cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?

for some other topic drift regarding certification authorities ... having been certification authorities for "digital certificates" targeted at the (electronic but) "offline" market ... they encountered a number of issues in the mid-90s as the world was transitioning to ubiquitous online operation ... the digital certificates were somewhat targeted for relying parties ... dealing with total strangers (that they had no prior information about) and had no timely mechanisms for directly contacting any authorities for references regarding the stranger.

so one of the issues for x.509 identity certificates ... small x-over from this other thread
https://www.garlic.com/~lynn/aadsm27.htm#25 Why self describing data formats

was to try and move out of the no-value market into the identity market ... aka ... as world transitioned to ubiquitous online operation ... the remaining "offline" was "no-value" situations where the relying-party couldn't justify the cost of maintaining information about the parties that they dealt with (aka something analogous to browser "cookies") and/or couldn't justify the cost of directly contacting responsible agencies for information about the parties they were deailing with.

now in this recent thread ... somewhat about some internet historical evolution
https://www.garlic.com/~lynn/2007l.html#67 nouns and adjectives
https://www.garlic.com/~lynn/2007l.html#68 nouns and adjectives
https://www.garlic.com/~lynn/2007l.html#69 nouns and adjectives
https://www.garlic.com/~lynn/2007l.html#70 nouns and adjectives

the last post drifts into the subject of some of the recent "churn" around identity activities ... also lengthy post on the subject here:
https://www.garlic.com/~lynn/aadsm27.htm#23 identity resurges as a debate topic

the certification authorities were somewhat looking at increasing the value of x.509 identity digital certificates (since there wasn't a lot of future selling into the no-value market segment) by starting to grossly overload the digital certificates with enormous amounts of personal information.

now typically identity has been a authentication characteristic ... adding potentially enormous amounts of personal information could be considered attempting to move into the authorization area ... where a relying-party might be able to make a authorization, approval, and/or permission decision purely based on the additional personal information in the digital certificate.

what was seen by the mid-90s was that many of the institutions were starting to realize that x.509 identity digital certificates, grossly overloaded with personal information represented significant privacy and liability issues. what you saw then was a retrenchment to purely authentication, relying-party-only digital certificate
https://www.garlic.com/~lynn/subpubkey.html#rpo

with the digital certificate containing little more than a record locator (where all the necessary information was actually kept, even real-time, and aggregated information ... which is difficult to achieve in a stale, static digital certificate paradigm) and a public key ... note, however, we could trivially show that in such situations the stale, static digital certificate was redundant and superfluous ... aka just add the public key to the entity's record ... which already had all the personal, private and other information necessary for authorization. in the payments market segment ... this is somewhat separate from the fact that the appended stale, static, redundant, and superfluous digital certificates were causing a factor of 100 times payload and processing bloat
https://www.garlic.com/~lynn/subpubkey.html#bloat

one of the other problems faced by certification authorities attempting to move identity digital certificates into the authorization market segment was what (with loads of personal information), if any, liability were certification authorities going to accept with regard to authorization problems encountered by the relying-parties (depending on the digital certificate personal information in their decision making process).

A crazy thought?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A crazy thought?
Date: Sat, 09 Jun 2007 18:02:10 -0600
To: Jim Dixon <jdd@xxxxxxxx>
CC: Allen <netsecurity@xxxxxxxx>,  cryptography@xxxxxxxx
Jim Dixon wrote:
The CA certifies that X is your public key. It doesn't know what your private key is.

If the CA starts handing out false public keys - which is the worst that it could do, right? - it will find itself instantly distrusted. Everybody in the world will be able to see that the CA used its private key to sign a false statement. The offended party need only put the false declaration up on the Web.


CAs actually tend to certify that they were able to verify a supplied digital signature with a supplied public key ... with the implication that the entity who supplied the signature & key ... had access to the corresponding private key, in order to generate the signature (aka something you have authentication model).

CAs then may also certify that they were able to verify some amount of other information related to the entity supplying the signature and public key.

the existence of a certified digital certificate with a different public key ... can be on the order of various kinds of identity theft ... and as equally difficult to deal with.

for instance ... it may not be sufficient that you can prove that there are two distinct, different digital certificates ... in the identity theft scenario ... it may also going to require that the disputed digital certificate couldn't possibly apply to you (which is more than just that it is not the same as the digital certificate you are owning up to).

previous posts in thread:
https://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?
https://www.garlic.com/~lynn/aadsm27.htm#26 A crazy thought?

A crazy thought?

From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A crazy thought?
Date: Sat, 09 Jun 2007 18:34:42 -0600
To: Ian G <iang@xxxxxxxx>
CC: Allen <netsecurity@xxxxxxxx>,  cryptography@xxxxxxxx
Ian G wrote:
What you are suggesting is called Web of Trust (WoT). That's what the PGP world does, more or less, and I gather that the SPKI concept includes it, too.

However, x.509 does not support it. There is no easy way to add multiple signatures to an x.509 certificate without running into support problems (that is, of course you can hack it in, but browsers won't understand it, and developers won't support you).


re:
https://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought?
https://www.garlic.com/~lynn/aadsm27.htm#26 A crazy thought?
https://www.garlic.com/~lynn/aadsm27.htm#27 A crazy thought?

actually ... at a very fundamental level both PKI and PGP have nearly identical business and implementation processes ... the difference is somewhat that the PKI operations tend to try and make out that their structure is more formal ... and therefor should be more trusted.

Both implementations require that the relying-parties have some sort of local trusted public key repository ... initially populated with some out-of-bad process. In the SSL PKI scenario ... there tends to be a trusted public key repository built into each browser distributed ... initially loaded with possibly 40-50 public keys that you are told that you can trust. In the "web of trust" scenario ... there tend to be some set of public keys that are also trusted and have also been acquired in some out-of-band process.

In both scenarios ... the relying-party is expected to "trust" new public keys that carry digital signatures ... where these digital signatures can be verified with public keys from their local repository of (already) trusted public keys (public keys that have typically been distributed/initialized by some out-of-band process)

It isn't so much that the fundamental processes are different ... it is more about how tightly controlled and cast in concrete the surrounding pieces happen to be (aka formalized and not easily changed/adapted).

For totally other drift ... one of the places we came up with requirement for multiple digital signatures was in the process for x9.59 financial infrastructure for payment transactions ... i.e. 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
https://www.garlic.com/~lynn/x959.html#x959

x9.59 actually doesn't specify the details of digital signature process ... but defines the fields necessary for a payment transactions which require authentication and integrity protection on end-to-end basis. one of the scenarios is the authentication of the account holder with digital signature (which also provides payment transaction integrity). one of the trust issues was that there could be various kinds of exploits at the originating environment (where the account holder's digital signature and the transaction was otherwise valid). to increase the trust (as indication of possible countermeasures against these additional exploits/vulnerabilities) allowed for the originating environment to also digitally sign the transaction (as a flavor of "device" authentication, possibly a point-of-sale terminal or other kind of device that was used to originate the transaction).

the FSTC electronic check work also allowed for multiple digital signatures ... representing the equivalent of requiring multiple co-signers on business checks ... i.e. business checks that allow for single signer if the amount is below some limit ... but requires additional co-signers for larger amounts.

note that both in the FSTC electronic check and the X9.59 financial standard scenario, there was some assumption that the basic transaction went via normal existing electronic payment networks ... with appended digital signature(s) ... where the transaction might actually only be encoded during just the digital signature generation and digital signature verification processes. recent posts in the encoding thread:
https://www.garlic.com/~lynn/aadsm27.htm#24 Why self describing data formats:
https://www.garlic.com/~lynn/aadsm27.htm#25 Why self describing data formats:

also any additional appending of traditional digital certificates to such operations could represent a factor of 100 times payload and processing bloat.
https://www.garlic.com/~lynn/subpubkey.html#bloat

A secure Internet requires a secure network protocol

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: A secure Internet requires a secure network protocol
Date: Fri, 22 Jun 2007 10:30:27 -0600
To: Cryptography <cryptography@xxxxxxxx>
A secure Internet requires a secure network protocol
http://www.infoworld.com/article/07/06/22/25OPsecadvise_1.html

from above:
Implementing -- and requiring -- stronger authentication and cryptography standards is the next step toward a new Internet
... snip ...

i would contend that majority of exploits are attacks on (vulnerable) end-points ... not directly involving any actual network protocol or cryptography; this includes (updated) variations on old-time "social engineering" ... which has some relation to authentication (between end-points) ... but on par with crooks using the telephone to call people and convince them of one thing or another (and then suggesting that encrypting the telephone call transmission would eliminate the problem).

one of the things seen in various of the SSL (authentication) vulnerabilities ... are attackers being able to ("authenticate") prove who they claim to be ... however, who they claim to be for SSL authentication ... and who they claim to be for their "social engineering" attacks ... may not be exactly the same.

As before, one of the largest class of attacks (not restricted to internet) are against information related to payment transactions and which (largely because of weak authentication in unrelated parts of the infrastructure) is then turned around and relatively easily used for fraudulent financial transactions. misc. past posts on the theme of "naked" transactions.
https://www.garlic.com/~lynn/subintegrity.html#payment

A secure Internet requires a secure network protocol

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: A secure Internet requires a secure network protocol
Date: Sat, 23 Jun 2007 07:37:02 -0600
To: Alex Alten <alex@xxxxxxxx>
CC: Cryptography <cryptography@xxxxxxxx>
Alex Alten wrote
SSL seems to be hanging by a thread, mainly the name to public key mapping depends on how thorough the checking is done in to SSL vs application layers inside of the web browser. If this is hosed then unrestricted MITM is in the cards sometime in the near future.

re:
https://www.garlic.com/~lynn/aadsm27.htm#29 A secure Internet requires a secure network protocol

i.e. we were called in to consult with this small client/server startup that wanted to do payments on their server. they had this technology they called SSL ... and we had to end-to-end process audits ... including walk-thru of some of these new business entities that were calling themselves certification authorities.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

the fundamental SSL design point was that the user knows the relationship between a website and a URL, the user entered that URL, and SSL would authenticate that the website that the user *thot* they were talking to (from entering the URL), was in fact, the website they were actually talking to.

these days, most users have no cognition about relationship between websites and URLs, they click on something in email and/or webpages. In this scenario, the attacker is providing the URL and then the only thing that SSL is providing is authenticating who the attacker is claiming to be (via the URL that the attacker provides).

the original SSL design point had implicit assumptions that users knew the relationship between the website they thot they were talking to and URLs (and then SSL authenticated the relationship between those known URLs and the website). For the most part those assumptions are no longer valid ... which then breaks the security model and all bets are off. With the potential attacker frequently providing both the URL and the website, then the only thing SSL is providing is authenticating the website that the attacker claims to be (via the URL) is the website that they are (breaking original basic assumption about SSL). This totally invalidates the assumption that SSL is proving that the website that the user *thot* they were talking to (via directly entering the URL) was, in fact, the website that they were talking to (aka the user has no idea what website they are talking to ... because they no longer have the knowledge about the relationship between websites they think they are talking to and the URLs for those websites).

The (URL) name to key mapping isn't the problem ... that is the mechanics that SSL provided. The problem was that SSL security had implicit assumption that the user knew the mapping between the website they think they talk to and the URL for that website. In the current environment, that assumption is no longer valid,

So the basic, most common PKI infrastructures provide a trusted public key repository (typically manufactured into browsers before they ship). Users are indoctrinated that they can trust those public keys ... for the purposes of digitally signed CA digital certificates. These digital certificates provide the binding between URL (actually the domain names part of URL) and website public keys. It is imperative that the user (knowledge) then provide the binding the website they think they are talking to and the URL. That is the part that is missing in today's environment (and what large numbers of attackers can leverage to slip thru the "cracks").

The missing piece is trusted binding between who the user's think they are talking to and the URL (or at least domain name). This could be accomplished by a separate trusted repository ... names that the end-user relates to and trusted binding between those names and URLs. Attacker provided URLs that are clicked on ... then can be cross-checked with things in that new trusted table (analogous to the way that the browser table of certification authority public keys are trusted).

Then the issue is that if there is a trusted table mapping names to URLs (or at least domain names) ... and a separate table of trusted public keys ... the whole thing could be collapsed into a single table ... totally eliminating the level of indirection provided by (redundant and superfluous) PKI and certification authorities ... just add the public key to the trusted table of names & domain names (aka URLs).

The issue isn't so much that SSL is broken ... it is the implicit dependency on users knowing the relationship between the website they think they were talking to and the URL for those websites. Creating a user trusted table of website/urls (analogous to the browser trusted table of certification authority public keys), can make PKIs and certification authorities redundant and superfluous ... since in whatever trusted process is used to maintain the trusted table of website/urls ... can also directly include the public key for those website/urls.

this is similar, but different to some of the domain name infrastructure proposals that would allow real-time retrieval of on-file, domain name public keys (also making PKIs and certification authorities redundant and superfluous). Some past posts discussing catch-22 for PKI infrastructures with real-time domain name infrastructure public keys
https://www.garlic.com/~lynn/subpubkey.html#catch22

other posts about certificate-less public key operation
https://www.garlic.com/~lynn/subpubkey.html#certless

The bank fraud blame game

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Sun, 01 Jul 2007 08:23:00 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx <cryptography@xxxxxxxx>,
dan@xxxxxxxx, Leichter, Jerry <leichter_jerrold@xxxxxxxx>
Peter Gutmann wrote:
(The usage model is that you do the UI portion on the PC, but perform the actual transaction on the external device, which has a two-line LCD display for source and destination of transaction, amount, and purpose of the transaction. All communications enter and leave the device encrypted, with the PC acting only as a proxy. Bill of materials shouldn't be more than about $20).

The decade or so old EU FINREAD standard is along this line ... sort of modeled after point-of-sale terminal ... includes its own display and pinpad (countermeasure to keyloggers). lots of past posts mentioning EU FINREAD standard
https://www.garlic.com/~lynn/subintegrity.html#finread

the actual communications that enter and leave aren't required to be encrypted ... the communication that enter are revalidated on the display ... and the communication that exits is on the order of an x9.59 transaction
https://www.garlic.com/~lynn/x959.html#x959

that are armored with digital signature (integrity and authentication) ... misc. posts mentioning "naked" transaction metaphor
https://www.garlic.com/~lynn/subintegrity.html#payments

old aads chip strawman from nearly decade ago postulated form factor agnostic ... that could even be added to existing pda/cellphone for a lot less and communicate wirelessly.
https://www.garlic.com/~lynn/x959.html#aads

in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. part of the detailed end-to-end risk and threat analysis was not only the end-point vulnerabilities but also the large number of business processes that are giving rise to security breaches and data breaches that have frequently made the press. part of x9.59 transaction armoring was that all the transaction information could be readily exposed and still not be useful to attackers for performing fraudulent transactions. This was countermeasure to all the breaches ... regardless of whether insiders or outsiders were involved ... it was recognized that the transaction information had to be exposed in a large number of business processes. Recognizing the impossibility of eliminating all such information exposure ... the x9.59 approach was to eliminate the risk and fraud associated with such exposures (i.e. impossible to eliminate all the breaches ... so eliminate the risk and fraud associated with such breaches).

We had previously been called in to consult with small client/server startup that wanted to do payment transactions on their server
https://www.garlic.com/~lynn/subnetwork.html#gateway

and had this technology called SSL that they wanted to use. The issue in SSL was that it hid the information while moving thru the internet ... but left it totally exposed at all other points (and in fact the numerous business processes required such exposure). the x9.59 approach was then not to try and eliminate all such exposures ... but to eliminate the risks associated with all exposure of the information (in effect, armoring the transaction w/o requiring the information to be hidden as countermeasure to fraudulent transactions).

The bank fraud blame game

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Sun, 01 Jul 2007 10:06:45 -0600
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
CC: Peter Gutmann <pgut001@xxxxxxxx>,  dan@xxxxxxxx,
"Leichter, Jerry" <leichter_jerrold@xxxxxxxx>
re:
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game

slight addendas ...

1) EU finread
https://www.garlic.com/~lynn/subintegrity.html#finread
https://www.garlic.com/~lynn/subintegrity.html#assurance

one of the issues that we looked at early on in x9.59 standard ... somewhat related to the EU finread ... was what proof did the financial institution have as to the integrity of the originating end-point (for doing risk assessment purposes). With this motivation, X9.59 standard allowed for multiple digital signatures ... which could include device authentication for finread-like devices (giving some assurance as to the integrity of the originating end-point)

2) liability

there appears to be a lot more motivation for improving assurance in the online banking scenario ... say, as opposed to e-commerce and retail payments. in the e-commerce and retail payments ... financial institutions can charge off a lot of fraud to the merchants (buried in things like interchange fees). in the online banking scenario, merchants aren't part of the scene ... just leaving the consumer and the financial institutions as the responsible parties.

....

misc. recent financial news items ...

Police arrest three suspects in credit card investigation
http://www.redlandsdailyfacts.com/news/ci_6262066
ACH Fraud: Clearing House Aims To Clean House
http://www.banktechnews.com/article.html?id=200706260ZQVU91V
Mobile wallets to replace payment cards - report
http://www.finextra.com/fullstory.asp?id=17116
Debit Scam used 'parasite' pin pads
http://www.canada.com/vancouversun/story.html?id=773122d5-556f-4b50-87bc-2dc2ad205126&k=24040
Shoppers 'easy prey' for debit card fraud
http://www.canada.com/vancouversun/news/story.html?id=8e460eed-1bab-4848-9f4c-eefbaecc5ab8


...

in the early aads chip strawman (from the 90s)
https://www.garlic.com/~lynn/x959.html#aads

form-factor agnostic in user "owned" pda/cellphone were countermeasure to foreign, unfamiliar POS-terminals that possibly were compromised (i.e. paranoid consumers could have some responsible control over their own devices ... as opposed to POS-terminals at random merchants)

The bank fraud blame game

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Sun, 01 Jul 2007 13:38:14 -0600
To: Ian G <iang@xxxxxxxx>
CC: Florian Weimer <fw@xxxxxxxx>,
"Leichter, Jerry" <leichter_jerrold@xxxxxxxx>,
    dan@xxxxxxxx,  cryptography@xxxxxxxx
Ian G wrote:
Unfortunately for the banks, there is a vast body of evidence that we knew and they knew or should have known that the PC was insecure [1]. So, by fielding a system -- online commerce -- with a known weakness, they took responsibility for the fraud (from all places).

re:
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game

i.e. to large extent, the existence of the EU finread standard is proof of attempt at countermeasures to the (known) PC integrity weaknesses.

the original electronic-commerce adopted the MOTO model (mail-order/telephone-order) which placed significant responsibility on the merchant ... AND there was some presumption that physical goods were involved, shipping to a known address. SSL was used as compensating process, in theory, placing internet-order on level playing field with MOTO.

as electronic-commerce deviated more & more from the MOTO-model and related assumptions ... there were increasing risks and vulnerabilities.

one of the early problems ... in the electronic-commerce genre ... was what to do with purely internet merchants. in the standard MOTO model ... there is consumer financial institution, financially responsible for the consumer and merchant financial institution, financially responsible for merchants (with merchant interchange fees largely underwriting the whole environment).

merchant financial institutions tended to sponsor merchants where there were physical assets available for seizure ... equivalent to a month or two of credit card transactions. With every transaction passing thru the sponsoring organization (or its agent), the merchant financial institution had real-time knowledge of the outstanding exposure and risk (and was capable of cutting things off at a moments notice). However, a lot of internet merchants were setting up as purely order fulfillment organizations with little in the way of physical assets. In the early electronic commerce days there were some intense lobbying that went on with the risk management departments in merchant financial institutions.

But as mentioned in previous post ... the move to online banking ... removes the merchant completely from the picture (it is no longer the electronic commerce MOTO-model) ... leaving just the end-user and their financial institution as the responsible parties.

In the mid-90s, financial institutions looking at the internet for online, commercial banking and cash management (i.e. business equivalent to consumer online banking) were extremely conflicted ... they frequently were almost insisting on their own appliance at the business (and low-end of SOHO at least overlaps high-end of consumer online banking).

Various of the PC-based dedicated financial applications go to quite some lengths to compensate for kind of vulnerabilities typically associated with browser activity. For instance, instead of relying on a trusted third party to certify that some remote location really has a valid digital certificate, they have a trusted repository of valid financial institutions. This is somewhat the equivalent of the table of certification authority trusted third parties built into browsers ... but instead of table of certifying parties that can certify other parties ... it is table of the actual financial institutions. This has the added benefit of eliminating the horribly complex and vulnerable PKI-type of operation (an don't rely on certification of something totally unrelated to financial transaction operation, but instead rely directly on known financial transaction operation).
https://www.garlic.com/~lynn/subpubkey.html#certless

The bank fraud blame game

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Sun, 01 Jul 2007 14:49:40 -0600
To: Adam Shostack <adam@xxxxxxxx>
CC: Peter Gutmann <pgut001@xxxxxxxx>,
perry@xxxxxxxx,  cryptography@xxxxxxxx,
    dan@xxxxxxxx,  leichter_jerrold@xxxxxxxx
Adam Shostack wrote:
I'd suggest starting from the deployment, training, and help desk costs. The technology is free, getting users to use it is not. I helped several banks look at this stuff in the late 90s, when cost of a smartcard reader was order ~25, and deployment costs were estimated at $100, and help desk at $50/user/year.

re:
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game

there was a detailed analysis of the 99/00 smartcard deployments ... looking at the most common causes for problems. this was overlapped with opinion claimed to be widely held among consumer financial institutions, that it had been proven that smartcards were not practical in the consumer market segment.

then, for something of a lark, at the annual smartcard conference, i went around to most of the booths asking people at the booth if they were 1) aware that the financial industry considered smartcard not practical in the consumer market segment and 2) what was the cause of the majority of the problems.

some of the major deployments selected to be pc/sc compliant ... which at the time only supported serial port attachment ... and did not support USB plug&play. It turned out that the vast majority of smartcard deployment problems in that time-frame had to do with consumers trying to install serial port card readers, consumers that couldn't find the serial port, serial port connections that conflicted with something else, serial port IRQ conflicts, serial port driver conflicts (large number of BSOD and consumers having to re-install their systems from scratch).

there was then a very complex and intricate series of negotiations getting agreement to upgrade pc/sc to support USB plug&play (for starters, responses like why even bother since it had been proven already that smartcards weren't practical in the consumer marketplace ... ignoring for a moment that major factor in the failures was the pc/sc serial port limitations) .

There were also things like alternative packaging ... USB keyboard with built-in smartcard reader, display, and PIN-pad cut-out switch ... where keyboard incremental cost was more like $5 (but again, it required PC/SC to be upgraded to USB plug&play)

however, by that time, nearly every where you went, there were echos that it (some deployment or another) had proven that smartcards were not practical in consumer environment. Note that it wasn't just consumer limited, there were instances where commercial operations figured that it would be on the order of $500/PC to be able to handle PC/SC serial port smartcard reader attachments.

it was in the midst of these particular disasters that you also saw some of the smartcard operating system projects being canceled (again the spreading belief that smartcards were not practical in the consumer market place). All of this can be pretty much put at the doors of the institutions failing to understand some of the fundamental issues attempting to deploy serial-port PC/SC in the PC market place of the time (and/or understand that large driver behind doing the whole USB plug&play thing was the significant problem and issues attempting to deal with the serial port implementation)

some number of past posts mentioning the whole PC/SC serial port problems encountered with various attempts at smartcard deployments in the PC/consumer marketplace
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
https://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
https://www.garlic.com/~lynn/2002m.html#37 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002m.html#39 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2003n.html#35 ftp authentication via smartcard

The bank fraud blame game

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Sun, 01 Jul 2007 17:33:59 -0600
To: Florian Weimer <fw@xxxxxxxx>
CC: Ian G <iang@xxxxxxxx>,
"Leichter, Jerry" <leichter_jerrold@xxxxxxxx>,
dan@xxxxxxxx,  cryptography@xxxxxxxx


Florian Weimer wrote:
Oh really?

In Germany, early digital banking had no cryptographic protection at all. Integrity and confidentiality were inherited from the underlying phone system. There were no end-to-end digital signatures. Nothing. Just a one-time password for each transaction, but the password was not tied to the transaction in any way.

> This has the added benefit of eliminating the horribly complex
> and vulnerable PKI-type of operation

Except that there aren't any attacks on the browser PKI. That's part of the reason why the certificate prices plummeted. 8-/


re:
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game

there had been lots of home banking with PCs starting in the 80s. these were dial-up into private bank modem pools (both consumer and business cash management). one of the trade-offs looking at going to internet based operation is the enormous infrastructure savings to financial institutions.

in 1995, a presentation by one financial institutions figured that they had provided and were supporting something like 65 different modem software drivers (different modems, different operating system versions, different operating systems, different platforms, etc). transitioning to internet met that they could eliminate all of that (lots of help desk, lots of serial port issues, lots of hardware issues ... a much smaller precursor to the later smartcard PC/SC serial port disaster).

they talked about what trade-offs were with any conversion to internet, the operating system vendors and ISPs would go to a common connectivity operation, bearing the cost of all the online connectivity ... amortized over a lot of online use (not just online banking). This eliminated an enormous cost for online banking. The downside was that the security issues significantly increased.

the dedicated financial applications have some similarities to that earlier dial-up phone environment ... except they are using something akin to a controlled SSL encrypted path (tunneled thru the internet) where the client PC application has preloaded information about the financial institution's server (not needing traditional PKI trusted 3rd party certification authority to provide information about unknown parties).

now with respect to weakness of using PKI for such purposes, i've contended in the past that the image/picture authentication (was believed to) helped increase the possibility that the consumer/client was dealing with valid financial institution (that they had previously registered the image/picture with).

in that sense, it can be viewed as countermeasure to common phishing attacks ... where clients are convinced to click on some field that takes their browser to (possibly fraudulent) webserver. Given that the attacker can supply both the actual URL and the corresponding SSL digital certificate ... and majority of clients have very weak binding between websites and the corresponding URL (i.e. SSL PKI digital certificate is just checking that the webserver contacted actually corresponds to the supplied URL) .... then attackers have found an enormous PKI weak link in the current way SSL is deployed (it relies on the user to provide the binding between the webserver they think they are talking to and that webserver's URL ... where SSL PKI is then only providing the binding between a URL and a webserver).

As a result, active MITM attacks have happened ... where consumer is convinced to click on a field purported to connect them to their financial institution. The attacker actually provides a URL to the attacker's webserver, for which the attacker has a valid SSL digital certificate (i.e. the attacker is abel to prove that they are who they claim to be, w/o having to prove that they are who the victim thinks they are) ... then the attacker can transparently pass communication between the real financial institution website and the consumer (with two different SSL sessions connected at the attackers website) ... aka the (registered/selected) image/picture authentication stuff is to increase the sense of comfort a customer would have that they are actually talking to their financial institution (in view of all the SSL short-comings ... however, it doesn't actually do anything to preclude man-in-the-middle attack)

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

some specific past posts about MITM-attacks and bank site authentication
https://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private information to improve security
https://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL
https://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL ... addenda 2
https://www.garlic.com/~lynn/aadsm26.htm#56 Threatwatch: MITB spotted: MITM over SSL from within the browser
https://www.garlic.com/~lynn/2007d.html#26 Securing financial transactions a high priority for 2007

part of this harks back to when we were originally called into consult with this small client/server startup that wanted to do payments on their servers ... they had this technology called SSL they wanted to use and it has since come to be frequently called electronic commerce
https://www.garlic.com/~lynn/subnetwork.html#gateway

the end-to-end security "assumptions" at the time was that the user would type into the browser, the URL of the website they wanted to connect to. This created the trusted binding between the website the user wanted to talk to and the URL. Then the browser, using SSL, digital certificates, PKI, etc ... would validate the correspondence between the URL and the webserver that was actually contacted (two part trust operation, both required).

however, fairly early in the deployment, merchants found that using SSL for the whole shopping experience cut their thruput by 90-90 percent. as a result, they cut SSL use back to just the part for payment. Now the user can enter a URL ... and it isn't validate with SSL ... so the user can be talking to an attackers website. Then when they go to pay/checkout ... they click on a button, provided by (potential fraudulent) website. The button provides the URL for the checkout portion ... allowing an attacker to provide both the URL and an digital certificate that corresponds to that URL.

No longer is SSL being used to provide the correspondence between the webserver that the user thinks they are talking to and the webserver they are actually talking to ... the user is getting both the URL and the digital certificate off the net ... so all an attacker has to show that the URL they claim to be is the URL that they have a valid digital certificate for.

lots of past posts about SSL (and effectively SSL digital certificates turning into a "comfort" item as opposed to a real security feature)
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

For other topic drift, in the mid-90s at one of the large security conferences (in the US), one of the large German banks gave a talk on relying-party-only digital certificates ... lots of past posts mentioning RPO certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

They had realized that the X.509 identity digital certificates (from the early 90s), potentially overloaded with enormous amounts of personal information, ... represented significant privacy and liability issues. As a result, they had retrenched to RPO-certificates containing little more than an account number (or other kind of record locater) and public key ... if you actually wanted to do something ... it was necessary to read the information from the appropriate record. It wasn't just large German financial institutions that had come to this realization ... numerous financial institutions were retrenching from the x.509 identity digital certificates of the early 90s.

Note, however, examining all the business processes that would make use of RPO-certificates ... we were able to demonstrate that it was trivial to include the public key in the specified account record ... which made the associated PKI and digital certificates redundant and superfluous (since the relying party would be retrieving *all* necessary from the appropriate record).

This also significantly influenced our work on the X9.59 financial standard in the X9A10 financial standard working group (which in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments)
https://www.garlic.com/~lynn/x959.html#x959

It wasn't just that the RPO-certificates were redundant and superfluous. The typical RPO-certificates being tested in that time-frame were contributing enormous payload bloat (PKI and digital certificate payload overhead size was on the order of one hundred times larger than the typical financial transaction size). misc. past posts mentioning the enormous payload bloat of redundant and superfluous digital certificates
https://www.garlic.com/~lynn/subpubkey.html#bloat

In the same timeframe as x9a10 work on x9.59 financial standard, the X9F committee was attempting to take another approach. They had a financial standard work item for "compressed" digital certificates ... with the objective to try and get payload bloat of (the redundant and superfluous) RPO-certificates and PKI overhead bloat down to possibly only 5-10 times larger than the base financial transaction payload size.

One of their suggested approaches ... was that all fields that were common to an issuer's RPO-certificate would be eliminated ... i.e. only the fields that were unique to every RPO-certificate would be included. I had a slightly different suggestion ... instead eliminate all fields in the RPO-certificate that the financial institution already had on file for the entity. Since by definition, it could be shown that the financial institution already had all fields (if nothing else from having issued the RPO-certificate in the first place), then it would be possible to eliminate all fields, reducing an RPO-certificate to zero bytes.

So as an alternative to deploying a certificate-less public key infrastructure
https://www.garlic.com/~lynn/subpubkey.html#certless

it would be possible to deploy a fully functional PKI operation that depended on attaching zero byte digital certificates to every transaction (which would also address the enormous PKI payload bloat). some old posts discussing the enormous advantages of a PKI with zero byte digital certificates
https://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
https://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
https://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI

TPM, part 2

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: TPM, part 2
Date: Sun, 01 Jul 2007 19:53:40 -0600
To: Peter Gutmann <pgut001@xxxxxxxx>
CC: cryptography@xxxxxxxx,  leichter_jerrold@xxxxxxxx
Peter Gutmann wrote:
I have a friend who implemented a basic trusted-boot mechanism for a student project, so we have evidence of at least one use of a TPM for TC, and I know some folks at IBM Research were playing with one a few years ago, so that's at least two users so far. Anyone else?

as i've mentioned before ... we looked at somewhat similar hardware solution (but much simpler) for the original acorn (ibm/pc code name), primarily as software piracy countermeasure ... but the tamper resistant technology state of the art at the time was way too expensive ... and investigation was dropped. what was seen during the 80s were things like those specially encoded floppy disks ... that had to be inserted when you started the application ... a couple past posts/references:
https://www.garlic.com/~lynn/2006p.html#41 Device Authentication - The answer to attacks lauched using stolen passwords?
https://www.garlic.com/~lynn/aadsm27.htm#9 Enterprise Right Management vs. Traditional Encryption Tools
https://www.garlic.com/~lynn/2007m.html#20 Patents, Copyrights, Profits, Flex and Hercules

in the late 90s i would periodically chide the TPM folks about what they were doing ... and at an assurance talk i gave in the trusted computing track at intel developers forum (spring 2001), i chided the guy running the effort (was sitting in the front row) that it was nice to see that over the previous couple yrs that TPM had started to look more & more like the AADS chip strawman. his retort was something about it being because I didn't have a committee of couple hundred people helping me with (my) chip design.

misc. past posts mentioning aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads

The bank fraud blame game

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
To: Peter Gutmann <pgut001@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Mon, 02 Jul 2007 09:50:15 -0600
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
CC: adam@xxxxxxxx,  cryptography@xxxxxxxx,
    dan@xxxxxxxx,  leichter_jerrold@xxxxxxxx,  perry@xxxxxxxx
Peter Gutmann wrote:
Smart cards are part of the problem set, not the solution set - they're just an expensive and awkward distraction from solving the real problem. What I was suggesting (and have been for at least ten years :-) is a small external single-function device (no need for an OS) that can't be compromised by malware because there's no attack vector for the malware to get at it.

there is an interesting side story to this involving certification, common criteria, protection profiles, etc.

possibly the majority of the smartcard protection profiles have to do with all the problems allowing software/application to be loaded. on the other hand, you can get a common criteria evaluation done on the basic chip ... w/o any application loading ... and being able to show a much higher security level ... than might be possible with any application actually loaded.

one of the problems i ran into getting higher than eal4+ for aads chip strawman ... was since everything was built into the silicon at manufacturing time, and nothing could be subsequently loaded ... all the crypto had to also be resident in the silicon.

one of the original objectives given for the aads chip strawman was being able to do digital signature in contactless form factor within transit gate elapsed time requirements (very low power and very fast) ... which eventually fell to doing ec/dsa ... and i couldn't get an protection profile definition for ec/dsa higher than eal4+. similar chips ... w/o anything loaded had been able to get eal5+ evaluation (or better) ... but since ec/dsa was built into the chip silicon, it was only possible to get eal4+.

the other criteria for aads chip strawman was extremely aggressive cost reduction; i had joked i was taking a $500 milspec part, cost reducing by 2-3 orders of magnitude and at the same time increasing the integrity. part of the aggressive cost reduction was choosing a single function (something you have authentication via chip digital signature) that could be used in a broad range of applications ... and eliminate everything else.

misc. aads
https://www.garlic.com/~lynn/x959.html#aads

other posts in this thread:
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game

The bank fraud blame game

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Tue, 03 Jul 2007 10:29:19 -0600
To: Adam Shostack <adam@xxxxxxxx>
CC: Perry E. Metzger <perry@xxxxxxxx>,
Peter Gutmann <pgut001@xxxxxxxx>,
    cryptography@xxxxxxxx,  dan@xxxxxxxx,  leichter_jerrold@xxxxxxxx
Adam Shostack wrote:
It may be, indeed. You're going (as Lynn pointed out in another post) to be fighting an uphill battle against the last attempts. I don't think smartcards (per se) are the answer. What you really need is something like a palm pilot, with screen and input and a reasonably trustworthy OS, along with (as you say) the appropriate UI investment.

given the recognition of the serial port issues from the earlier, dial-in online banking ... providing a strong motivation to transfer responsibility for all such problems to ISPs (under the guise of moving to the internet)
https://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game

that even the transfer of a little bit of (this earlier serial port) institutional knowledge, could have avoided/mitigated some of the later smartcard reader disastrous deployments
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game

However, following some of the early YES CARD deployments
https://www.garlic.com/~lynn/subintegrity.html#yescard

it appeared to be more of a case where smartcard organizations were very narrowly focused on purely smartcard issues and ignoring everything else (probably not receptive to any input regarding serial port issues).

that aspect was somewhat highlighted in an very early presentation about circumstances surrounding the YES CARD ... and there was a somewhat uncontrolled comment from somebody in the audience do you mean to say that they managed to spend a billion dollars to prove that chips are less secure than magstripes?.

misc. old posts/threads mentioning the pc/sc serial port issue & smartcard reader deployment disasters
https://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers
https://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP
https://www.garlic.com/~lynn/2002m.html#37 Convenient and secure eCommerce using POWF
https://www.garlic.com/~lynn/2002m.html#39 Convenient and secure eCommerce using POWF

a fraud is a sale, Re: The bank fraud blame game

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: a fraud is a sale, Re: The bank fraud blame game
Date: Tue, 03 Jul 2007 10:48:48 -0600
To: Ed Gerck <edgerck@xxxxxxxx>
CC: nbohm@xxxxxxxx,  cryptography@xxxxxxxx
Ed Gerck wrote:
Yes. Today, under current practice, there's actually a strong incentive to keep existing fraud levels than to try to "scrub it out" -- fraud has become a sale:

thread from earlier this year ... when over a period of a month or so there were several releases that essentially had fraud declining by 10-15 percent simultaneously with fraud increasing by 200-300 percent.
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#61 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#62 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#19 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007m.html#65 nouns and adjectives

this followed an article pointing out that EU financial institutions had something less than 10percent of their bottom line coming from payment transaction operation ... while it was closer to 40percent for US financial institutions.
https://www.garlic.com/~lynn/2007k.html#12 IBM Unionization
https://www.garlic.com/~lynn/2007k.html#13 IBM Unionization
https://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based

and articles about interchange fee represents the single largest expense for some retail merchants
https://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems
https://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#72 Free Checking

a fraud is a sale, Re: The bank fraud blame game

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: a fraud is a sale, Re: The bank fraud blame game
Date: Wed, 04 Jul 2007 06:21:47 -0600
To: Ed Gerck <edgerck@xxxxxxxx>
CC: nbohm@xxxxxxxx,  cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game

for a little bit more background ....

signature-debit fraud has been quoted at 15 times that of pin-debit fraud ... some refs:
https://www.garlic.com/~lynn/aadsm22.htm#22 FraudWatch - Chip&Pin, a new tenner (USD10)
https://www.garlic.com/~lynn/2006e.html#21 Debit Cards HACKED now
https://www.garlic.com/~lynn/2006e.html#24 Debit Cards HACKED now
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#60 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#12 IBM Unionization

and so the merchant fees for signature-debit are like an order of magnitude more than pin-debit (i.e. more on par with credit fees)
http://www.digitaltransactions.net/newsstory.cfm?newsid=738
http://www.digitaltransactions.net/newsstory.cfm?newsid=1251

in the US, there has been some numbers that walmart accounts for 25-30 percent of all retail store transactions. several yrs ago they won a class action legal action against the payment transaction infrastructure.
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#42 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies

various refs:
http://www.classactionrefund.com/VisaInfo.html
http://www.inrevisacheckmastermoneyantitrustlitigation.com/history.php3
http://www.digitaltransactions.net/newsstory.cfm?newsid=623

other posts in the previous part of this thread:
https://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#37 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game

The bank fraud blame game

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Wed, 04 Jul 2007 10:43:49 -0600
To: ray@xxxxxxxx
CC: lucks@xxxxxxxx,  hal@xxxxxxxx,  dan@xxxxxxxx,
leichter_jerrold@xxxxxxxx,  pgut001@xxxxxxxx,
cryptography@xxxxxxxx
R. Hirschfeld wrote:
During the course of the CAFE project some commercial electronic purse systems emerged, notably Proton (from Banksys in Belgium, replicated in other counties under other names) and Mondex. These were in many ways less sophisticated than CAFE's system (which was multi-issuer, multi-currency, privacy-respecting, etc.) but had serious commercial backing. For the most part these seem to have stagnated or died. I suspect that getting them to catch on would require drastic measures such as:

we had gotten tasked to do a design and costing of mondex implementation in the states (all the transaction processing dataprocessing, sizing capacity and resources, etc) ... and looking at pricing various kinds of mondex related transactions ("super brick" from mondex international and how it flowed thru the rest of the infrastructure).

the conclusion we came up with was that nearly all the financial justification for mondex was in the float. later there were scenarios where mondex international was encouraging deployment in various countries by offering to split the float with the chartered mondex national body (and then it seemed like float offerings were starting to peculate down to financial institutions lower in the mondex hierarchy)

then along came an EU statement that mondex (and similar implementations) would only be given a grace period with regard to retaining the float (as a mechanism to underwrite start-up costs) ... but after a period of 2-3 yrs, they were then going to be required to start paying interest on balances carried in the cards. after that, much of the interest(?) seemed to evaporate.

separately there were some issues with the chip technology being used in the mondex cards.

misc. past posts mentioning mondex.
https://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop
https://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
https://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
https://www.garlic.com/~lynn/aadsm18.htm#42 Payment Application Programmers Interface (API) for IOTP
https://www.garlic.com/~lynn/aadsm20.htm#7 EMV
https://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards?
https://www.garlic.com/~lynn/aadsm23.htm#23 Payment systems - the explosion of 1995 is happening in 2006
https://www.garlic.com/~lynn/aadsm25.htm#31 On-card displays
https://www.garlic.com/~lynn/2002e.html#14 EMV cards
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002g.html#53 Are you sure about MONDEX?
https://www.garlic.com/~lynn/2002g.html#54 Are you sure about MONDEX?
https://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2005i.html#10 Revoking the Root
https://www.garlic.com/~lynn/2005v.html#1 Is Mondex secure?
https://www.garlic.com/~lynn/2007b.html#47 newbie need help (ECC and wireless)
https://www.garlic.com/~lynn/2007i.html#57 John W. Backus, 82, Fortran developer, dies

The bank fraud blame game

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: The bank fraud blame game
Date: Wed, 04 Jul 2007 13:39:51 -0600
To: ray@xxxxxxxx
CC: lucks@xxxxxxxx,  hal@xxxxxxxx,  dan@xxxxxxxx,
leichter_jerrold@xxxxxxxx,  pgut001@xxxxxxxx,
cryptography@xxxxxxxx
R. Hirschfeld wrote:
- differential pricing: electronic purse payments are potentially cheaper to process than those of debit cards because they are offline, but consumers find it more convenient to keep money in their bank account than on a smart card and will likely continue to do so as long as it costs no more. (This may become less of an issue if/when all vending machines and parking meters are on the internet anyway.)

re:
https://www.garlic.com/~lynn/aadsm27.htm#41 The bank fraud blame game

in the mid-90s, a number of US financial institutions looked at the economics of the EU chipcard electronic purses (modulo the float issue ... which could be made to work) the issue was that the (much more) expensive chips were being used to offset the significantly higher PTT costs (and/or just plain PTT availability) in Europe.

The US could deploy a magstripe authentication card for stored-value ... that did online transactions using much of the existing online point-of-sale infrastructure ... for significantly lower overall infrastructure costs than the EU chip-based offline stored value. The magstripe card basically became a something you have authentication mechanism. The primary trade-off issue was that the US telecom pricing was so much lower than in Europe (and lots of 80s & 90s design in europe was being driven by the extremely high PTT costs and/or, in some cases, lack of PTT availability).

Note, however, the internet along with various telcom and technology changes around the world have contributed to significantly changing those online/offline economic trade-off considerations.

Independent of the online/offline economic issues ... there are some fraud and security issues that could drive towards using chips for a more secure something you have authentication device.

part of this was our semi-facetious statements about taking a $500 (chip) milspec part, aggresive cost reduction by 2-3 orders of magnitude while increasing the integrity/security
https://www.garlic.com/~lynn/x959.html#aads

however, there is some lingering effects from the older high PTT costs related to chip-based architectures ... and whether there are any residual design features related to (originally) supporting offline operation.

Part of this could be seen in the YES CARD exploits ... where, transaction "business rules" were left in the chip implementation (as oppsed to the chip being purely an authentication mechanism) ... contributing to the enormous vulnerability increase
https://www.garlic.com/~lynn/subintegrity.html#yescard

For the float issue with regard to the class of US gift/stored-value cards ... they are sold as "merchant" cards ... i.e. the kind of gift & stored-value cards you see used by coffee shops, video rental, grocery stores, large department stores, etc. Possibly, in part, because they are "merchant" cards ... as opposed to "bank" cards ... the associated accounts and balances are pretty far removed from any jurisdiction that might impose payment of interest.

misc. past posts about how the large difference in telecom costs drove different solutions
https://www.garlic.com/~lynn/aepay11.htm#28 Solving the problem of micropayments
https://www.garlic.com/~lynn/aepay11.htm#70 Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aadsm16.htm#12 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm18.htm#39 Financial identity is *dangerous*? (was re: Fake companies, real money)
https://www.garlic.com/~lynn/aadsm21.htm#12 Payment Tokens
https://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
https://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market
https://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002d.html#41 Why?
https://www.garlic.com/~lynn/2002e.html#22 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2003h.html#54 Smartcards and devices
https://www.garlic.com/~lynn/2004j.html#39 Methods of payment
https://www.garlic.com/~lynn/2004j.html#43 Methods of payment
https://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards

a fraud is a sale, Re: The bank fraud blame game

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: a fraud is a sale, Re: The bank fraud blame game
Date: Mon, 09 Jul 2007 16:55:12 -0400
To: Ed Gerck <edgerck@xxxxxxxx>
CC: nbohm@xxxxxxxx,  cryptography@xxxxxxxx
re:
https://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank fraud blame game

recent item with the other side of the issue (as opposed to being able to profit when merchants have fraud)

Data Security Advanced by New Aleratec Multi-purpose DVD/CD Shredder
http://www.emedialive.com/Articles/ReadArticle.aspx?ArticleID=12940

from above:
Identity Theft and Fraud cost business $600 billion a year, according to the Association of Certified Fraud Examiners.

.. snip ...

post from earlier this spring about series of articles essentially appearing simultaneously:
https://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007

ID fraud down, except credit cards
http://www.pcadvisor.co.uk/news/index.cfm?newsid=8280
Survey: ID fraud in U.S. falls by $6.4B
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9010082&aintsrc=hm_list
Survey Indicates ID Theft May Be Diminishing
http://yro.slashdot.org/yro/07/02/01/2127224.shtml
Study: ID fraud in decline
http://www.securityfocus.com/brief/423
US ID theft losses decline
http://www.astalavista.com/?section=news&cmd=details&newsid=3376
US ID theft losses decline
http://www.theregister.com/2007/02/05/us_id_fraud_survey/

and

ID Theft Is Exploding In The U.S.
http://www.informationweek.com/news/showArticle.jhtml?articleID=198701579
ID fraud soaring across the pond
http://www.silicon.com/financialservices/0,3800010322,39166236,00.htm


Threatwatch: how much to MITM, how quickly, how much lost

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 23, 2007 10:23 PM
Subject: Threatwatch: how much to MITM, how quickly, how much lost
Blog: Financial Cryptography

https://financialcryptography.com/mt/archives/000941.html

re:
https://www.garlic.com/~lynn/aadsm27.htm#43 a fraud is a sale, Re: The bank fraud blame game
https://www.garlic.com/~lynn/2007n.html#72 Poll: oldest computer thing you still use

and

Identity theft has replaced drug dealing as No. 1 crime in the U.S. And thieves often aren't caught.
http://www.pennlive.com/news/expresstimes/index.ssf?/base/news-5/1185077364273960.xml&coll=2

Identity theft soars to top of modern crime list
http://www.gatewaynewspapers.com/signalitem/focus/84274/


Threatwatch: how much to MITM, how quickly, how much lost

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 24, 2007 08:21 PM
Subject: Threatwatch: how much to MITM, how quickly, how much lost
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#44 Threatwatch: how much to MITM, how quickly, how much lost

from posting in thread in crypto mailing list
https://www.garlic.com/~lynn/aadsm27.htm#43 a fraud is a sale, Re: The bank fraud blame game

one of the references mentioned in the above:
Data Security Advanced by New Aleratec Multi-purpose DVD/CD Shredder
http://www.emedialive.com/Articles/ReadArticle.aspx?ArticleID=12940

from above:

Identity Theft and Fraud cost business $600 billion a year, according to the Association of Certified Fraud Examiners.


... snip ...

A year or two ago i tripped across an obscure study that quoted a similar number ... this was after there was some news coverage of a talk that happened to mention cybercrime being greater

the crypto mailing list post also references a number of different news articles running somewhat concurrently earlier this spring ... one series was that id-fraud was in decline and the other series was that id-fraud was exploding.

and series of news articles from late 2005:

Cybercrime Profits Outpace Drug Trafficking
http://www.ecommercetimes.com/story/47559.html
Expert: Cyber-crime Yields More Cash than Drugs
http://www.eweek.com/article2/0,1895,1893592,00.asp
Expert: Cyber-crime Yields More Cash than Drugs

http://www.extremetech.com/article2/0,1697,1893916,00.asp
Cybercrime now outstrips drug trafficking
http://www.cw360asp.com/Articles/2005/11/29/213190/Cybercrimenowoutstripsdrugtrafficking.htm
Cybercrime 'more lucrative' than drugs
http://www.theregister.co.uk/2005/11/29/cybercrime/
Cybercrime profits exceed those of drugs, expert says
http://www.globetechnology.com/servlet/ArticleNews/TPStory/LAC/20051129/RTICKERB29-2/TPTechnology/
Cybercrime more profitable than illicit drug sales?
http://arstechnica.com/news.ars/post/20051129-5648.html

Threatwatch: how much to MITM, how quickly, how much lost

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 26, 2007 06:52 PM
Subject: Threatwatch: how much to MITM, how quickly, how much lost
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#44 Threatwatch: how much to MITM, how quickly, how much lost
https://www.garlic.com/~lynn/aadsm27.htm#45 Threatwatch: how much to MITM, how quickly, how much lost

following is quite a bit less than amount quoted a couple yrs ago ... on the other hand, this report comments that there may some incentive that leads to significant underreporting

Cybercrime Costs US Economy at Least $117B Each Year
http://www.technewsworld.com/story/58517.html
Cybercrime Costs US Economy at Least $117B Each Year
http://www.ecommercetimes.com/story/58517.html

from above:
"Whatever is reported by organizations, most of that will likely be underreported because of disincentives to report losses," he told TechNewsWorld.

Reporting remains a major challenge to fighting cybercrime, Powner noted.


... snip ...

If your CSO lacks an MBA, fire one of you

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 26, 2007 07:18 PM
Subject: If your CSO lacks an MBA, fire one of you
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000940.html

"security" isn't just limited to things like defenses and countermeasures against attacks and fraud ... security supposedly includes things like assurance, availability, correctness, etc.

there was a recent thread in mainframe discussion about the general issue of "quality" (and somewhat the related costs).
https://www.garlic.com/~lynn/2007n.html#76 PSI MIPS
https://www.garlic.com/~lynn/2007n.html#77 PSI MIPS
https://www.garlic.com/~lynn/2007n.html#79 PSI MIPS

i've mentioned before that we were called in to consult with small client/server startup that wanted to do financial transactions on their server (frequently now referred to as electronic commerce) misc. past references
https://www.garlic.com/~lynn/subnetwork.html#gateway

the startup had this technology they called SSL that they wanted to use in conjunction with the financial transactions. some misc. past references
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

and some comments about general state of domain name certification and related PKI operation
https://www.garlic.com/~lynn/subpubkey.html#catch22

however, as noted in the referenced thread (somewhat on general quality issues and related costs) ... a lot of what we did related to server financial transactions drew on having earlier done ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp

which included some very detailed vulnerability studies (which were not limited to just attack & fraud defenses and countermeasures)

If your CSO lacks an MBA, fire one of you

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 27, 2007 07:45 AM
Subject: If your CSO lacks an MBA, fire one of you
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#47 If your CSO lacks an MBA, fire one of you

the previous post and references allude to higher quality implementations costing more ... and frequently there have been direction to go for lowering costs without a whole lot of attention to what happens to the costs (and security, integrity, assurance, etc).

there was also a passing reference to mainframe operation having some feature/function that actually lower the total cost of achieving higher quality implementations.

the other place that this shows up in has to do with the effects that some of the tools and building blocks have on overall quality, security, integrity, assurance, etc.

for instance in these posts mentioning buffer overflow (and associated exploits/vulnerabilities)
https://www.garlic.com/~lynn/subintegrity.html#overflow

... there is a repeated assertion that a lot of it is due to the use of C programming language ... that implementations done in some other languages have drastically lower occurance of overflow-related exploits/vulnerabilities. for instance, these posts reference a security evaluation of multics (implemented in pli) that found no overflow exploits/vulnerabilities
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
https://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation

also, these posts mention initial mainframe tcp/ip product being implemented in vs/pascal ... which also had no buffer overflow exploits/vulnerabilities (that i know of). however there were performance issues in the initial implementation ... however i had done the rfc 1044 implementation which achieved about 25 times the thruput in about 1/20th-1/30th the pathlength (around three orders of magnitude improvement)
https://www.garlic.com/~lynn/subnetwork.html#1044

another reference to attempting to improve the assurance/integrity of the building blocks is having done a one week JAD looking at what could be done in Taligent infrastructure to significantly improve the quality of the resulting applications (taligent was an object oriented programming environment ... somewhat an outgrowth of apple's attempt at an object oriented operating system, pink)
https://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink
https://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
https://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions
https://www.garlic.com/~lynn/2005b.html#40 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005f.html#38 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005i.html#42 Development as Configuration

the original references have passing mention of it frequently taking 4-10 times the original application implementation effort to support business critical application. somewhat related is common observation that doing a "2167A" implementation takes ten times the effort as what it frequently takes to do many common implementations. similar to the taligent JAD, we looked at what software infrastructure changes would be necessary to reduce the cost of 2167A implementation from ten times to only two times. a few past posts mentioning 2167A:
https://www.garlic.com/~lynn/2001i.html#55 Computer security: The Future
https://www.garlic.com/~lynn/2002e.html#70 Computers in Science Fiction
https://www.garlic.com/~lynn/2004q.html#1 Systems software versus applications software definitions
https://www.garlic.com/~lynn/2005i.html#42 Development as Configuration
https://www.garlic.com/~lynn/2006.html#37 The new High Assurance SSL Certificates
https://www.garlic.com/~lynn/2006q.html#40 Was FORTRAN buggy?

for other random drift ... reference to giving keynote at nasa high dependability computing consortium workshop:
https://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html

If your CSO lacks an MBA, fire one of you

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 27, 2007 01:25 PM
Subject: If your CSO lacks an MBA, fire one of you
Blog: Financial Cryptography
re:
https://www.garlic.com/~lynn/aadsm27.htm#47 If your CSO lacks an MBA, fire one of you
https://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you

long ago and far away, shortly after graduation and going to work for a large computer vendor ... they hired a new CSO ... who had come from a fairly high ranking gov. position.

This was back in the days before there was much computer security and large corporations frequently hired former gov. employees who's background were various kinds of physical security; actually this continues to frequently happen and then they might have a separate CSIO position

For whatever reason, I got assigned to run around with the new CSO for several months ... imparting some information about electronic kind of security and having a little physical security details rub off.

If your CSO lacks an MBA, fire one of you

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 28, 2007 01:54 PM
Subject: If your CSO lacks an MBA, fire one of you
Blog: Financial Cryptography
i replied:
>Hey Lynn,
>What is JAD?
>
>What's a 2167A :)

joint application development .... sort of a high-powered design session ... frequently have a person specialized in facilitating meetings/results running a jad ... wiki reference:
https://en.wikipedia.org/wiki/Joint_application_development

....

here is picture of various processes ... including 2167A ... and somewhat how they are related:
http://www.stsc.hill.af.mil/crosstalk/1997/09/frameworks.asp

more detail
http://www2.umassd.edu/SWPI/DOD/MIL-STD-2167A/DOD2167A.html

wiki reference
https://en.wikipedia.org/wiki/DOD-STD-2167A


... snip ...

re:
https://www.garlic.com/~lynn/aadsm27.htm#47 If your CSO lacks an MBA, fire one of you
https://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you
https://www.garlic.com/~lynn/aadsm27.htm#49 If your CSO lacks an MBA, fire one of you

it isn't just cso ... here is a number of posts discussing a major security failure in the financial industry. it was a bunch of techies that eventually spent truely huge amounts of money on attempted wide-spread deployments that met with disastrous results. the disastrous failures of the deployments resulted in a wide-spread opinion in the financial industry that hardware tokens (for authentication and security) weren't viable in the consumer market segment.

the funny thing was that the seeds for the disastrous failures had been known in the financial industry for several years ... just in different parts of the organization i.e. for whatever reason, those responsible for the disastrous failures weren't able to draw on the institutional knowledge from earlier activities.

there is the old saying about those that don't study history are doomed to repeat the same mistakes.
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
https://www.garlic.com/~lynn/2007n.html#60 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#63 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#65 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#66 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#75 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#78 Poll: oldest computer thing you still use

now while the direct costs of the disastrous deployments were significant, the 2nd order costs are quite a bit greater ... i.e. the dampening effect on deployment of effective authentication and security infrastructures leaves open large vulnerabilities and threats
https://www.garlic.com/~lynn/aadsm27.htm#44 Threatwatch: how much to MITM, how quickly, how much lost
https://www.garlic.com/~lynn/aadsm27.htm#45 Threatwatch: how much to MITM, how quickly, how much lost
https://www.garlic.com/~lynn/aadsm27.htm#46 Threatwatch: how much to MITM, how quickly, how much lost

there may also be some x-over here with recent article on the success of failure
https://www.garlic.com/~lynn/2007h.html#29 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/aadsm26.htm#59 On cleaning up the security mess: escaping the self-perpetuating trap of Fraud?

that with fundamental systemic flaws, industries can grow up that make a long-term business out of continuous fixing and patching ... aka like that systemic flaws found in the C language programming environment mentioned earlier in this thread:
https://www.garlic.com/~lynn/subintegrity.html#overflow

or the fundamental systemic flaws in the "naked transaction" paradigm
https://www.garlic.com/~lynn/subintegrity.html#payment

disclaimers:

... as mentioned earlier, we had done detailed vulnerability and threat analysis in the 80s, as part of doing ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp

the knowledge contributed quite a bit when we were called in to consult with small client/server startup that wanted to do payments on its server (they had this technology they called SSL, and the effort is now frequently referred to as electronic commerce)
https://www.garlic.com/~lynn/subnetwork.html#gateway

then in the mid-90s, the x9a10 financial standards working group had been given requirement to preserve the integrity of the financial infrastructure for all retail payments ... there were further detailed vulnerability and threat analysis (and we were able to also draw heavily on previous experience with ha/cmp and the original electronic commerce effort)
https://www.garlic.com/~lynn/x959.html#x959

it was in this period that we spent some amount of time on design of authentication hardware token with both extremely aggressive cost reduction and security improvement. it was some of the these other deployment disasters that also had downside impact on the aads chip strawman
https://www.garlic.com/~lynn/x959.html#aads

we somewhat facetiously claimed that we were doing 2-3 order aggressive cost reduction on $500 mil-spec part ... while at the same time improving the security & integrity.

we also somewhat facetiously claimed that the per chip aggressive cost reduction and the work on person-centric hardware token paradigm could represent an overall four order of magnitude cost reduction on an extensively deployed hardware token authentication infrastructure. misc. past posts mentioning institutional-centric hardware token paradigm vis-a-vis a person-centric hardware token paradigm
https://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA)
https://www.garlic.com/~lynn/aadsm19.htm#14 To live in interesting times - open Identity systems
https://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm19.htm#47 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#41 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm22.htm#12 thoughts on one time pads
https://www.garlic.com/~lynn/aadsm24.htm#49 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm24.htm#52 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#7 Crypto to defend chip IP: snake oil or good idea?
https://www.garlic.com/~lynn/aadsm25.htm#42 Why security training is really important (and it ain't anything to do with security!)
https://www.garlic.com/~lynn/aadsm26.htm#35 Failure of PKI in messaging
https://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
https://www.garlic.com/~lynn/aadsm27.htm#23 Identity resurges as a debate topic
https://www.garlic.com/~lynn/2003e.html#22 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#31 MP cost effectiveness
https://www.garlic.com/~lynn/2004e.html#8 were dumb terminals actually so dumb???
https://www.garlic.com/~lynn/2005g.html#47 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005m.html#37 public key authentication
https://www.garlic.com/~lynn/2005p.html#6 Innovative password security
https://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
https://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
https://www.garlic.com/~lynn/2005u.html#26 RSA SecurID product
https://www.garlic.com/~lynn/2006d.html#41 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006o.html#20 Gen 2 EPC Protocol Approved as ISO 18000-6C
https://www.garlic.com/~lynn/2006p.html#32 OT - hand-held security
https://www.garlic.com/~lynn/2006q.html#3 Device Authentication - The answer to attacks lauched using stolen passwords?
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
https://www.garlic.com/~lynn/2007d.html#12 One Time Identification, a request for comments/testing
https://www.garlic.com/~lynn/2007l.html#8 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#9 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#43 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007m.html#27 nouns and adjectives
https://www.garlic.com/~lynn/2007m.html#31 nouns and adjectives

Know Your Enemy: Scott McNeally on security theater

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date:  July 28, 2007 08:32 PM
Subject: Know Your Enemy: Scott McNeally on security theater
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000942.html

grump, grump ... i have plethora of past posts on subject of confusing authentication and identification.

authentication is about making sure only the authorized entities are allowed ... frequently associated with preventing fraud and/or other kinds of bad things

identification is frequently about catching the entities responsible after something bad has happened.

we have frequently asserted that x9.59 financial standard
https://www.garlic.com/~lynn/x959.html#x959

is privacy agnostic ... providing infrastructure for strong authentication as countermeasure to fraudulent transactions ... w/o requiring identification.
https://www.garlic.com/~lynn/subpubkey.html#privacy

this is from the mid-90s and hey day of some of many privacy efforts. lots of institutions were starting to realize that the x.509 identity digital certificates represented enormous privacy and liability problems.

apparently having been convinced that digital certificates carried some magical properties ... there was retrenchment to relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

only carrying some sort of record/account locator ... where the necessary information to complete transactions was actually kept. however, we were repeatedly able to trivially demonstrate that the actual digital certificates were redundant and superfluous ... and digital signature authentication business processes would continue to work just fine if the digital certificates were totally ignored
https://www.garlic.com/~lynn/subpubkey.html#certless

To large extent, many of the identification cards efforts ... are the x.509 identity digital certificates (from the early 90s), reborn with hardware token wrappers.

and the reference in long winded post in related thread
https://financialcryptography.com/mt/archives/000940.html

... also archived here
https://www.garlic.com/~lynn/aadsm27.htm#50 If your CSO lacks an MBA, fire one of you

that includes some discussion about some past attempts at hardware token deployments.

In the mid-90s time-frame part of x9.59 work was influenced by EU-DPD which had spawned a statement that electronic payments at point-of-sale should be as anonymous as cash. This led to the observation that would include removing names from various payment (debit, credit, etc) cards ... requiring a transition away from identification to authentication.

In the x9.59 case, it was shown that appropriate gov. agencies could still follow due process and locate individuals associated with transactions ... but the authentication paradigm wouldn't require that identification was publicly brandished about as part of every transaction.

for other drift, we also were involved in co-author of x9.99 financial industry standard involving privacy ... some reference here ... since as part of the effort, did a "privacy" merged taxonomy and glossary
https://www.garlic.com/~lynn/index.html#glosnote

in a manor similar to the other merged taxonomies and glossaries

more on firing your MBA-less CSO

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: July 30, 2007 08:14 PM
Subject: more on firing your MBA-less CSO
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000943.html

note that in the naked transaction thread
https://www.garlic.com/~lynn/subintegrity.html#payment

... the discussion was that there are hundreds and thousands of places that card transaction details might leak ... including (but not limited to) past studies that possibly seventy percent of such leakages involve *insiders*. given the enormous number of leakage points, the naked transaction thread discussed armoring the actual transaction so that any leaked information became useless to crooks (i.e. the "card transaction" details could fall into the wrong hands, but they would find the information useless) ... ala what was specified for the x9.59 financial transaction standard
https://www.garlic.com/~lynn/x959.html#x959

i.e. 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
https://www.garlic.com/~lynn/subpubkey.html#x959

as to the recent disastrous reader deployment references:
https://www.garlic.com/~lynn/aadsm27.htm#49 If your CSO lacks an MBA, fire one of you
https://www.garlic.com/~lynn/aadsm27.htm#50 If your CSO lacks an MBA, fire one of you

note that there have been a efforts that aren't particularly CSO-related ... just techies ... in relatively the same time frame as the disastrous card reader deployments ... there were also some magnificent other disastrous security attempts in portions of the financial market segment.

in about the same time frame as disastrous reader deployments, there were some number of YES CARD deployments ... some discussion here
https://www.garlic.com/~lynn/subintegrity.html#yescard

the YES CARD scenario should have been evident to anybody familiar with skimming attacks (dating back at least a decade or so earlier)

also leading up to time frame of the disastrous reader deployments, there were still some lingering belief in the "magical" properties of digital certificates and misc. related pilot projects that came in at the $50mil range. the certification authority industry were making all sorts of offers to the financial community (for scale-up roll-out after the pilot stage), if the financial institution would register a public key for each account in the master file ... and then provide a certification authority a copy of that master file ... then each account record would be magically transposed into a digital certificate at only $100 a pop per annum. This appeared to be acceptable to the techy community, until executives of some of the larger institutions (i.e. 10million or more accounts) started tallying the annual payments to certification authorities and shutdown the projects.

this doesn't even need to take into the consideration that the digital certificates themselves would be redundant and superfluous ... posts about relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
and certificate-less digital signatures
https://www.garlic.com/~lynn/subpubkey.html#certless

a combination of the disastrous reader deployments, the ridiculous (projected) costs of the digital certificate (scale-up) efforts, the YES CARDS and misc. other activities ... contributed to financial insitution risk managers and executives starting to seriously question the competency of "techies" (not particularly a CSO or CSIO issue).

the aggregate effect was (also) significant damper on being able to deploy any reasonable authentication and security technologies.

misc. past posts discussing the $100/account/annum proposition (minimum cost to the financial industry $20b/annum assuming only a single account/person ... again independent of the issue of whether the digital certificates were redundant and superfluous)
https://www.garlic.com/~lynn/aepay10.htm#72 Invisible Ink, E-signatures slow to broadly catch on
https://www.garlic.com/~lynn/aadsm14.htm#29 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm16.htm#16 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
https://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
https://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
https://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm23.htm#29 JIBC April 2006 - "Security Revisionism"
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
https://www.garlic.com/~lynn/2005o.html#2 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
https://www.garlic.com/~lynn/2007h.html#27 sizeof() was: The Perfect Computer - 36 bits?
https://www.garlic.com/~lynn/2007l.html#9 John W. Backus, 82, Fortran developer, dies

Doom and Gloom spreads, security revisionism suggests "H6.5: Be an adept!"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date:  August 6, 2007 09:51 AM
Subject: Doom and Gloom spreads, security revisionism suggests "H6.5: Be an adept!"
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000947.html

way back when ... it was about designing & implementing systems/infrastructure to prevent bad things happening. some slight (nearly 40yr old) drift:
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

now we have a lot of systems/infrastructures where it is all about attempting to recognize when bad things have happened ... and the basic systems/infrastructures are effectively recognized as extremely vulnerable ... and solutions are effectively done in terms of bailing wire and chewing gum. (one might be tempted to say that things have severely regressed and there is little lore left anymore about prevention)

recent reference:
https://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you

old buffer overrun post
https://www.garlic.com/~lynn/2005d.html#55 Buffer overruns

with these references
Microsoft Researchers Target Worms, Buffer Overruns
http://www.neowin.net/comments.php?id=27321&category=main Microsoft researchers target worms, buffer overruns
http://www.infoworld.com/article/05/03/03HNmicrosoftworms_1.html
Microsoft Researchers Target Worms, Buffer Overruns
http://www.pcworld.com/news/article/0,aid,119891,00.asp

or this old post:
https://www.garlic.com/~lynn/2000.html#25 Computer of the century

with reference to discussion of how to deal with some number of C-language related coding problems .... 90% of which wouldn't happen in various other programming languages.

passing reference at a assurance panel in 2001 to comment about m'soft holding up windows 2000
https://www.garlic.com/~lynn/aadsm5.htm#asrn4

I remember in the early 80s ... where state-of-the-art had progressed to the point where work was going on ... not with regard to outsider attacks or straight-forward insider attacks (supposedly still responsible for up to 70percent of the fraud) ... but the state-of-the-art was collusion countermeasures .... i.e. organized groups of insiders attempting to bypass provisions preventing insiders from subverting the systems.

misc. past posts mentioning that early 80s security state-of-the-art focusing on insider collusion (i.e. having procedures in place for outsider attacks and the simple, straight-forward insider attacks)
https://www.garlic.com/~lynn/aadsm3.htm#kiss10 KISS for PKIX. (authentication/authorization seperation)
https://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
https://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11-> PKCS12
https://www.garlic.com/~lynn/aadsm11.htm#10 Federated Identity Management: Sorting out the possibilities
https://www.garlic.com/~lynn/aadsm12.htm#33 two questions about spki
https://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
https://www.garlic.com/~lynn/aadsm23.htm#10 PGP "master keys"
https://www.garlic.com/~lynn/aadsm24.htm#36 Interesting bit of a quote
https://www.garlic.com/~lynn/aadsm24.htm#40 Interesting bit of a quote
https://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
https://www.garlic.com/~lynn/2005g.html#37 MVS secure configuration standard
https://www.garlic.com/~lynn/2005g.html#38 MVS secure configuration standard
https://www.garlic.com/~lynn/2005k.html#1 More on garbage
https://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
https://www.garlic.com/~lynn/2006d.html#30 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006k.html#16 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#33 Password Complexity
https://www.garlic.com/~lynn/2006n.html#32 The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2007f.html#39 Silly beginner questions

Security can only be message-based?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 7, 2007 03:54 PM
Subject: Security can only be message-based?
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000949.html

i would put it slightly differently, KISS api with strongly enforced boundaries and partitioning.

message-passing tends to imply various kinds of partitioning.

however, there was a lot done in the 60s (disclaimer, i was involved) with virtual machine paradigm as a partitioning mechanism ... with message-passing between the virtual machines.

this was work at the cambridge science center ... 4th flr, 545 tech sq.
https://www.garlic.com/~lynn/subtopic.html#545tech

which traces some of its heritage back to CTSS. recent mention of upcoming 40th anniversary of (cp67, as well as 35th anniversary of vm370) product announce
https://www.garlic.com/~lynn/2007n.html#92

also reference to archeology in this recent post
https://www.garlic.com/~lynn/aadsm27.htm#47 Doom and Gloom spreads, security revision suggests "H6.5: Be an adept!"
and this reference
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

Of course, Multics on the 5th flr, also traces back to CTSS, recent post mentioning multics
https://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you

the science center was also responsible for the technology for the internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

which was larger than arpanet/internet from just about the beginning until sometime mid-85.

also gml (precursor to sgml, html, xml, etc) was invented at the science center in '69
https://www.garlic.com/~lynn/submain.html#sgml

for other historical reference .... the compare&swap instruction was invented by CAS at the science center (note that mnemonic for compare&swap instruction are charlie's initials) as part of work on fine-grain multiprocessor serialization related to cp67. With some difficulty managed to get CAS added to the 370 architecture in the early 70s ... lots of past postings on multiprocessor support and/or compare&swap instruction
https://www.garlic.com/~lynn/subtopic.html#smp

for lots & lots of historical drift ... the original sql/relational work was implemented in virtual machine (vm370) environment at SJR ... lots of past posts mentioning system/r
https://www.garlic.com/~lynn/submain.html#systemr

some amount of the AADS work drew on background
https://www.garlic.com/~lynn/x959.html#aads

having done operating concurrency/integrity with cp67 and vm370 ... but also with system/r. Also as part of doing the high-availability product
https://www.garlic.com/~lynn/subtopic.html#hacmp

we had to work out loads of failure modes ... not just security related ones ... and provide for correct operation in distributed environment. if fact, during the ha/cmp work we had coined the terms disaster survivability and geographic survivability
https://www.garlic.com/~lynn/submain.html#available

another influence was having to do the distributed lock manager for distributed scale-up operation; some old references in this series of old email
https://www.garlic.com/~lynn/lhwemail.html#medusa

as frequently mentioned ... we were later called in to consult for a small client/server startup that wanted to do payment transactions on their server ... which then required this thing called a payment gateway
https://www.garlic.com/~lynn/subnetwork.html#gateway

and two of the people that were responsible for what they were calling a commerce server had earlier worked with us on distributed database transaction scale-up ... and, in fact, were at the meeting mentioned in these posts
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/96.html#15

that whole sequence of having done mainframe multiprocessor scale-up and concurrency, database concurrency and scale-up, distributed database operation and scale-up ... and then having done the availability product before working on what has since come to be called electronic commerce ... also influenced the later work on AADS.

Microsoft asserts itself as an uber-CA

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 7, 2007 09:36 PM
Subject: Microsoft asserts itself as an uber-CA
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000945.html

another way of looking at it ... is that in some cases, the browser vendors have charged CAs quite a bit of money to get their (self-signed) certificate included in the browser.

These aren't x.509 identity digital certificates in the traditional sense ... these tend to be self-signed digital certificates ... which turn out to be a convenient packaging technique for public keys that are to be included in a trusted repository (of public keys) ... aka rather than these digital certificates being a trust mechanism ... these kinds of digital certificates are purely public key packaging mechanism ... and the act of including the public key in the (browser's) trusted repository of public keys is the trust mechanism.

Now the certification authorities (CA), who have typically paid money to have their public key included in the browser's repository of trusted public keys, ... can turn around and charge their clients money for digitally signed (trust) digital certificates (verifiable by one of the public keys included in a browser's repository of trusted public keys).

So the ability to remove a (certification authorities) public key from a browser's repository of trusted public keys ... might also be interpreted as impacting a whole economic ecosystem (since the CA's clients stop receiving benefit from having the certificates, they paid for, being accepting ... which in turn impacts the economic operation of the CA that had paid money to have their public key included in the browser's trusted public key repository).

Having the browser vendor automatically reload public keys into the browser's repository of public keys ... might be construed as the browser vendor actually maintaining the master copy of trusted public keys (which they probably have charged quite a bit of money to include a public key) ... and any specific browser's copy is purely a "local" cache. While it might superficially appear that a browser's local copy of trusted public keys is purely autonomous ... protocols implemented by the browser software could actually manage cache consistency with the vendor's master copy. In theory, not only could a cache consistency algorithm reload trusted public keys that have been deleted from the local cache ... but might also load new public keys that had never been in a local cache. Such an hypothetical cache consistency implementation could also do away with any certificate revocation kludge for certification authority public keys (we've made past claims that our repeated criticism of certificate revocation operation led to the OCSP effort).

In any case, the whole public key reload effort might possibly be a browser vendor, certification authority, CA-client economic ecosystem ... having little or nothing to do directly with PKI relying parties.

This is orthogonal to the traditional trusted 3rd party certification authority having no real business foundation ... aka the relying party typically doesn't have any sort of contractual relationship or other mechanism on which to base liability and/or recourse with regard to anything done by the certification authority.

This is somewhat highlighted by the federal PKI operation where the GSA (as agent for federal gov. relying parties) has contracts with the various approved certification authorities (creating a basis for legal reliance between the relying parties and the certifying operations). These "contracts" bridge the legal and contractual gap with regard to reliance that occurs in many of the deployed PKI operations

misc. past posts mentioning the contractual work around in the federal PKI to the typical trusted 3rd party kludge:
https://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm16.htm#16 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
https://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
https://www.garlic.com/~lynn/aadsm18.htm#7 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
https://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
https://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
https://www.garlic.com/~lynn/2007l.html#2 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#6 John W. Backus, 82, Fortran developer, dies

The Uneasy Ride on the Cryptography Bandwaggon

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 10, 2007 11:25 AM
Subject: The Uneasy Ride on the Cryptography Bandwaggon
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000955.html

Two guys credited with ecc in 1985 were Koblitz at univ. wash and Victor Miller at ykt (math dept). Coppersmith (lucifer, des) was also in the math dept at ykt.

During period that Koblitz and Miller were doing the ecc related work, i had offices in bldg. 28 (sjr) and bldg. 29 (vlsi lab) on the west coast ... but reported to ykt on the east coast ... which met x-cntry flts a couple times or more a month and interacted. i had interactions the people in the math dept (coppersmith, miller, etc) on various crypto stuff i was doing.

misc references:
http://www.iacr.org/conferences/eurocrypt2007/slides/s14t1.pdf
http://www.certicom.com/index.php?action=ecc,home
http://www.certicom.jp/index.php?action=ecc_tutorial,ecc_tut_1_0
http://searchsecurity.techtarget.com/sDefinition/0,290660,sid14_gci784941,00.html

misc. old email related to various kinds of crypto
https://www.garlic.com/~lynn/lhwemail.html#crypto

The fundamental _barrier to entry_ in the business of payment systems

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 10, 2007 11:25 AM
Subject: The fundamental _barrier to entry_ in the business of payment systems
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000948.html

one of the big infrastructure issues in the 70s was interchange and the associations. before that both the merchant and consumer had to be with the same institution. this was not just a technology interconnect problem but also contractual and legal issuef. the value-added networks to address the interconnect problem have somewhat been obsoleted with the growth of the global internet. however, the legal and contractual issues still remain.

for instance, in some countries, at least in the late 90s, and possibly still true today, required bilaterial, contractual agreements between every accepting merchant and every issuing consumer institution.

the associations allowed merchants to have (contractual) agreements with their financial institutions, consumers have (contractual) agreements with their financial institutions. then all financial institutions have contractual agreements with the associations (as opposed to every individual financial institution required to have bilaterial contract with every other financial institution) This reduced N*M problem to a N+M ... aka N are number of merchant financial institutions and M are number of consumer financial institutions (with each on the order of tens of thousands)

old posts discussing the N*M issue:
https://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand

the issue of interchange/association (or lack there-of) also reared its head in the digicash trials ... being limited to a single, common institution that served both the merchants and the consumers. disclaimer ... in the digicash liquidation ... we were called in to evaluate the patent portfolio.

On the downside of the MBA-equiped CSO

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: August 28, 2007 09:02 AM
Subject: On the downside of the MBA-equiped CSO...
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000944.html

for some unrelated historical perspective, in silicon valley, starting at least in the early 80s ... individuals with any kind of engineering or technical degree plus an MBA would command a large premium. however this was about the time that MBAs (and accountants) were starting to be blamed for ruining american business (attributed for the fanatical, total focus on quarterly numbers). this was also about the time i sponsored john boyd for some corporate briefings. he attributed much of the ruining of american business on the training that many corporate executives received as young officers in the early days of WW2. lots of past posts mentioning john boyd
https://www.garlic.com/~lynn/subboyd.html#boyd

some of the smartcard issues were that there were various special interests that viewed some part or another of the activity as profit opportunity (as opposed to purely cost issue). in a past life, we had been indoctrinated with "walking" the complete end-to-end process as part of identifying cost-saving opportunities.

as to the smartcard reader disaster, i had noted that part of this was one area of the organization not communicating to another part of the organization. the consumer smartcard reader disasters had to do with problem supporting serial port interface. this had been identified by home banking operations (from the days of serial port modems) as a major excuse to migrate home banking to the internet in the mid-90s.
https://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
https://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game
https://www.garlic.com/~lynn/2007n.html#60 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#63 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#65 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#66 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#75 Poll: oldest computer thing you still use
https://www.garlic.com/~lynn/2007n.html#78 Poll: oldest computer thing you still use

Threatwatch - more data on cost of your identity

From: Lynn Wheeler <lynn@xxxxxxxx>
Date: September 10, 2007 08:29 AM
Subject: Threatwatch - more data on cost of your identity
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000969.html

one possible scenario accounting for difference between fraud value of credit cards and identification cards is that credit cards have had a primarily online infrastructure where each use is tracked and recorded ... and can be "deactivated". identification cards have tended to be offline infrastructure where use and activity haven't tended to involve online operations with each use being tracked and recorded and there tends to not be an easy online deactivation.

in that sense the credit card would be considered only a very small feature of a more extensive online operation ... where identification cards are typically operate independent of a much more extensive infrastructure. Another view point is a credit card (as part of an online infrastructure) tends to be purely authentication and any authorization is embodied in the online infrastructure. identification cards would not only represent authentication, but in an offline paradigm, would implicitly carry the sense of authorization.

something similar can be cited for past discussion of YES CARD vulnerability
https://www.garlic.com/~lynn/subintegrity.html#yescard

and/or even PKI .... which i've repeatedly claimed had design point trade-off for the offline email operation of the early 80s and/or letters of credit/introduction from sailing ship days. the "credentials" represented a "better than nothing" solution in a purely offline environment where the relying party had access to no other information regarding the other party (first time interaction with complete stranger) that they were dealing with. Given any online infrastructure and/or any sort of timely interaction with responsible authority, the "better than nothing" solution (designed for the offline environment) becomes a very poor substitute (tended to migrate to purely no-value operations).

lots of past posts about mentioning "offline solutions" becoming limited to no-value applications when higher quality "online solutions" are available as an alternative
https://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III
https://www.garlic.com/~lynn/aadsm12.htm#26 I-D ACTION:draft-ietf-pkix-usergroup-01.txt
https://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication
https://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
https://www.garlic.com/~lynn/aadsm16.htm#22 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
https://www.garlic.com/~lynn/aadsm19.htm#8 GeoTrust says existing PKI practices are worthless
https://www.garlic.com/~lynn/aadsm20.htm#33 How many wrongs do you need to make a right?
https://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on high-assurance certificates
https://www.garlic.com/~lynn/aadsm21.htm#36 browser vendors and CAs agreeing on high-assurance certificates
https://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
https://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
https://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL ... addenda
https://www.garlic.com/~lynn/aadsm26.htm#34 Failure of PKI in messaging
https://www.garlic.com/~lynn/aadsm26.htm#41 PKI: The terrorists' secret weapon (part II)
https://www.garlic.com/~lynn/aadsm27.htm#23 Identity resurges as a debate topic
https://www.garlic.com/~lynn/aadsm27.htm#26 A crazy thought?
https://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
https://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card?
https://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government
https://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
https://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003l.html#33 RSA vs AES
https://www.garlic.com/~lynn/2004b.html#25 Who is the most likely to use PK?
https://www.garlic.com/~lynn/2004b.html#52 The SOB that helped IT jobs move to India is dead!
https://www.garlic.com/~lynn/2004e.html#20 Soft signatures
https://www.garlic.com/~lynn/2004j.html#2 Authenticated Public Key Exchange without Digital Certificates?
https://www.garlic.com/~lynn/2005e.html#62 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
https://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#13 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005i.html#24 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005k.html#29 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#11 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#21 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#25 PKI Crypto and VSAM RLS
https://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
https://www.garlic.com/~lynn/2005l.html#33 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
https://www.garlic.com/~lynn/2005t.html#0 TTP and KCM
https://www.garlic.com/~lynn/2006c.html#16 X.509 and ssh
https://www.garlic.com/~lynn/2006c.html#39 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
https://www.garlic.com/~lynn/2006f.html#35 X.509 and ssh
https://www.garlic.com/~lynn/2006h.html#28 confidence in CA
https://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation
https://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
https://www.garlic.com/~lynn/2007g.html#30 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#22 sizeof() was: The Perfect Computer - 36 bits?

Retailers try to push data responsibilities back to banks

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Retailers try to push data responsibilities back to banks
Date: Fri, 05 Oct 2007 18:13:36 -0400
To: cryptography@xxxxxxxx
some number of other recent notes on the subject:

Customer Service: Consumer Confidence at Stake in Retail, Credit Card Industry Clash
http://www.ecommercetimes.com/story/59670.html
Retailer PCI Rebellion: 'No More Storing Credit Card Numbers'
http://www.darkreading.com/document.asp?doc_id=135602
Retailers Fighting To No Longer Store Credit Data
http://it.slashdot.org/it/07/10/05/192250.shtml
Retail group takes a swipe at PCI
http://www.infoworld.com/article/07/10/05/Retail-group-takes-a-swipe-at-PCI_1.html
Retailers Challenge the Networks' Card-Data Storage Requirements
http://www.digitaltransactions.net/newsstory.cfm?newsid=1536
NRF to Credit Card Companies: Stop Forcing Retailers to Store Credit Card Data
http://www.nrf.com/modules.php?name=News&op=viewlive&sp_id=380
Retail group takes a swipe at PCI, puts card companies 'on notice'
http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyName=security&articleId=9040958&taxonomyId=17
Rethinking the Assumptions Behind PCI-DSS
http://www.paymentsnews.com/2007/10/rethinking-the-.html
PCI Is Here: Keeping the barbarians outside the cyber gates
http://www.practicalecommerce.com/articles/580/Caveat-Vendor-PCI-Is-Here/
Retailers, Credit Card Industry Clash
http://www.physorg.com/news111253284.html

....

we had been called in to consult with this small client/server startup that wanted to do payment transactions. this required some amount of translating technology into business critical dataprocessing ... which has somewhat come to be referred to as "electronic commerce". This including technology invention that they called SSL ... and among other things we had to do some detailed audits of these supporting infrastructures that were calling themselves certification authorities ... various past posts on the subject
https://www.garlic.com/~lynn/subnetwork.html#gateway

in the mid-90s we got involved in the x9a10 financial standard working group that had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. we drew on our experience having previously done "electronic commerce" as well as some detailed vulnerability studies and threat models. having been given the requirement for all retail payments ... we had to look at a standard that was lightweight enuf that could be easily deployed in both point-of-sale as well as internet environments ... and provide end-to-end security and integrity with countermeasures for both "data-in-flight" vulnerabilities (aka transaction transmission) as well as "data-at-rest" vulnerabilities (aka transaction logs and databases). part of the issue was some studies that claimed as much as 70 percent of ("data-in-flight" and "data-at-rest") compromises involved "insiders" (aka countermeasures had to recognize that majority of compromises possibly involved individuals with legitimate access to the information).

the resulting financial standard was x9.59
https://www.garlic.com/~lynn/x959.html#x959

the x9.59 approach was to eliminate fraudulent transactions resulting evesdropping and data breach compromises ... aka it didn't eliminate evesdropping and data breach compromises ... but it eliminated the ability of attackers (insiders or outsiders) to use the information that they had obtained for purposes of doing fraudulent transactions.

Linus: Security is "people wanking around with their opinions"

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Linus: Security is "people wanking around with their opinions"
Date: Sun, 07 Oct 2007 13:20:21 -0400
To: cryptography@xxxxxxxx <cryptography@xxxxxxxx>
Peter Gutmann wrote:
For people who don't read LKML (or get interesting bits forwarded to them), there's a wonderful quote by Linus Torvalds about the difference between OS scheduler design and security design:

"Schedulers can be objectively tested. There's this thing called 'performance', that can generally be quantified on a load basis."

"Yes, you can have crazy ideas in both schedulers and security. Yes, you can simplify both for a particular load. Yes, you can make mistakes in both. But the *discussion* on security seems to never get down to real numbers. So the difference between them is simple: one is 'hard science'. The other one is 'people wanking around with their opinions'."


http://kerneltrap.org/mailarchive/linux-kernel/2007/10/1/326534


most schedulers tend to be relatively static ... tended to have repeatably, predictable response. one of the things that i worked on as an undergraduate in the 60s ... was dynamic, adaptive, resource management and being able to schedule to the bottlneck, dynamically (which later influenced some of my opinions on adaptive security infrastructures).
https://www.garlic.com/~lynn/subtopic.html#fairshare

some of the work was released in products while i was still an undergraduate ... and then dropped ... nearly a decade later, i was offered opportunity to reship dynamic adaptive resource management infrastructure. as part of that effort, a automated, adaptive benchmarking infrastructure was built ... and in the final sequence, 2000 benchmarks were involved, taking three months elapsed time ... as part of both calibrating and validating the resource management capability across a broad range of workloads and configurations. part of the automated, adaptive benchmarking controls included a sophisticated system and performance modeling implemented in APL ... which would evaluate configuration and workloads tested to date, along with the resulting thruput and performance against thruput and performance predicated by the models ... as part of specifying the next workload/configuration combination to be test
https://www.garlic.com/~lynn/submain.html#benchmark

most of this was all done in a system infrastructure that was also considered extremely secure ... the there were at least as many system infrastructure issues related to security as there were related to thruput and performance.

an old reference related to the infrastructure and security
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

some of the claims in this patent portfolio ... while primarily oriented around authentication ... does stray into parameterised, adaptable security operation within an overall, consistent security infrastructure
https://www.garlic.com/~lynn/aadssummary.htm

for this 40+ plus year old technology ... which is seeing somewhat of a resurgence ... both for addressing resource management as well as for addressing security issues.

misc. recent posts mentioning resurgence of 40+ year old technology
https://www.garlic.com/~lynn/2007.html#39 Just another example of mainframe costs
https://www.garlic.com/~lynn/2007b.html#11 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007b.html#21 history question
https://www.garlic.com/~lynn/2007b.html#23 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#26 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#28 What is "command reject" trying to tell me?
https://www.garlic.com/~lynn/2007e.html#20 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007e.html#63 FBA rant
https://www.garlic.com/~lynn/2007f.html#33 Historical curiosity question
https://www.garlic.com/~lynn/2007h.html#2 The Mainframe in 10 Years
https://www.garlic.com/~lynn/2007h.html#23 MIPS and RISC
https://www.garlic.com/~lynn/2007i.html#14 when was MMU virtualization first considered practical?
https://www.garlic.com/~lynn/2007i.html#15 when was MMU virtualization first considered practical?
https://www.garlic.com/~lynn/2007i.html#16 when was MMU virtualization first considered practical?
https://www.garlic.com/~lynn/2007k.html#47 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#48 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#50 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#52 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#54 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#59 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#15 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#23 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#63 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007l.html#65 mainframe = superserver
https://www.garlic.com/~lynn/2007m.html#64 Operating systems are old and busted
https://www.garlic.com/~lynn/2007n.html#27 What if phone company had developed Internet?
https://www.garlic.com/~lynn/2007o.html#1 Hypervisors May Replace Operating Systems As King Of The Data Center
https://www.garlic.com/~lynn/2007o.html#7 Hypervisors May Replace Operating Systems As King Of The Data Center
https://www.garlic.com/~lynn/2007o.html#9 Hypervisors May Replace Operating Systems As King Of The Data Center
https://www.garlic.com/~lynn/2007p.html#7 what does xp do when system is copying
https://www.garlic.com/~lynn/2007p.html#28 Newsweek article--baby boomers and computers
https://www.garlic.com/~lynn/2007q.html#3 Virtualization: Don't Ask, Don't Tell

Fingerprint Firefox Plugin?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Fingerprint Firefox Plugin?
Date: Wed, 24 Oct 2007 14:57:32 -0400
To: cryptography@xxxxxxxx
zooko wrote:
Suppose you did have a convenient way to display the SSL certificate for every site whenever you loaded a page from the site. You probably wouldn't want to memorize all the certificates for the secure sites that you care about, so you might instead write some notes on a piece of paper next to your computer, for example writing down an SSL certificate and then next to it writing "bank", and then writing down another one and then next to it writing "mail", and so on.

Then, whenever you load a page, you would look at the SSL certificate that is linked to that page and glance at your notepad to see which description it maps to. If you are looking at a random web site that you've never seen before, and the certificate doesn't appear on your notes, then no big deal. If you are looking at a page that appears to belong to your bank, and the certificate that came with that page doesn't appear on your notes, then this is a big red flag! Likewise, if you are looking at a page that appears to belong to your bank, and the certificate appears on your notes, but the note next to it doesn't say "bank", then this is a red flag, too! For example, it might be the certificate of your mail service, which appears on your paper along with the note "mail". Or it might just be a certificate that appears on your paper along with the note "joke site from Harry".

Note that a system which classified certificates into "trusted" or "untrusted" categories might give you the green flag even when a certificate that you trust to serve up good jokes is serving up something that appears to be your bank account.

So, the thing about writing down certificates and mapping them to short hand-written notes is what the Pet Name Toolbar automates for you:
https://addons.mozilla.org/en-US/firefox/addon/957


the design point for certificates was first time communication between total strangers (aka the letters of credit/introduction from sailing ship days).

certificates have also somewhat tried moving into no-value market segment for relying parties that had no (and/or couldn't cost justify) mechanism for recording information about other parties they were dealing with.

by comparison pgp had assumed some mechanism for relying parties being able to record information about the parties that they had dealings with. huge number of infrastructures have had well entrenched infrastructures for recording information about parties that they dealt with ... it just has been that the authentication related information (for these infrastructures) have tended to be shared-secrets. many of these infrastructures could have been upgraded from shared-secrets to public key ... w/o having any impact on the business and/or trust models ... and furthermore by the very nature of the existing infrastructures, the paradigm behind digital certificates wasn't applicable (i.e. digital certificates being totally redundant and superfluous).

recent thread/posting about it being much more natural for simple upgrade of kerberos infrastructure from shared-secrets to public key ... w/o the exorbitant additional overhead and processing introduced by digital certificates.
https://www.garlic.com/~lynn/2007q.html#2 Windows Live vs Kerberos
https://www.garlic.com/~lynn/2007q.html#5 Windows Live vs Kerberos

when we were called in to consult with this small client/server startup that wanted to do payment transactions on their server ... since then somewhat has come to be called electronic commerce
https://www.garlic.com/~lynn/subnetwork.html#gateway

one of the technologies they had invented was SSL ... and we had to do some work on applying SSL to real business processes and also do some end-to-end audits of the whole series of operations ... including these things that we calling themselves certification authorities

one of the things that undermined original assumptions applying SSL to business processes was the whole "click" paradigm ... discussed in more detail in this recent post
https://www.garlic.com/~lynn/2007q.html#30

and the assumptions about SSL as countermeasure and the related threat models.

another aspect of SSL, certification authorities, digital certificates was the whole issue behind what is met by certification process ... and what certifications were represented by digital certificates.

during the initial decade or so of electronic commerce something over 70 percent of the transactions were done by less than 100 websites (activity is highly skewed) These websites were both well known and also carried a lot of repeat business ... invalidating one of the original/primary justifications for having digital certificates. so a very few websites did majority of transactions and didn't need certification. by comparison, the vast majority of websites were only doing a very, very few electronic transactions (especially those involving large percentage of first interaction between complete strangers) ... and couldn't cost justify expensive certification process

the other issue was that (all) merchants were already paying a fairly hefty "interchange fee" that acted as a form of warranty/insurance to cover their client/consumers (actually proportional to the value of the operations). by comparison, the certification authorities were providing almost no added value ... so except for pure hype ... there was no real reason for spending money for additional certification (at least from the standpoint of electronic commerce) ... which somewhat gave rise to the thread about "merchant comfort certificates" in some of the older ssl domain name certificate postings
https://www.garlic.com/~lynn/subpubkey.html#sslcert

a combination of these factors continued to push PKIs, certification authorities, and digital certificates more and more into the no-value market segment.

Oddly good news week: Google announces a Caps library for Javascript

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 11, 2007 11:03 AM
Subject: Oddly good news week: Google announces a Caps library for Javascript
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000984.html

some capability based trivia ... repeated here
https://www.garlic.com/~lynn/2007s.html#17

some earlier work on capability based infrastructure was the Gnosis done starting in the 70s by Tymshare. Tymshare had a vm370-based commercial, online timesharing system
https://www.garlic.com/~lynn/submain.html#timeshare

When Tymshare was bought by M/D, Gnosis was spun off as KeyKOS (disclaimer, I was brought in to audit Gnosis as part of the spin-off) Other trivia, M/D sold off Tymshare's TYMNET to B/T.

KeyKOS Documentation webpage
http://www.agorics.com/Library/keykosindex.html

other efforts that grew out of KeyKOS:

EROS: The Extremely Reliable Operating System
http://www.eros-os.org/

CapROS: The Capability-based Reliable Operating System
http://www.capros.org/

which has this reference back to KeyKOS
http://cap-lore.com/CapTheory/upenn/

The Coyotos Secure Operating System
http://www.coyotos.org/

from Coyotos history page ...
Coyotos is the successor to the EROS system, which is in turn the successor to the KeyKOS system. Since the system inherits 30 years of prior research and development history, it seems appropriate to briefly describe some of that history and the prople who contributed to it.

... snip ...

more from Coyotos history page ...
My own contact with this work came in 1990. As a co-founder of HaL computer systems, I became involved in evaluating various operating system platforms for use by HaL. In 1990, UNIX robustness wasn't great, and we hoped to find something that would be largely operator free and highly robust. Key Logic made a presentation to us about KeyKOS. For reasons that were largely political, HaL decided not to gamble on KeyKOS, but I became convinced that KeyKOS offered something worthwhile.

... snip ...

for other trivia, the "H" in "HaL" had been head of the austin workstation division (in an earlier life, for a time, I had been his only direct report) and the "L" had come from SUN.

there use to be a joke in the valley that there were only 200 people in the business ... they kept moving around, so it just appeared like there were more.

How to crack RSA

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: November 19, 2007 06:46 PM
Subject: How to crack RSA
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000985.html

could claim that complexity of PC software & hardware was one of the motivations behind EU finread terminal. One might also claim that this is another instance of the sporadic reoccurring security refrain about KISS

... and other recent refs:
Adding math to list of security threats (repeat from yesterday)
http://www.news.com/Adding-math-to-list-of-security-threats/2100-7349_3-6219153.html
Microprocessor math bugs pose security risk, warns cryptographer
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9047899
Cryptography Expert Sounds Alarm At Possible Math Hack
http://it.slashdot.org/article.pl?sid=07/11/19/0240210

MITM spotted in Tor

Refed: **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: December 15, 2007 11:05 AM
Subject: MITM spotted in Tor
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000987.html

for topic drift ... i mention here
https://www.garlic.com/~lynn/2007u.html#74

in a thread about using on-screen visual keyboards (CAPTHAs obscured)
https://www.garlic.com/~lynn/2007u.html#66

and mouse clicks as countermeasure to PC virus/trojans capturing online banking userid/passwords.

this is PC virus/trojan that waits until the session has been initiated ... and then executes fraudulent transactions w/o the person's knowledge

New Trojan Attacks Clients At Four Worldwide Banks
http://www.crn.com/security/204803106
Sophisticated Trojan loots business bank accounts
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9053018
Botnet-controlled Trojan robbing online bank customers
http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html

the original thread had drifted into topic that the threats/vulnerabilities had been well-studied and understood by at least the mid-90s ... along with the current spate of kneejerk, simple-minded, point solutions for each individual exploit that appears, rather than addressing underlying infrastructure weaknesses.

in the case of the online banking visual keyboard scenario ... it is obviously a countermeasure to compromised PC ... then where does it say that a compromised PC will only be limited to keylogging.

one could claim that the original SSL design (before the mid-90s) was countermeasure to hostile environment ... not only did the session have to be authenticated ... but everything related to the session had to also be armored.

if the environment is really hostile, then it is much better going to individual armored transaction instead of assuming that everything within a session boundary is secure ... somewhat discussed in old thread here last summer on naked transactions
https://www.garlic.com/~lynn/subintegrity.html#payments

comments about the culture of kneejerk simple-minded point-solution reaction to exploits
https://www.garlic.com/~lynn/2007e.html#12 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007i.html#66 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#67 open source voting
https://www.garlic.com/~lynn/2007k.html#55 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series
https://www.garlic.com/~lynn/2007u.html#53 folklore indeed
https://www.garlic.com/~lynn/2007u.html#55 folklore indeed
https://www.garlic.com/~lynn/2007u.html#57 folklore indeed
https://www.garlic.com/~lynn/2007u.html#62 folklore indeed
https://www.garlic.com/~lynn/2007u.html#63 folklore indeed
https://www.garlic.com/~lynn/2007u.html#67 folklore indeed
https://www.garlic.com/~lynn/2007u.html#68 folklore indeed

2007: year in review

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler <lynn@xxxxxxxx>
Date: December 22, 2007 04:03 PM
Subject: 2007: year in review
Blog: Financial Cryptography
re:
https://financialcryptography.com/mt/archives/000988.html

my two bits on some of the subjects

part of the payment issue is whether it is a transaction business or a risk management business.

if it is a transaction business ... then one might expect lots of efforts to make it more efficient and less risky.

if it is a risk management business ... then it might be construed that if all risk were to be eliminated ... there wouldn't be much to manage anymore.

for more than a decade there has been predictions that telcos would move in and take over the payment transaction business ... because they are already extremely efficient at managing call record transactions. there has been numerous claims that has yet to happen because telcos haven't figured out how to do the risk management end better.

some recent posts related to pdas/cellphones moving into payment transactions
https://www.garlic.com/~lynn/2007u.html#11 Public Computers
https://www.garlic.com/~lynn/2007u.html#47 folklore indeed
https://www.garlic.com/~lynn/2007v.html#37 Apple files patent for WGA-style anti-piracy tech

and for some cybercrime issues ... recent post
https://www.garlic.com/~lynn/2007v.html#35 Inside a Modern Malware Distribution System

The referenced modern malware articles make mention of the "new, 40+ yr old" technology ... however, my first exposure wasn't until the last week of jan68 as an undergraduate (a few weeks short of 40yrs). However, over the next two years ... as an undergraduate at the univ, I significantly redesigned and rewrote much of the original kernel.

The malware article is also somewhat related to the virus/trojan attacks on online banking systems ... which (with a little topic drift) raised in this post:
https://www.garlic.com/~lynn/aadsm27.htm#65 MITM spotted in Tor

there have been several ongoing themes that the "new 40+ yr old" technology will be the saving solution to all sorts of current computing ills (and whether or not 2008 will be the year of virtual machines).

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