December 30, 2005
GP4.3 - Growth and Fraud - Case #3 - Phishing
We would be remiss if we didn't also measure the theory of GP (GP1, GP2, GP3) against that old hobby horse, phishing.
When ecommerce burst on the scene as an adjunct to browsing, it pretty quickly emerged as "taking credit card orders over the net." This took off fairly easily as the FORM in HTML allowed ready collection of these data, and many existing credit card merchants simply shipped as if the new orders were MOTO - mail-order/telephone-order ones.
There were a few niggles around though. Security was thought to be a bit loose, as all these credit cards were flashing around on the open net. Compare this to the existing usage where credit cards were handed over to waiters and waitresses for copying back at the counter, or where orders taken over telephone resulted in goods generally being shipped to billing addresses, and it was either scary or not scary, depending on how closely you really understood the cycle. Nobody ever showed that credit cards were being snooped on the net, although telnet passwords were being scarfed up in large numbers (a threat that led separately to the development of hyper-successful SSH) so we can see here the seeds of a GP-problem.
Obviously a little crypto would have helped, and SSL in its first version ("v1") was duly floated to the crypto community sometime in 1994. All things being equal, this would have been acceptable to deal with the potential of fraud, but not all things were equal. In fact, so many things were not equal that this minor case has become what amounts to a major history lesson.
In order to understand SSL it is necessary then to digress and understand the environment of the times. I present this as forces, a sort of institutional approach from economics (c.f., Michael Porter's Five Forces analysis). Here's the list of forces that were pushing around in 1994:
- Netscape's stellar growth, capped by the dotcom fairy story of their IPO, had put Netscape firmly in the driver's seat of ecommerce. Unfortunately, they couldn't sell their flagship product because they had set a price tag of $50 for the browser but nicely left it free for personal use or somesuch. (As events were to show, Microsoft simply boxed them in by shipping their browser for free. Only Microsoft could afford to win that battle.) Force: Netscape needed big friends, big products, big revenues and something to spend its IPO cash on. Result: the pressure was on the ecommerce division to save Netscape's bacon.
- Porn! Insiders report that fully half of early SSL use was by adult sites which needed to reduce the risks of delivering the product to the wrong party. Paying for certs or secured servers was chicken feed compared to being shown to deliver to the wrong "customer." However, what they didn't want was the load that ground their servers into the dust - megabyte images being far different animals to kilobyte credit card transfers. Hence, cue in some early hard engineering questions: load balancing, page caching, proxy servers, page pre-loading from customers who's interest in security was unusual and unpredicted.
- Fear and Loathing and the Payments Industry. The credit card companies were scared witless by the arisal of new payment companies like First Virtual (a sort of forerunner to PayPal) and before them, DigiCash, and lobbied to anyone who would listen to get some 'protection' for ecommerce. One idea that they liked was the certificate, that some had mused on as being the "missing link" in the security of SSL. Better yet, those that controlled lots of merchants (MCI and AT&T in this case) could envisage delivering the certificates to the merchants, and leaving the outsiders to fend for themselves; in other words, a classic barrier to entry. But it also appealed to Netscape because pushing certificates not only boosted sales of their secure server, it maintained their control over the protocol and found them some great new friends. Briefly.
- The crypto wars! The protagonists were the United States government in the person of Loius Freeh on the one hand and the network libertarians on the other. Although the USG was prepared to compromise on weak crypto which would have been fine for ecommerce, this wasn't good enough for the cypherpunks. Nothing short of complete freedom to implement super-strong crypto against any threat for any application was anything short of acceptable. As a side-effect to their religious war against "national technical means," any merchant who implemented anything short of 100% absolutely secure no risk guaranteed and certified crypto was hit by the indiscriminate pogrom of the free crypto crowd; the result of this "all or nothing" security approach was more often nothing than all.
- Hence another short footnote in the history of ecommerce arrived in the form of SSL being required to run at full crypto strength against the man who wasn't in the middle and against Eve who wasn't listening. Unfortunately, the machines of the time were not strong enough to push through sessions fast enough. Inevitably, as nothing short of full strength was adequate, and certs and triple DES were dimming the lights of ecommerceville by about 80-90%, the security space again split into SSL-mode for collecting credit cards and non-SSL mode for the rest. This made security itself inordinately difficult, as in classical military terms, there was now a gap between security models through which to attack, and security itself was now firewalled off from the main shopping process.
- The US Department of Defense's "COTS" dream. In the 90s, the DoD procurement monolith took on a new mission. In brief, they decided to offset their R&D costs onto general society, and move to purchasing commercial off-the-shelf equipment, albeit directed towards government needs. The unwritten offer given to suppliers like Netscape was to sell DoD standard COTS software, split off portions of the revenue stream at appropriate points to fund government-specific development, and then sell DoD "COTS" with additional new "GOTS" features. Recalling that the US government was the single largest source of Netscape revenues, this was no small offer!
- The NSA's PKI dream. The American spook community decided to bet the farm on PKI as a way to slip into place a crypto regime dependent on a pre-rigged infrastructure. In perhaps following the COTS dream of their peers over at DoD, NSA pushed procurement into the direction of requiring and acquiring large PKI structures and they pushed certain suppliers - you know who I mean - into valuable PKI nodes and roles so as to make sure the(ir) infrastructure was in place. The theory was that this would then explode into life, we'd all "get PKI" religiously and then find ourselves hooked.
- The DoJ's non-repudiation dream. Some legal people (and not a few techies) believed that a digital signature was in some ways analogous to a human signature. They reasoned that if they could get the non-repudiation aspects slipped into the Internet, they'd be able to control and prosecute the criminals to come. This meant laws, structure, authorities, and above all, control.
- Identity Solves Every Security Problem. Once people realised that the certificate was like an identity, business plans bloomed like a thousand flowers based on the right to sell these identities back to their owners. Billion dollar cash flows based on the ability to sell a $100 cert to 100 million Americans floated around Wall Street. We say in (real) warfare that no plan of battle survives the first shot, etc etc, and in relatively short order, the certificate authority space was turned upside down by competitors diving in and demanding access. Netscape lost control of the space, and made all CAs equivalent so it wasn't seen to favour anyone. Inevitably, this reduced the security of the system to where certificates acquired popup-avoidance status, because there was no differentiation and certificates became a bottom-feeding business.
- The patent wars! RSADSI and Cylink were engaged in battle over public key crypto standards. Also sparring was NIST with DSA and that Canadian company with EC. Ultimately won by RSA, this also saw a whole bunch of weird and wonderful licensing agreements forced on customers. No points for guessing what features were withheld in the licences offered to which customers!
fig 8. the Battle for Ecommerce
Heady stuff for conspiracy theorists! Now, the beauty of the above forces is that they don't all have to be true even though I believe them to be fair if one-sided representations. Sufficient of these forces still sum to a statistically relevant picture. We can reach the conclusions we need, so let's go there right now.
In the face of all these pressures, Netscape found itself adding certificate-based protection with a new upgraded form of SSL called v2. (Even SSL v2 was a little loose, so they quickly hired an external consultant to come in and do v3, although that form of SSL still hasn't properly deployed in your default secure sessions as yet, so it must have been OK to secure ecommerce with v2!)
The end result was the balkanisation of the Internet's security space. Various large and famous companies carved up the space amongst them and created the CA structure that we know today. Certificates went from full-PKI-wholesome-trust mode to popup-avoidance certificate manufacturing mode in the blink of a venture capitalist's eye. Verisign made out like bandits on the stock market. The USG chipped in with some worry about enemies of the state, and forced a mishmash of cipher suites and options and above all, the certificates that a dozen agencies put so much store by. The cypherpunks added their "all or nothing" politics to the mix and created the "all and nothing" nightmare. Netscape themselves were soon embroiled in a bid for survival as Microsoft defeated them on their own ground and went on to all but own ecommerce space. And out in ecommerceville itself, they ruined the security by breaking the model down the center.
So what was all that about, in summary form? SSL v1 was put in place for a predicted, but so far unvalidated threat. The lack of focus on a clear validated threat left the space vulnerable to capture - and SSL v2 duly became the battle ground of many, none of whom had much concern about security of the browser users' sessions but were quite willing to use it as a cassus belli in the war against someone or other.
The question that I often pondered on was why certificates were added to SSL. From a technical pov, they are too expensive for the mission, too heavy. Now that I've investigated the forces and listed them out, I can see the error of my ways - obviously this had nothing to do with security, and the question is best off couched as "how could Netscape have possibly avoided putting a certificate-based PKI into the security protocol?" And that's the conclusion we need: there is no way they could have avoided it. The forces were just too strong.
Back to security. A little-known small-time fraud turned up with the name of phishing. Originally, this was a very crude and old claims scam on AOL, where the A.O.Lusers were sold some bogus product and had their credit cards re-used elsewhere. By the time AOL had been all phished out, the model was well understood and well tested, so it was natural to start somewhere else.
fig 9. the Battle of Online Banking
Fast forward to the new millenium, and that somewhere else was online payment systems and banks. I.e., where the money is. The first known phishing attack on a financial operator was June 2001 against e-gold. Delivered using spam techniques, users were tricked into entering their passwords into near-enough websites. And it was here that the browser security model was first challenged and failed within moments. The one thing that the certificate was supposed to do was tell the user that they were on the right site, plus or minus some details. But by the time the attackers arrived, the security model had been so abused by other agendas that it wasn't capable of putting up a fight against a real criminal.
Worse, the huge infrastructure that had been built up - crypto libraries, protocol libraries, browser manufacturers, web server manufacturers, standards committees, certificate authorities, auditors, audit standards models, digital signature laws, PKI rollouts and a cast of a thousand onlookers - proved itself simply incapable of accepting the threat for what it was - a successful attack on the browser's security model.
We're still there - working with a security model that was envisaged as a nice quick and dirty fix for credit cards in the first instance, in the second instance squabbled over by a bunch of disparate interests, and in the third instance broken like a child's toy sword the day after Christmas when the first bully turned up and wacked it with a stick. Worse, in the fourth instance, phishing has invested its proceeds and diversified into the trojan / malware and data breach spaces so any fixes delivered are not going to stem the tide of red ink losses.
It might be hard to tell when GP was reached in ecommerce. But the real underlying conclusion to draw from this case is this: do not put the security model in place too early! In the case of phishing by the time the model was needed, it was incapable of protecting and of adjusting against the threat. The cost to this impatience can be measured by integrating the red curve in fig. 9 - it's all the area under the curve.
This case study concludes the story of Growth and Fraud:
- GP1 - Meet at the Grigg Point
- GP2 - Instructing Security at GP
- GP3 - How to Book a Table
- GP4: Case Studies:
Ownership has been revealed as a flawed misconception believed by the masses as their rights of usage. The ownership of their credit information, private residency, and purchased property is all but a notional concept. Since the dawn of ecommerce the teeth of State Controlled Rights have reared thier ugly head and the consumer at least the US consumer has watched the Supreme Court rule that government is allowed to take property away based on a projected greater good basis rendering property ownership useless. The consumer has no recourse when their information is sold by merchants and unprotected by those same merchants. Freedom has all but vanished and waned to the beneficent dictator. We no longer have representation in elected offices due to the states preference to bow to better funded non-physical entities. Phishing is a symptom of the society serving the elites and rendering the un-empowered to theft and scandal. The online is reflecting the social ills of our society with the credo might makes right. sphere of self interest.
Posted by: Jimbo at December 30, 2005 12:25 PMHTTPS traffic has usually been protected by RC4, which is lightning-fast, rather than 3DES which indeed taxes CPUs pretty heavily.
I don't think the porn guys have had any problems with encryption-caused loads.
Actually, I think that RC4 was one of the reasons why SSL-based HTTPS emerged as the winning secure browsing solution when PGP-based SHTTP was already implemented (NCSA httpd server and mosaic browser, later ported to Apache) and based on the most popular and trusted crypto available at the time. OTOH, SHTTP would have allowed encrypting the stuff once with a symmetric key, and only do the asymmetric encryption of that key in real time.
Anyhow, I have been hired to develop a new content-distribution mechanism, so the non-hollywood content industry (which is porbably much more than porn) is not quite happy with SSL.
Two quick comments (because I don't have time for more):
First, I want to correct a misleading statement about Netscape: The amount of total Netscape revenue from the Federal sales group never exceeded ten per cent or so of total Netscape revenues (a ratio in line with enterprise software companies in general), so it's not correct to say that "the Federal sales division of Netscape was reputed to have made most of the revenues". However it was most likely the case that the US government in general was the single largest source of Netscape revenues, in the sense that no other single company/organization accounted for a higher percentage of revenue. (Again, given the size of the US government this is a pretty typical situation for enterprise software companies.)
Second, it's great to know your thoughts on what went wrong, especially in light of your "GP" ideas, which seem worth exploring. But your readers crave more: If you had been in charge, what would you have done differently? What specific security measures would have made sense in your mind, and when? (Maybe this could be another blog post? :-)
Posted by: Frank Hecker at January 2, 2006 03:45 PMFrank, thanks for your correction! FTR, I've changed "Federal sales division of Netscape was reputed to have made most of the revenues" to "US government was the single largest source of Netscape revenies..." in the text above.
(I certainly agree that this situation is in common with many other large enterprise suppliers. And it is similar in other places around the world, more or less. Nothing unusual there, and it would be a surprise if Netscape wasn't under such forces. As a for instance, we see much the same going on today with the big suppliers and the Chinese government - Yahoo, Sun, Cisco, eBay have all been in the press over this sort of influence.)
Posted by: Iang at January 2, 2006 04:17 PMFrank,
On your second point - "your readers crave more" - you are too kind, I know that my readers crave my head, but I'll try and answer it anyway :-)
Firstly, the point of the historical dive into SSL's beginnings is to identify the genesis about certs, and I conclude that "there is no way [Netscape] could have avoided it. The forces were just too strong." So my first answer is that I couldn't have made any different choices!
But we can get a little deeper. GP's thesis is that there is no value or negative value in putting the security in too early, and my story lays it out with that theme - it was too early. So if we had concluded that there was no value, there was also no point in going up against all those forces. Same answer than as (1) above. If we concluded negative value, then that would have been simple - not deploy it so fast, or deploy it in a more limited fashion.
Third attempt - lets say we recognised all those forces and decided to go up against them. (Yowsa!) The way I'd do that is to set up some meetings and collaborations and standards groups.
Fourth attempt - we have to seriously consider that the goal was money and not security. If that was the case, then the short term tactical goal is control and the long term strategic goal was not the above forces at all but M$, which is strangely absent from that list. If that were the case, then the protocol would have just been wrestled about in a different war, not the one it was in. If one is security minded then one would be equally unsatisfied, so this is another dud answer ;-) But assuming that we were going to use the protocol as a weapon against M$, then there were plenty of directions and some of them even would have been positive for security. For example, I'd have been sorely tempted to do the uber-CA thing because it solves or addresses some of the bugs in the implementation (still there!) and the murky legal situation.
Of course, the deeper we get into this armchaircryptogeneralling, the stickier it gets. I wasn't there - you were. What would you have done (if you'd been in the hot seat) ?
Posted by: Iang at January 2, 2006 04:50 PMRe your question, "What would you have done (if you'd been in the hot seat)?" I don't really have any better answers than you. If the near-term goal were simply to allay basic fears about eavesdropping on connections (and remember, not just PKI folks were obsessed about that, it was the heyday of crypto paranoia generally) then from a technical point of view an alternative approach would have to go with an SSH-style model for SSL (with or without certs as such), or perhaps a model which nominally used certs but where you got the cert from your web server software vendor as a side effect of installing the software. Basically the approach here would have been to 1) make SSL-enabling connections dead easy and 2) avoid focusing overmuch on "identity" (and the need for CAs to validate such identity). But I agree that the forces around SSL were probably too great to avoid going down the traditional PKI path, especially because of the e-commerce and payment connection.
Where I think a major opportunity was missed was with S/MIME email. Although S/MIME as such was technically tied to X.509v3 certificates, IMO there was no real reason why CAs as such couldn't have been optional in the S/MIME implementations fielded by Netscape and others. Netscape Communicator could have generated self-signed certs automatically upon initialization, and could have easily bootstrapped into automatically and silently doing signing and encryption when sending email to people known to also be using Netscape Communicator (based on previously having received email from them).
I think email would have been a good area to do this sort of alternative approach, for several reasons. Crypto performance would have been much less of an issue than with SSL, because the transactions would not be "real-time", so adopting an "always sign and/or encrypt" policy would be much less of a burden. For the most part S/MIME wasn't tied up in the e-commerce/payment wars as was SSL. Also, self-signed certs could have been used in combination with the user's address book to make a basic distinction between "known" vs. "unknown" (and thus potentially dubious) sources of email, bypassing the whole issue of needing CAs to do this sorting out of potential correspondents. Enterprises would still have wanted to do the PKI thing (since that was still the hot thing at that time), but they could have just turned off the auto-recognition of self-signed certs.
Against this we have to weigh the fact that "overt" use of S/MIME (as opposed to the "covert" use described above) was still driven by large enterprises wedded to the PKI/CA model and driven in large part by e-commerce concerns (e.g., to move EDI-style transactions over to a full digital signature regime). And of course CAs themselves were still operating under the assumption that they could sell millions of certs to random individuals.
But I think the basic ideas of "opportunistic cryptography" (to use your term) in the email context are still worth exploring. (And as I understand it, this is in many respects the strategy that Skype pursued with their VOIP client, basically giving the user crypto without worrying them about how it got done.)
Posted by: Frank Hecker at January 3, 2006 12:19 AMActually, I still don't understand why do domain name registries not provide certs with the domain name. After all, there's already a hierarchy of trust in place there, why have a different one (and why trust the other one to certify this one?)?
What would be more authoritative certification than that of the registry?
> Actually, I still don't understand why do domain name registries not provide certs with the domain name.
Technically, that makes sense and has been on the IETF agenda for ages. Politically, it's going to upset a hundred committees and vested interests. I've never followed it, but it is frequently brought out in conversation and just as frequently shot down in flames...
I suppose the place to watch is godaddy.com.
Posted by: Iang at January 3, 2006 08:16 AMOn the subject of getting certs with domain names: As Ian mentioned, some companies like Go Daddy are indeed treating certs as basically an add-on to domain name registration. However it is still not treated as a truly bundled service, for a couple of reasons I think:
First, an SSL cert is still perceived by suppliers like Go Daddy as something that they can charge for. Hence from the user's perspective it's an optional purchase, and one without a clear value proposition if you're not doing an online store.
Second, bundling a cert with a domain name registration by default makes most sense if the company in question is selling hosting services too (which Go Daddy and other domain name vendors do), since then all the web server magic in enabling SSL can be done "under the covers" with minimal main to the user. However as Ian well knows there are technical problems with deploying SSL in the virtual host mode used by hosting services for their entry-level offerings. These problems won't go away until SSLv2 support gets dropped by default and the majority of browsers in use implement the TLS extension that supports SSL use in a virtual hosting mode. This will take at least a year or so, maybe longer.
But I do agree that SSL server certs are a natural companion to domain names and hosting services, and ideally would be bundled together in a single service. The role of CAs in such an environment would then move in large part to being back-end suppliers of PKI technology and services to the "web presence" vendors. I discuss this in more depth in my "business of CAs" post.
Posted by: Frank Hecker at January 3, 2006 09:52 AM> Actually, I still don't understand why do domain name
> registries not provide certs with the domain name. After
> l, there's already a hierarchy of trust in place there,
> why have a different one (and why trust the other one to
> certify this one?)? What would be more authoritative
> certification than that of the registry?
one might conjecture that there are some economic forces in play ... if it was done within dns ... there wouldn't have been justification for independent business ... it would simply be part of the existing infrastructure.
the other part is done within the existing dns operation, there would have been no justification for PKI, certification authorities, digital certificates, etc.
basically dns provides real-time authoritative information responses (and structured for generalized information not just binding of ip-address to domain name ... but can and does provide various kinds of other information bound to domain name).
within the dns real-time authoriative information responses, a public key implementation would be bound to a domain name ... in addition to the other information bound to a domain name and provided in a real time response.
the digital certificate model was designed to provide relying party with stale, static binding information in stituations where the relying party had no access to their own local repository of information and/or online, real-time access to some authoritatve agency with the information (aka an offline environment)
there is dnssec effort, somewhat backed by the ssl certification industry to have domain name owners register a public key when a domain name is registered. currently, a certification authority requires some identification information in conjunction with an ssl domain name certificate. the ssl certification authority then can do a real-time retrieval of the identification information onfile with the domain name infrastructure. then the certification authority does the expensive, time-consumer, and error prone task of matching the supplied identification information with the onfile identification information.
dnssec would allow the certification authority to request digital signature on ssl domain name certificate applications. then the certification authority could do a real-time retrival of the onfile public key and verify the digital signature ... replacing a time-consumer, expensive, and error-prone identification matching process with a much simpler, reliable, and less-expensive authentication operation.
the catch-22, is if the ssl certification authority industry can start doing real-time retrivals of onfile public keys ... then the rest of the world could also ... obsoleting the requirement for ssl domain name certificates. lots of past postings on ssl certificates and the ssl certification process
http://www.garlic.com/~lynn/subpubkey.html#sslcert
i've even suggested a drastically simplified and efficient ssl hand-shaking protocol. the client does a call to dns just like they do today ... but if there is any registered public key ... they get back both the ip-address along with any public key and crypto protocol options piggy-backed on the ip-address response.
then in a single communication with the server, they could transmit the random session key (encrypted with the server's public key) and the actual request (encrypted with the random session key) ... no SSL protocol setup chatter is required.
this could even be done as a udp and/or transaction protocol.
note that SSL over HTTP over TCP is quite expensive. the minimum packet exchange for just TCP is seven packets ... and then HTTP and SSL has to ride on top of that ... including all the SSL protocol setup chatter.
an early reliable "transaction" protocol was VMTP ... which reduced the 7-packet minimum TCP to 5-packet minimum.
I did a lot of work on XTP ... which included support for reliable "transaction" protocol in 3-packet minimum exchange. lots of past posts on XTP
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
aka do dns udp in single round-trip, getting ip-address, public key, and any ssl crypto options in single roundtrip. then do ssl-like encrypted request/response transaction with XTP in minimum 3-packet exchange.
while there was an RFC for vmtp ... rfc1045 ... there was never a RFC for XTP ... although we did a forey at ISO (but got hung up in the rule about violating OSI model). there are a couple books written on XTP ... and I've piles of hardcopy and softcopy stuff.
my rfc index
http://www.garlic.com/~lynn/rfcietff.htm
move down to "RFCs listed by" section and select "TERM (term->RFC#)".
in the acryonym fastpath section, select "DNSSEC". this will give you all RFCs associated with DNSSEC ... aka
domain name system security (DNSSEC )
see also domain name system , domain name system extensions , security
4322 4310 4035 4034 4033 3845 3833 3755 3658 3226 3225 3130 3110 3090 3008 3007 2931 2930 2845 2541 2540 2539 2538 2537 2536 2535 2137 2065
if you are in frames mode, selecting any RFC number will bring up the RFC summary in the lower frame. as always, selecting the ".txt=nnnn" field (in an rfc summary) retrieves the actual RFC.
Posted by: Lyn Wheeler at January 3, 2006 11:54 AMor you could go even further. the prevailing use of SSL is for hiding acocunt numbers in payment transaction.
the long-time vulnerability for payment transactions was attacker evesdropping and/or harvesting account numbers and using them in fraudulent transactions
http://www.garlic.com/~lynn/subpubkey.html#harvest
http://www.garlic.com/~lynn/subpubkey.html#secrets
http://www.garlic.com/~lynn/subpubkey.html#fraud
effectively a form of replay-attack.
the x9a10 standards working group was given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the resulting protocol was x9.59.
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
it had two business rules
1) transactions were strongly authenticated
2) account numbers used in x9.59 transactions would not be valid in non-authenticated transactions
this is effectively traditional countermeasures for attackers attempting replay attacks.
with the elimination of the evesdropping/harvesting vulnerability for replay attacks (fraudulent transactions) the justification for hiding the account number was drastically reduced.
x9.59 transactions had sufficient protection with simple authentication for fraud prevention and no longer needed encrypting and account number hiding to prevent fraud.
customers would register public keys with their accounts (in similar manner suggested for domain name infrastructure) ... similar to registering "mother's maiden name" or other authentication information. the consumer applies their digital signature to the x9.59 transaction and send it on its way. the transaction eventually arrives at the consumer's financial institution, validates the digital signature (with the onfile public key), does their other bit of authentication magic and authorization magic and send off the reply.
no PKI, certification authority and/or digital certificates are required. in addition, it also eliminates the requirement for SSL hiding of the account number; just simple authentication and long understood countermeausures against replay attacks.
the ancillary issue was that there were some payment protocol activities going on concurrent with the x9.59.
we had been involved in much of the work on the original payment gateway with this little client/server startup company that had come up with SSL (and used for hiding payment transactions)
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
one of the scenarios that we looked at with respect to some of the PKI/certificate-based payments ... was just the payload size. A PKI infrastructure has the original transaction, an appended digital signature, and one or more appended digital certificates (under the assumption that the receiving party has no prior knowledge of the signer and/or their public key).
A standard ISO8583 payment transactions runs 60-80 bytes. The common appended PKI digital certificate of the period ran 4k-12k bytes. Basically, the PKI-based infrastructure planned on increasing the transaction payload size by two orders of magnitude (100 times increase in payload size) with appended PKI overhead ... solely on the justification that the receiving consumer's financial institution had no prior relationship with the consumer (which appears to be logical contridiction).
Posted by: Lynn Wheeler at January 3, 2006 01:14 PMthe other approach to doing the financial transaction account number vulnerability analysis is using the userid/password metaphor.
bascially an account number is used to select the account, like the functionality provided by userids. also, like userids, account numbers are required to be available and used in a large number of different business processes.
however, the account number is also used to authenticate the transaction ... i.e. knowledge of the account number is sufficient authentication in large number of payment transactions. in that use, the account number is like a password and is vulnerable to evesdropping, skimming, and/or harvesting. thus such account number uses is also like a password.
the use of an account number as both a "userid" and a "passwords" may create an horribly conflicted environment. at post periods, the industry had created countermeasures to account number guessing ... i.e. as fraud prevention in account number role as password.
however, the advent of evesdropping, skimming, and harvesting attacks sidestepped the guessing countermeasures and opened the way for replay attacks (i.e. capturuing a valid value and replaying it).
SSL and various of the PKI-based payment protocols provided countermeasure to account number evesdropping while transactions were in-flight. however, one of the long term (preceeding internet use) attacks against account numbers have been havesting account numbers from stored information. the stored transaction acocunt information was required for a large number of business processes where the account number role is used like a "userid".
this gave rise to my past comments that the planet could be buried under miles of encryption and it still would prevent account number leakages. the problem was the dual-use requirements placed on account numbers for both userid functionality and password functionality and the radically conflicted processing and protection objectives. The account number as userid functionality has to be fairly widely available. The account number as password functionality has to be kept hidden and confidential. This conflicting requirements leads to enormous problems and vulnerabilities that can't be address by simply hiding the account number in transit.
the solution by x9.59 retail payment standard eliminated the dual-use conflict for account numbers. account numbers were solely restricted to use a userid funtionality. digital signatures were introduced for (authentication) password functionlity. x9.59 enabled accounts would no process transactions that didn't have appropriate authentication (many of the PKI-oriented payment protocols solely addressed hiding the account number, but still allowed the account number to be skimmed or harvested and used in non-PKI and non-authenticated transactions).
with the elimination of account number dual use ... it was no longer to hide the account number ... since it was only be used for "userid" functionality.
static data passwords are still subject to evesdropping and replay attacks ... and therefor are required to be hidden. advantage of digital signatures for authentication (over static data passwords) is that they can be evesdropped w/o being vulnerable to replay attacks.
as previously mentioned, a separate issue with some of the PKI-based payment protocols was the enormous payload bloat
(increase in payload size of one hundred times) introduced by requiring stale, static, redundant and superfluous digital certificates to be appended to payment transaction.
going back to fundamental principle of PKI, certification authorities and appended digital certificates ... is that you have digitally signed something and prepared to transmit the transaction and the appended digital signature.
The issue in PKI environment is that the targeted recipient has no prior information about you and/or has no way of doing online operation to obtain information about you.
So digital certificates are created that have been certified by independent, well known parties (where the targeted recipient is believe to have some sort of trusted relationship). The targeted recipient is believe to trust the certification authority and therefor the appended digital certificate with appropriate information about you ... will be trusted.
However, it takes quite a bit of confused thinking to believe that a consumer's financial institution has no prior knowledge about their consumers for which they have created consumer accounts and issued consumer accounts. It is even more unbelievable that the because it is believed that a consumer's financial institution has had absolutely no relationship with the consumer for which there is an account ... that it justifies bloating a payment transaction payload size by a factor of one hundred times.
I suggest that if we had been using an SSH-style security model all these years since the mid 90s, we would have seen just as many problems. Attackers would have tuned their efforts towards the weaknesses in that model if that were the one that was widely deployed. It's crazy to look at the attacks in place today in an SSL world, note that they would not work well against an SSH world, and conclude that if we had an SSH world we'd have no attacks!
The achilles' heel of SSH is the initial connection, when an unverified key is accepted and trusted for future use. If the attacker can get there first and play MITM on that initial connection then security is lost. Who knows what creative methods to accomplish this would be conceived in ten years of intensive efforts by hackers and criminals.
Another obvious effect would be that instead of SSL's "bad/expired certificate" messages which people have been auto-trained to ignore, we would see SSH's "key-changed" messages which would be just as opaque and just as common due to system re- and mis-configurations.
a PKI certificate-based model
1) assumes that the relying-party or recipient has not other source of information (aka the letters of credit/introduction from the sailing ship days)
2) trust in the certifying party
a certificateless-based model
http://www.garlic.com/~lynn/subpubkey.html#certless
1) assumes that the recipient and/or relying party has their own information
2) and/or direct access to certifying party
SSH is one such certificateless implementation.
various of the PKI payment solutions from the mid-90s were relying-party-only scenarios
http://www.garlic.com/~lynn/subpubkey.html#rpo
the relying-party-0only certificate model from the mid-90s were
1) reaction to the x.509 identity certificate standard, realizing that personal information in certificate represented serious privacy and liability issues
2) effectively restricted the "personal" information in the certificate bound to the entity's public key was just an account number.
even at that, the certificate-based appended overhead still represented an enormous payload bloat of 100 times.
the PKI process scenario from the mid90s was a consumer provided a public key (and proof of the private key) that the financial institution could register in the account record (akin to registering mother's maiden name).
in the traditional PKI process, this is frequently referred to as the RA or registration authority.
the financial institution then generated a (replying party only) digital certificate which was returned to the consumer (the certification manufactoring part of the PKI process)
the consumer was then expected to generate a transaction, append a digital signature, and also append the digital certificate (resulting in a 100-times payload bloat).
eventually the digital signed transaction arrived at the financial institution, they pull the account number from the transaction, retrieve the account record, and then can use the public key registered in the account record to validate the digital signature.
any appended digital certificate, in addition to causing a 100-times payload bloat was truely redundant and superluous.
the x9.59 scenario
http://www.garlic.com/~lynn/index.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
can do the identical public key registration as the PKI scenario. the certificateless process, just eliminates the manufactoring of a redundant and superfluous digital certificate and also eliminates the appending of a redundant and superfluous digital certificate on ever financial transaction sent back to the consumer's financial institution (as well as avoiding the 100-times payload size bloat).
As mentioned before, neither the SSL or the PKI-based acocunt hiding technique actually addressed the major long-term vulnerability of account numbers (dual-user vulnerability representing both the userid functionality as well as the password functionality.
old related posting on security proportional to risk (and the merchant transaction file)
http://www.garlic.com/~lynn/2001h.html#61
and that continue to show that the leading cause of data breaches associated with id/account theft involve insiders
http://www.garlic.com/~lynn/aadsm17.htm#38 ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
similarly, the solution to major SSL domain name certificate vulnerability was the registration of a domain name user's public key. The trust root for SSL domain name certificate then changes from the identification information on file with the domain name infrastructure (and the expensive, error-prone, and time-consumer identification matching process) to the onfile, certificateless public key (and a simpler, more reliable, and less expensive digital signature verification proces).
A certificateless, SSH-style implementation doesn't necessarily mean that there has not been any registration process and/or certification of the public key. It may just mean that there hasn't been the certificate manufactoring (a term we coined when we were doing the original payment gateway and auditing these new operations called certification authorities) process.
Posted by: Lynn Wheeler at January 4, 2006 12:28 PMthe certificate payload bloat was so enormous for payment protocols (factor of 100 times) that X9 financial standard group (with a backing of major PKI forces) started a new work item called digital certificate compression. the idea was to come up with various compression techniques to try and get the appended digital certificate down from several thousand bytes to possibly 300 bytes.
the first thing they talked about doing was eliminating all fields that were common across all certificates by the same institution.
early on i pointed out that there was a couple of different ways of addressing the enormous payload bloat of digital certificates in payment protocols ... aside from eliminating them as being redundant and superfluous.
a perfectly valid information compression technique was to eliminate all fields that were already in possession of the relying-party (not just the fields that were common to all certificates). i quickly showed that this technique easily achieves zero-byte certificates. rather than making the rash statement of not appending stale, static digital certificates to every digitally signed transaction, i suggested that implementations should instead append zero byte certificates to every digitally signed payment transaction.
the other mechanism was to use certificate caching echnology ... if the relying party was known to have previously acquired the consumer's digital certificate and was to known to have saved it ... then it was possible to avoid appending the same digital certificate on subsequent payment transactions ... since it could be shown that the relying party was guaranteed to already have a copy.
since it was a relying party scenario, the institution being the registration authority as well as the certification authority; when the consumer registered their public key with their institution ... the institution would dutifully create a full-fledge digital certificate and save a copy in the consumer's account record. then the institution would return a note to the consumer saying that they were caching the consumer's digital certificate on behalf of the consumer ... and therefor it was not necessary to actually send the consumer a copy of their digital certificate ... since it would just result in the consumer appending the copy to possibly thousands of future payment transactions and returning it to the financial institution. by caching the original, the financial institution was saving the consumer enormous amounts of bandwidth and processing by keeping. if the consumer wanted, they could append a short note to digitally signed payment transactions stating that the digital certificate was already on file (in most cases, the digital certificate on file wouldn't even be a copy, but the original).
numerous past post discussing the enormous benefits of creating zero-byte digital certificates with advanced information compression technology
http://www.garlic.com/~lynn/aadsm2.htm#storage Storage of Certificates
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://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))
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm11.htm#35 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm11.htm#36 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda II
http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000f.html#3 Why trust root CAs ?
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2004d.html#7 Digital Signature Standards
http://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?
I like the way webopedia, yes another pedia, describes what SSL is.
"S-HTTP is designed to transmit individual messages securely"
Ha-ha-ha
Helen, I suspect you are confused - that text in full is:
Another protocol for transmitting data securely over the World Wide Web is Secure HTTP (S-HTTP). Whereas SSL creates a secure connection between a client and a server, over which any amount of data can be sent securely, S-HTTP is designed to transmit individual messages securely. SSL and S-HTTP, therefore, can be seen as complementary rather than competing technologies. Both protocols have been approved by the Internet Engineering Task Force (IETF) as a standard.
Posted by: Iang at June 15, 2006 06:50 AM