James A. Donald wrote:
PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.
asymmetric cryptography has a pair of keys ... the other of the key-pair decodes what has been encoding by one of them. a business process was defined using this technology where one of the key-pair is designated as public ... and freely distributed and the other of the key-pair is designated as confidential and never divulaged. an authentication business process was defined using public/private business process called digital signature .... where a hash of a message is taken and encoded with the private key. the recipient can recompute the hash of the received message and compare it to the digital signature that has been decoded with the corresponding public key. this catches whether the message has been altered and from 3-factor authentication http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are implies "something you have" authentication ... i.e. the originator has access and use of the corresponding private key. PKI was somewhat targeted at the offline email model of the early 80s; the relying party dials up their (electronic) post office, exchanges email, and hangs up. They then may be dealing with first time correspondance from a total stranger with no (offline or online) recourse for determining information about the sender. Relying parties could be seeded with trusted public key repository of trusted third party certification authorities. Stangers could be issued "certificates" (digitally signed by one of these certification authorities) containing informoation about themselves bound to their public key. Email recipients in the offline email days of the early 80s ... could now of source of information regarding first time communication from total strangers (sort of the "letters of credit" model from the sailing ship days). we were asked to work this small client/server startup in menlo park http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 that wanted to do payments on something they called a commerce server. In the year we worked with them ... they moved from menlo park to mountain view and changed their name (trivia question ... who previously had the rights to their new name? also what large corporate entity was providing most of the funding for the commerce sever?). some topic drift ... recent postings referencing this original e-commerce work as an example of service oriented architecture (SOA): http://www.garlic.com/~lynn/2005i.html#42 http://www.garlic.com/~lynn/2005i.html#43 they had this technology called SSL which was configured at addressing two issues: a) is the webserver that the user had indicated to the browser ... the actual webserver the browser was talking to and b) encryption of the transmitted information. SSL digital certificates would be issued http://www.garlic.com/~lynn/subpubkey.html#sslcert which would contain the domain name of the webserver bound to their public key. the browsers would have trusted public key repository seeded with the public keys of some number of trusted third party certification authorities. the browser SSL process would compare the domain name indicated by the user to the domain name in the digital certificate (after validating the certificate). (at least) two (other) kinds of vulnerabilities/exploits have shown up. 1) in the name of convenience, the browsers have significantly obfuscated the certificate operation from the end-user. attackers have devised ways for the end-users to indicate incorrect webservers ... which the browser SSL process (if it is even invoked) will then gladly validate as the webserver the user indicated. 2) a perceived issue (with knowing that the webserver that a browser is talking to is the webserver the user indicated) were integrity issues in the domain name infrastructure. however, as part of doing this consulting with this small client/server startup ... we also had to do detailed end-to-end business process due dilligence on some number of these certification authorities. it turns out that a certification authority typically has to check with the authoritative agency for the information they are certifying. the authoritative agency for domain name ownership is the domain name infrastructure ... the very institution that there are integrity questions giving rise to the requirement for SSL domain name server certificates. In the second vulnerability, the certification authority industry is somewhat backing a proposal that when somebody registers a domain name with the domain name infrastructure ... they also register their public key. then in future communication with the domain name infrastructure, they digitally sign the communication. the domain name infrastructure then can validate the digital signature using the (certificateless) public key onfile for that domain. This supposedly improves the integrity of the communication between the domain name owner and the domain name infrastructure .... mitigating some possible domain name hijacking exploits (where some other organization becomes recorded as the domain name owner). It turns out that the certification authority industry also has an issue. When somebody makes an application for an SSL domain name certificate, they need to supply a bunch of identification information. This is so the certification authority can perform the expensive, time-consuming and error-prone identification process ... and then do the same with the information on file at the domain name infrastructure as to the owner of the domain name ... and then see if the two domain name owner identifications appear to match. Having an on-file public key for the domain name owner ... the certification authority industry can also require that an SSL domain name applicant, digitally sign their application. Then the certification authority can retrieve the onfile (certificateless) public key and change an expensive, error-prone, and time-consuming identification process into a simple and more reliable authentication process (by retrieving the onfile public key and validating the digital signature). From an e-commerce perspective ... the SSL process was to protect against credit card information havesting for use in fraudulent transactions. However, the major vulnerability/exploit before SSL and after the introduction of SSL ... wasn't against credit card information in flight ... but against huge repositories of credit card information (information at rest). It was much easier for the crooks to steal the information already collected in huge repositories than go to the effort of evesdropping the information inflight and creating their own repositories (fraud return-on-investment, much bigger benefit in stealing large repositories of already collected and organized information). related reference regarding security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 the financial standards working group, x9a10 was given the task of preserving the integrity of the financial infrastructure for all retail payments (as well as some number of other requirements) for x9.59 standard http://www.garlic.com/~lynn/index.html#x959 so some earlier work on PKI-oriented protection for retail payments involved digitally signed transaction oriented protocol with attached digital certificates. in the early 90s, there was some work on x.509 identity certificates. however, there was some issues with ceritifcation authorities predicting exactly what information might be needed by unknown future relying parties ... and so there was some direction to grossly overload these certificates with excessive amounts of personal information. In the mid-90s, some number of institutions were starting to realize that such overloaded repositories of excessive personal information representing significant liability and privacy issues. As a result you saw some retrenchment to relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo these were digital certificates that basically contained some kind of database record locator (like an account number) bound to a public key (the database record contained all the real information). however, it became trivial to demonstrate that such relying-party-only certificates were redundant and superfluous. This was, in part because they violated the original design point for certificates ... the relying party not having any other recourse to the necessary information. By definition if all the information was in a relying-party's database ... then by definition the certificate was redundant and superfluous. in this later part of the mid-90s payment scene, these relying-party-only certificates were on the order of 4k-12k bytes. It turns out that a typical retail payment message is 60-80 bytes. Not only were the stale, static, relying-party-only certificates redundant and superfluous ... but they also would contribute to enormous payload bloat (on the order of one hundred times). the other problem with the relying-party-only, redundant and superfluous, stale, staic, enormous payload-bloat digital certificate based infrastructure ... were that they effectively were targeted only at protecting credit card information "in-flight" ... something that SSL was already doing. They were providing no countermeasure for the major vulnerability to the data "at rest". the information at rest was still vulnerable (and was the major exploit already with or w/o SSL) So one of the things in the x9a10 financial standards working group was to do a treat and vulnerability analysis ... and design something that could preserve the integrity of the financial infrastructure for all retail payments (credit, debit, stored-value, online, offline, pos, etc). X9A10 defined a light-weight digitally signed transaction that wouldn't contribute to the enormous payload bloat of the stale, static, redundant and superfluous certificate-based infrastructures. Another issue was the analysis demonstrated that the major treat and vulnerability was to the data at rest. So for X9.59, a business rule was defined ... for account numbers used for X9.59 transactions ... only correctly verified digitally signed transactions (authenticated) could be authorized. An x9.59 transaction was digitally signed, and the relying party could use an on-file public key to validate the digital signature .... showing the transaction wasn't modified in transit and providing "something you have" authentication as to the originator (they had access and use of the corresponding private key). furthermore, evesdropping of the transaction in flight ... and/or harvesting the large transaction databases (information at rest) wouldn't yield information for the crook to perform a fraudulent transaction. the current exploits where knowledge from an existing transaction is sufficient to generate fraudulent transaction has gone away ... for vulnerabilities involving both "data in flight" as well as "data at rest". The issue wasn't that SSL being designed to protect data-in-flight ... the issue was that the major threat/vulnerability has been to "data-at-rest" ... so to some extent, SSL (and the various other countermeasures to "data-in-flight" vulnerabilities) wasn't responding to the major threats. To some extent, e-commerce/internet was opening a theoritical, new vulnerabilities ("data-in-flight") compared to the non-internet world ... and so SSL was somewhat theoritically demonstrating that e-commerce/internet use wouldn't make the situation any worse. Recent studies have indicated that at least 77% of the id theft exploits have involved insiders (supporting the long standing premise that the majority of fraud is by insiders). The introduction of e-commerce and internet have introduced new avenues for attacking data-at-rest by outsiders. As a result, e-commerce/internet potential threats to data-at-rest has contributed to obfuscating responsible insiders in cases of exploits against data-at-rest. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com