Re: [Cryptography] encoding formats should not be committee'ized
On 09/30/13 04:41, ianG wrote: Experience suggests that asking a standards committee to do the encoding format is a disaster. I just looked at my code, which does something we call Wire, and it's 700 loc. Testing code is about a kloc I suppose. Writing reference implementations is a piece of cake. Why can't we just designate some big player to do it, and follow suit? Why argue in committee? early 90s annual ACM SIGMODS (DBMS) conference in San Jose ... general meeting in (full) ballroom ... somebody in the audience asks panel on the stage what is all this x.5xx stuff about ... and one of the panelists replies that it is a bunch of networking engineers trying to re-invent 1960s DBMS technology. CA industry is pitching $20B/annum business case on wallstreet ... where the financial industry pays CAs $100/annum for every account for a relying-party-only digital certificate ... where the financial industry providing all the information that goes into the certificate (CA industry just reformats all the information and digitally signs it). In one case of institution with 14M accounts, the board asks what is this $1.4B/annum thing about? I repeatedly point out that it is redundant and superfluous since the institution already has all the information. Purpose of the certificate is to append to every financial transaction. I also point out that digital certificate payload is enormous bloat, 100 times larger than the transaction size its attached to (besides redundant and superfluous) CA industry then sponsors x9.63 work in X9 financial standards industry for compressed certificate format ... possibly getting the payload bloat down to 10 times (instead of hundred times). Part of the compressed certificate work was to eliminate fields that the relying party already had. Since I had already shown that the relying party (institution) already had all fields, it was possible to compress every certificate to zero bytes ... so rather than doing digitally signed transactions w/o certificates ... it was possible to do digitally signed transactions with mandated appended zero-byte certificates. Trivia: last few years before he passed, Postel would let me do part of STD1. There was a joke that while IETF required at least two interoperable implementations before standards progression, ISO didn't even require that a standard be implementable. -- virtualization experience starting Jan1968, online at home since Mar1970 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Gilmore response to NSA mathematician's make rules for NSA appeal
We had been asked to come in and help wordsmith the cal. state digital signature act. Several of the parties were involved in privacy issues and also working on Cal. data breach notification act and Cal. opt-in personal information sharing act. The parties had done extensive public surveys on privacy and the #1 issue was identity theft, namely the form of account fraud as result of data breaches. There was little or nothing being done about this so there was some hope that the publicity from the breach notifications would motivate corrective action. The issue is that normally an entity takes security and countermeasures in self-protection ... the entities suffering the data breaches weren't at risk ... it is the account holders. Since then several Federal breach notification bills have been introduced about evenly divided between having similar notification requirements and Federal preemption legislation eliminating requirement for notifications. The federal bills elimina ting noti fications cite industry specifications call for account encryption (that were formulated after the cal. legislation). We've periodically commented in the current paradigm, even if the planet was buried under miles of information hiding encryption it still wouldn't stop information leakage. One problem, is account information is basically used for authentication and as such needs to be kept completely confidential and never divulged. However, at the same time, account information is also required in dozens of business processes at millions of location around the world. The cal.personal information opt-in sharing legislation would require institution have record from the individual authorizing sharing of information. However, before the cal legislation passed, an opt-out (federal preemption) provision was added to GLBA. GLBA is now better known for the repeal of Glass-Steagall. At the time, the rhetoric in congress was the primary purpose of GLBA was if you already had bank charter you got to keep it, however, if you didn't have a charter, you wouldn't be able to get one (i.e. eliminate new parties from coming in and competing with banks). However, GLBA was loaded up with other features like repeal of Glass-Steagall and the opt-out personal information sharing (i.e. the financial institution needed record of person declining sharing of personal information ... rather than opt-in which required institution to have record authorizing sharing). A few years ago, I was at a national annual privacy conference in Wash DC. (hotel just up the street from spy museum). There was a panel discussion with the FTC commissioners. Somebody in the audience asked the FTC commissioners if they were going to do anything about GLBA opt-out privacy sharing. He said he worked on callcenter technology used by all the major financial institutions ... and that none of the 1-800 opt-out desks had provisions for recording information from the call (aka an institution would *NEVER* have a record of a person objecting to sharing their personal information). The FTC commissioners just ignored him. -- virtualization experience starting Jan1968, online at home since Mar1970 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] In the face of cooperative end-points, PFS doesn't help
note when the router hughes references was 1st introduced in in IETF gateway committee meeting as VPN it caused lots of turmoil in the IPSEC camp as well as with the other router vendors. The other router vendors went into standards stall mode ... their problem was none of them had a product with processors capable of handling the crypto processing. A month after the IETF meeting one of the vendors announced what was supposedly an equivalent product ... but was actually their standard product (w/o crypto) packaged with hardware link encryptors (needed dedicated links instead of being able to tunnel thru the internet). The IPSEC camp whined a lot but eventually settled for referring to it as lightweight IPSEC (possibly trying to imply it didn't have equivalent crypto). As to DNSSEC ... the simple scenario is requiring domain owners to register a public key and then all future communication is digitally signed and authenticated with the onfile, registered public key (as a countermeasure to domain name take-over which affects the integrity of the domain name infrastructure and propogates to SSL CA vendors if they can't trust who the true owner is). Then the SSL CA vendors can also start requiring that SSL certificate requests also be digitally signed ... which can also be authenticated by retrieving the onfile public key (turning an expensive, error-prone and time-consuming identification process into a reliable and simple authentication process). The catch22 is once public keys can be retrieved in realtime ... others can start doing it also ... going a long way towards eliminating need for SSL certificates. Have an option piggy-back public key in the same response with the ip-address. Then do SSL-lite ... XTP had reliable communication minim um 3-pack et exchange ... compared to TCP requiring minimum 7-packet exchange. In the key escrow meetings, I lobbied hard that divulging/sharing authentication keys was violation of fundamental security principles. Other parties at the key escrow meetings whined that people could cheat and use authentication keys for encryption. However, there was commercial no single point of failure business case for replicating keys used in encrypting data-at-rest corporate assets. One might hypothesis that some of the current DNSSEC complexity is FUD ... unable to kill it ... make it as unusable as possible. disclaimer: person responsible for original DNS worked at the science center in the early 70s when he was at MIT. -- virtualization experience starting Jan1968, online at home since Mar1970 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Opening Discussion: Speculation on BULLRUN
On 09/07/13 05:19, ianG wrote: If so, then the domain owner can deliver a public key with authenticity using the DNS. This strikes a deathblow to the CA industry. This threat is enough for CAs to spend a significant amount of money slowing down its development [0]. unfortunately as far as SSL domain name certificate ... the domain name infrastructure is the authoritative agency for domain name ownership ... the SSL domain name certification agencies have to rely on the domain name infrastructure to validate true ownership for SSL domain name applications. As I've repeatedly referenced ... this puts the CAs in catch22 ... they need improved integrity of domain name infrastructure (attacks on ownership records of domain name ownership and then being issued valid SSL certificate) ... which comes with lots of DNSSEC ... but that also eliminates much of the need for SSL domain certificates. as per prior reference about original working on SSL for electronic commerce ... at least for the financial industry I've repeatedly shown that digital certificates were redundant and superfluous. I also shown that at the time, the addition of digital certificates increased the payload size by two orders of magnitude (besides being redundant and superfluous). That apparently motivated the compressed digital certificate financial standard effort ... trying to reduce digital certificates so that the payload bloat was only ten times (instead of hundred times) ... in large part by eliminating all information that the processing institution already had. I demonstrated that processing institution would have all information and therefor digital certificates could be reduced to zero bytes ... so instead of eliminating redundant and superfluous digital certificates ... it was possible to mandate that zero byte certificates be appended to every transaction (it would be possible to digitally sign a payment transaction for authentication ... and rely on the individual's financial institution to have registered the person's public key ... w/o having to increase the size of every payment transaction in the world by 100 times just to transmit a redundant and superfluous appended digital certificate). I like the interchange at panel discussion in early 90s ACM SIGMOD ballroom open session, somebody in the audience asked what was all this x.5xx stuff about and one of the panelists said it was a bunch of networking engineers trying to reinvent 1960s database technology. there was some amount of participation by the information assurance directorate in financial industry standards meetings. at various times there were references to rifts between IA and SIGINT ... but for all I know that may be kabuki theater. I was fairly vocal about any backdoors could put financial industry at risk for bad guys discovering the vulnerabilities ... and wanted KISS applied to as much as possible (and backdoors forbidden) there are other agendas in much of this. at the start of the century there were several safe internet payment products pitched to major merchants (accounting for 70% of internet transactions) which got high acceptance. Merchants have been indoctrinated for decades that a large part of interchange fee is proportional to associated fraud rate ... and the merchants were expecting an order of magnitude reduction in their fees (with the safe products). Then came the cognitive dissonance when the banks told the merchants that rather than major reduction in interchange fees with the safe payment products ... there would effectively be a surcharge added to the highest fee that they were already paying (and all the safe efforts collapse). Part of the issue was that the bottom line for large issuing banks was 40%-60% from these fees and an order of magnitude reduction in those fees would be a big hit to their bottom line (the size of fees in part justified by fraud rates). The safe products going a long way to eliminating most fraud and commoditizing the payment transaction business ... which would also lower the bar for entry by competition. -- virtualization experience starting Jan1968, online at home since Mar1970 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd: NYTimes.com: N.S.A. Foils Much Internet Encryption)
we were brought in as consultants to a small client/server startup that wanted to do payment transactions on their server, they had this technology they called SSL they wanted to use, the result is now frequently called electronic commerce. The two people at the startup responsible for the commerce server we had worked with in prior life on parallel Oracle cluster scaleup. As part of mapping SSL technology to payment transactions we had to audit operations selling SSL digital certificates and also came up with recommendations on how browsers and servers would deploy and use the technology. Almost immediately several of the recommendations were violated, resulting in some number of the exploits that continue to this day. We were then tangentially involved in the Cal. data breach notification legislation, having been brought in to help wordsmith the Cal. electronic signature legislation. Many of the parties were heavily involved in privacy issues and had done numerous, indepth, public surveys. The number one issue was identity theft of the form involving fraudulent financial transactions ... frequently as result of data breach. The issue was nothing was being done about the problems and so it was hoped that the publicity from the notifications might motivate corrective action. Part of the issue is normally institutions take security measures in self-interests ... however, the institutions having breaches weren't at risk, it was the account holders. PCI DSS shows up some time after Cal. data breach notification and frequently the joke is that if you have a breach ... you loose your PCI DSS certification. It turns out that there was a number of Federal data breach notification bills introduced, preempting state legislation and effectively eliminating notification requirements ... citing PCI DSS industry effort as justification for no longer needing notification. Another problem we've frequently pointed out is current paradigm with dual use paradigm and even if the planet was covered in miles of information hiding encryption, it wouldn't stop data leakage. Account information is used for authenticating new transactions and so has a requirement that it be kept totally confidential and never divulged to anybody ... but at the same time, account information is needed in dozens of business processes at millions of locations around the planet. disclaimer: we were co-authors of the x9.59 financial transaction standard that slightly tweaked the current payment paradigm and eliminated the dual-use characteristic which then also eliminated the need to hide account information and as a result it also eliminated the need for SSL to hide account information in electronic commerce transactions eliminating the major requirement for SSL in the world today. -- virtualization experience starting Jan1968, online at home since Mar1970 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] NSA and cryptanalysis
recent post with email discussing PGP-like implementation ... a decade before PGP in financial crypto blog http://www.garlic.com/~lynn/2013i.html#69 and then a little later realizing there were 3-kinds of crypto (when I was told I could make as many boxes as I wanted ... but could only sell to a certain gov. agency). In the late 90s, I worked on crypto chip for financial applications ... I would facetiously talk about taking a $500 mil-spec chip and cost reduce by 2-3 orders of magnitude while making it more secure (final objective was well under a dollar). Part of the objective was also to eliminate all the vulnerabilities that payment chips being done primarily in Europe were prone too. Long winded thread in financial crypto blog http://www.garlic.com/~lynn/subintegrity.html#yescard About that time, I was also approached by the transit industry to make the payment chip meet transit turnstyle requirements (while not reducing any security) ... this was a contactless chip being able to do crypto operation in 1/10th sec elapsed time and power profile of contactless transit turnstyle operation. RSA chips at the time were really large implementing 1024-bit arithmatic requiring enormous power and contact operation to get time in a few seconds. It turns out I could have a AADS chip strawman with ECC that was higher integrity *AND* could meet the transit industry turnstyle contactless power elapsed time profile. some past references to AADS chip strawman http://www.garlic.com/~lynn/x959.html#aadsstraw I was also asked to give presentation at Intel trusted computing ... gone 404 but lives on at wayback machine http://web.archive.org/web/20011109072807/http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp+s13 one of the problems in the early part of the century was that I wanted to go for higher than EAL4+ evaluation ... but NIST(somebody) pullled the ECC evaluation criteria ... and since ECC was part of the chip silicon ... w/o the ECC evaluation criteria ... I had to settle for EAL4+. Possibly part of the issue with AADS chip strawman was I approached it as purely a cost issue ... and the objective was to eliminate all possible costs from the whole infrastructure ... the side effect of course, it also eliminated all related profit. -- virtualization experience starting Jan1968, online at home since Mar1970 ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On 08/26/2010 06:38 AM, d...@geer.org wrote: While I am *not* arguing that point, per se, if having a better solution would require, or would have required, no more investment than the accumulated profits in the sale of SSL domain name certs, we could have solved this by now. the profit from sale of SSL domain name certs had profit motivation pretty much unrelated to the overall costs to the infrastructure ... and so there was an extremely strong champion. simply enhancing DNS and doing real-time trusted public key distribution thru a trusted domain name infrastructure ... was all cost with no champion with strong profit motivation. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security
On 08/25/2010 10:40 PM, James A. Donald wrote: This is inherent in the layering approach - inherent in our current crypto architecture. one of the things ran into the (ISO chartered) ANSI X3S3.3 (responsible for standards related to OSI level3 level4) meetings with regard to standardization of HSP (high speed protocol) ... was that ISO had policy that it wouldn't do standardization on things that violated OSI model. HSP violated OSI model by (and was turned down by X3S3.3) 1) went directly from level 4/5 interface to the MAC interface (bypassing OSI level 3/4 interface) 2) supported internetworking ... which doesn't exist in OSI model ... would set in non-existing layer between level3 level4 3) went directly to MAC interface ... which doesn't exist in OSI mdoel ... something that sits approx. in the middle of layer3 (above link layer and includes some amount of network layer). In the IETF meetings at the time of original SSL/TLS ... my view was that ipsec wasn't gaining tranction because it required replacing parts of tcp/ip kernel stack (upgrading all the kernels in the world was much more expensive then than it is now). That year two things side-stepped the ipsec upfront kernel stack problem * SSL ... which could be deployed as part of the application w/o requiring changes to existing infrastructure * VPN ... introduced in gateway sesssion at fall94 IETF meeting. This was implemented in gateway routers w/o requiring any changes to existing endpoints. My perception was that it upset the ipsec until they started referring to VPN as lightweight ipsec (but that opened things for ipsec to be called heavyweight ipsec). There was a problem with two classes of router/gateway vendors ... those with processors that could handle the crypto load and those that had processors that could handle the crypto load. One of the vendors that couldn't handle the crypto load went into standards stalling mode and also a month after the IETF meeting announced a VPN product that involved adding hardware link encryptors (which would then required dedicated links between the two locations as opposed to tunneling thru the internet. I would contend that various reasons why we are where we are ... include solutions that have champions with profit motivation as well as things like ease of introduction ... and issues with being able to have incremental deployments with minimum disruption to existing facilities (like browser application based solution w/o requiring any changes to established DNS operation). On the other hand ... when we were brought in to consult with the small client/server startup that wanted to do payment transactions (and had also invented SSL) ... I could mandate multiple A-record support (basically alternative path mechanism) for the webserver to payment gateway TCP/SSL connections. However, it took another year to get their browser to support multiple-A record (even when supplying them with example code from TAHOE 4.3 distribution) ... they started out telling me that multiple-A record technique was too advanced. An early example requirement was one of the first large adopters/deployments for e-commerce server, advertized on national sunday football and was expecting big e-commerce business during sunday afternoon halftime. Their e-commerce webserver had redundant links to two different ISPs ... however one of the ISPs had habit of taking equipment down during the day on sunday for maintenance (w/o multiple-A record support, there was large probability that significant percentage of browsers wouldn't be able to connect to the server on some sunday halftime). -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
On 08/25/2010 09:04 AM, Richard Salz wrote: Also, note that HSTS is presently specific to HTTP. One could imagine expressing a more generic STS policy for an entire site A really knowledgeable net-head told me the other day that the problem with SSL/TLS is that it has too many round-trips. In fact, the RTT costs are now more prohibitive than the crypto costs. I was quite surprised to hear this; he was stunned to find it out. Look at the tlsnextprotonec IETF draft, the Google involvement in SPDY, and perhaps this message as a jumping-off point for both: http://web.archiveorange.com/archive/v/c2Jaqz6aELyC8Ec4SrLY I was happy to see that the interest is in piggy-backing, not in changing SSL/TLS. the work on HSP (high-speed protocol) in the late 80s was to do reliable transmission in minimum 3-packet exchange; compared to 5-packet minimum for VMTP (rfc1045) and 7-packet minimum for tcp (disclaimer, i was on related technical advisory board for HSP ... while at IBM ... over strong objections from the communication division; but that also strong protested that we had come up with 3-tier architecture and were out pitching it to customer executives ... at a time when they were attempting to get the client/server genie back into the terminal emulation bottle) then SSL theoretically being stateless on top of tcp added a whole bunch of additional chatter. there has frequently between changing trade-offs between transmission and processing ... but SSL started out being excessive in both transmission and processing (in addition to having deployment requirement that the user understand the relationship between the website they believed they were talking to and the URL they had to supply to the browser a requirement that was almost immediately violated). my pitch forever has been to leverage key distribution piggy-backed on domain name to ip-address (dns) response ... and use that to do encrypted/validated reliable transaction within HSP 3-packet minimum exchange. as previously mentioned, somewhere back behind everything else ... there is strong financial motivation in the sale of the SSL domain name digital certificates. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On 08/13/2010 03:16 PM, Chris Palmer wrote: When was this *ever* true? Seriously. re: http://www.garlic.com/~lynn/2010m.html#50 ... original design/implementation. The very first commerce server implementation by the small client/server startup (that had also invented SSL) ... was mall paradigm, development underwritten by large telco (they were looking at being major outsourcer of electronic commerce servers) ... then the individual store implementation was developed. we had previously worked with two people responsible for commerce server (at small client/server startup) on ha/cmp ... they are mentioned in this old posting about jan92 meeting in ellison's conference room http://www.garlic.com/~lynn/95.html#13 they then left to join the small client/server startup ... and we also leave what we had been doing. we then get brought in as consultants because they want to do payment transactions on their server ... wanting to use this technology called SSL that had been invented at the startup. We have to go thru the steps of mapping the technology to payment business processes ... including backend use involving the interaction between commerce servers and the payment gateway; the payment gateway sitting on the internet and interface to acquiring network backends ... misc. past posts mentioning payment gateway http://www.garlic.com/~lynn/subnetwork.html#gateway we also have to do walkthru/audits of several of these new businesses calling themselves Certification Authorities that were selling SSL domain name digital certificates ... some past posts http://www.garlic.com/~lynn/subpubkey.html#sslcerts approx. in the same era, but not exactly the same time (when webservers were seeing the ssl cryptographic load dropping back to only using it for payment) ... some of the larger websites were starting to first see a plain tcp/ip scaleup issue ... having to do with tcp being originally designed as session protocol ... and was effectively being misused by HTTP. As a result most vendor implementations hadn't optimized session termination ... which was viewed as infrequent event (up until HTTP). There was six month period or so ... that the large websites saw their processors spending 90-95% of the cpu running the FINWAIT list (as part of session termination). The small client/server startup was also seeing (other) scaleup problems in their server platforms used for downloading products (especially browser product download activity) ... and in constant cycle of adding servers. This was before rotating front-ends ... so users were asked to manually specify URL of specific server. Their problem somewhat cleared up when they installed a large sequent box ... both because of the raw power of the sequent server ... and also because sequent claimed to have addressed the session terminal efficiency sometime previously (related to commercial unix accounts with 20,000 concurrent telnet sessions). For other topic drift ... I believe the first rotating, load-balancing front-ends was with custom modified software for routers at google. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Has there been a change in US banking regulations recently?
On 08/13/2010 02:12 PM, Jon Callas wrote: What on earth happened? Was there a change in banking regulations in the last few months? Possibly it's related to PCI DSS and other work that BITS has been doing. Also, if one major player cleans up their act and sings about how cool they are, then that can cause the ice to break. Another possibility is that a number of people in financials have been able to get security funding despite the banking disasters because the risk managers know that the last thing they need is a security brouhaha while they are partially owned by government and thus voters. I bet on synergies between both. If I were a CSO at a bank, I might encourage a colleague to make a presentation about how their security cleanups position them to get an advantage at getting out from under the thumb of the feds over their competitors. Then I would make sure the finance guys got a leaked copy. Jon the original requirement for SSL deployment was that it was on from the original URL entered by the user. The drop-back to using SSL for only small subset ... was based on computational load caused by SSL cryptography in the online merchant scenario, it cut thruput by 90-95%; alternative to handle the online merchant scenario for total user interaction would have required increasing the number of servers by factor of 10-20. One possibility is that the institution has increased the server capacity ... and/or added specific hardware to handle the cryptographic load. A lot of banking websites are not RYO (roll-your-own), internally developed ... but stuff they by from vendor and/or have the website wholly outsourced. Also some number of large institutions have their websites outsourced to vendors with large replicated sites at multiple places in the world ... and users interaction gets redirected to the closest server farm. I've noticed this periodically when the server farm domain name and/or server farm SSL certificate bleeds thru ... because of some sort of configuration and/or operational problems (rather than seeing the institution SSL certificate that I thot I was talking to). Another possibility is that the vendor product that they may be using for the website and/or the outsourcer that is being used ... has somehow been upgraded (software /or hardware). -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Zeus malware used pilfered digital certificate http://www.computerworld.com/s/article/9180259/Zeus_malware_used_pilfered_digital_certificate Zeus Malware Used Pilfered Digital Certificate http://www.pcworld.com/businesscenter/article/202720/zeus_malware_used_pilfered_digital_certificate.html Zeus malware used pilfered digital certificate http://www.networkworld.com/news/2010/080610-zeus-malware-used-pilfered-digital.html from above: The version of Zeus detected by Trend Micro had a digital certificate belonging to Kaspersky's Zbot product, which is designed to remove Zeus. The certificate -- which is verified during a software installation to ensure a program is what it purports to be -- was expired, however. ... snip ... Certificate Snatching—ZeuS Copies Kaspersky’s Digital Signature http://blog.trendmicro.com/certificate-snatching-zeus-copies-kasperskys-digital-signature/ ... there was another scenario of certificate-copying ( dual-use vulnerability) discussed in this group a while ago. The PKI/certificate bloated payment specification had floated the idea that that when payment was done with their protocol, dispute burden-of-proof would be switched placed on the consumer (from the current situation where burden-of-proof is on the merchant/institution; this would be a hit to REG-E ... and also apparently what has happened in the UK with the hardware token point-of-sale deployment). However, supposedly for this to be active, the payment transaction needed a consumer appended digital certificate that indicated they were accepting dispute burden-of-proof. The issue was whether the merchant could reference some public repository and replace the digital certificate appended by the consumer ... with some other digital certificate for the same public key (possibly digital certificate actually obtained by the consumer for that public key at some time in the past ... or an erroneous digital certificate produced by a sloppy Certification Authority that didn't adequately perform check for applicant's possession of the corresponding private key). Of course, since the heavily bloated PKI/certificate payment specification, performed all PKI-ops at the internet boundary ... and then passed a normal payment transaction with just a flag claiming that PKI-checking had passed ... they might not need to even go that far. There was already stats on payment transactions coming thru with the flag on ... and they could prove no corresponding PKI-checking had actually occurred. With the burden-of-proof on consumer ... the merchant might not even have to produce evidence that the appended digital certificates had been switched. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Kaspersky: Sham Certificates Pose Big Problem for Windows Security http://www.ecommercetimes.com/story/70553.html from above .. Windows fails to clearly indicate when digital security certificates have been tampered with, according to Kaspersky Lab's Roel Schouwenberg, and that opens a door for malware makers. ... snip ... -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Five Theses on Security Protocols
On 08/01/2010 01:51 PM, Jeffrey I. Schiller wrote: I remember them well. Indeed these protocols, presumably you are talking about Secure Electronic Transactions (SET), were a major improvement over SSL, but adoption was killed by not only failing the give the merchants a break on the fraud surcharge, but also requiring the merchants to pick up the up-front cost of upgrading all of their systems to use these new protocols. And there was the risk that it would turn off consumers because it required the consumers setup credentials ahead of time. So if a customer arrived at my SET protected store-front, they might not be able to make a purchase if they had not already setup their credentials. Many would just go to a competitor that doesn't require SET rather then establish the credentials. SET specification predated these (as also internet specific, from the mid-90s, went on currently with x9a10 financial standards work ... which had requirement to preserve the integrity for *ALL* retail payments) ... the decade past efforts were later were much simpler and practical ... and tended to be various kinds of something you have authentication. I'm unaware of any publicity and/or knowledge about these payment products (from a decade ago) outside the payment industry and select high volume merchants. The mid-90s, PKI/certificate-based specifications tended to hide behind a large amount of complexity ... and provide no effective additional benefit over above SSL (aka with all the additional complexity ... did little more than hide the transaction during transit on the internet). They also would strip all the PKI gorp off at the Internet boundary (because of the 100 times payload size and processing bloat that the certificate processing represented) and send the transaction thru the payment network with just a flag indicating that certificate processing had occurred (end-to-end security was not feasible). Various past posts mentioning the 100 times payload size and processing bloat that certificates added to typical payment transactions http://www.garlic.com/~lynn/subpubkey.html#bloat In the time-frame of some of the pilots, there were then presentation by payment network business people at ISO standards meetings that they were seeing transactions come thru the network with the certificate processed flag on ... but could prove that no certificate processing actually occurred (there was financial motivation to lie since turning the flag on lowered the interchange fee). The certificate processing overhead also further increased the merchant processing overhead ... in large part responsible for the low uptake ... even with some benefit of lowered interchange fee. The associations looked at providing additional incentive (somewhat similar to more recent point-of-sale, hardware token incentives in europe), effectively changing the burden of proof in dispute (rather than the merchant having to prove the consumer was at fault, the consumer would have to prove they weren't at fault; of course this would have met with some difficulty in the US with regard to regulation-E). Old past thread interchange with members of that specification team regarding the specification was (effectively) never intended to do more than hide the transaction during transnmission: http://www.garlic.com/~lynn/aepay7.htm#norep5 non-repudiation, was re: crypto flaw in secure mail standards aka high-overhead and convoluted, complex processing of the specification provided little practical added benefit over and above what was already being provided by SSL. oblique reference to that specification in recent post in this thread regarding having done both a PKI-operation benchmark (using BSAFE library) profile as well as business benefit profile of the specification (when it was initially published ... before any operational pilots): http://www.garlic.com/~lynn/2010l.html#59 A mighty fortress is our PKI with regard specifically to BSAFE processing bloat referenced in the above ... there is folklore that one of the people, working on the specification, admitted to a adding a huge number of additional PKI-operations (and message interchanges) to the specification ... effectively for no other reason than the added complexity and use of PKI-operations. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Five Theses on Security Protocols
minor addenda about speeds feeds concerning the example of mid-90s payment protocol specification that had enormous PKI/certificate bloat ... and SSL. The original SSL security was predicated on the user understanding the relationship between the webserver they thought they were talking to, and the corresponding URL. They would enter that URL into the browser ... and the browser would then establish that the URL corresponded to the webserver being talked to (both parts were required in order to create an environment where the webserver you thot you were talking to, was, in fact, the webserver you were actually talking to). This requirement was almost immediately violated when merchant servers found that using SSL for the whole operation cost them 90-95% of their thruput. As a result, the merchants dropped back to just using SSL for the payment part and having a user click on a check-out/payment button. The (potentially unvalidated, counterfeit) webserver now provides the URL ... and SSL has been reduced to just validating that the URL corresponds to the webserver being talked to (or validating that the webserver being talke d to, is the webserver that it claims to be; i.e. NOT validating that the webserver is the one you think you are talking to). Now, the backend of the SSL payment process was SSL connection between the webserver and a payment gateway (sat on the internet and acted as gateway to the payment networks). Moderate to heavy load, avg. transaction elapsed time (at payment gateway, thru payment network) round-trip was under 1/3rd of second. Avg. roundtrip at merchant servers could be a little over 1/3rd of second (depending on internet connection between the webserver and the payment gateway). I've referenced before doing BSAFE benchmarks for the PKI/certificate bloated payment specification ... and using a speeded up BSAFE library ... the people involved in the bloated payment specification claimed the benchmark numbers were 100 times too slow (apparently believing that standard BSAFE library at the time ran nearly 1000 times faster than it actually did). When pilot code (for the enormously bloated PKI/certificate specification) was finally available, using BSAFE library (speedup enhancements had been incorporated into standard distribution) ... dedicated pilot demos for transaction round trip took nearly minute elapsed time ... effectively all of it was BSAFE computations (using dedicated computers doing nothing else). Merchants that found using SSL for the whole consumer interaction would have required ten to twenty times the number of computers ... to handle equivalent non-SSL load ... were potentially being faced with needing hundreds of additional computers to handle just the BSAFE computational load (for the mentioned extremely PKI/certificate bloated payment specification) ... and still wouldn't be able to perform the transaction anywhere close to the elapsed time of the implementation being used with SSL. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/28/2010 08:55 AM, Anne Lynn Wheeler wrote: disclaimer: the inventor of domain name infrastructure did a stint at the science center a decade earlier ... working on various and sundry projects. other public key science center trivia; former RSA CEO also at science center ... following recent entry from his blog: http://smartphonestechnologyandbusinessapps.blogspot.com/2010/05/bob-creasy-invented-virtual-machines-on.html lots of past posts mentioning science center, 4th flr, 545 tech sq http://www.garlic.com/~lynn/subtopic.html#545tech a couple old emails from 1981 ... discussing a certificate-less, PGP-like implementation for the internal network http://www.garlic.com/~lynn/2007d.html#email810506 http://www.garlic.com/~lynn/2006w.html#email810515 ... aka the internal network was larger than the arpanet/internet from just about the beginning until sometime late '85 or early '86. one big difference from arpanet/internet was corporation required all links to be encrypted ... and in the mid-80s there was the claim that the internal network had over half of all hardware link encryptors in the world ... only practical solution at the time. I was running multiple T1 links in the period ... and DES-encryption processing for sustained full-duplex traffic from a single T1 link was more than enough to consume multiple mainframe processors. old email on the subject (regarding doing some benchmarking of DES software encrypt/decrypt) http://www.garlic.com/~lynn/2006n.html#email841115 past posts mentioning internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Five Theses on Security Protocols
corollary to security proportional to risk is parameterized risk management ... where variety of technologies with varying integrity levels can co-exist within the same infrastructure/framework. transactions exceeding particularly technology risk/integrity threshold may still be approved given various compensating processes are invoked (allows for multi-decade infrastructure operation w/o traumatic dislocation moving from technology to technology as well as multi-technology co-existence). in the past I had brought this up to the people defining V3 extensions ... early in their process ... and they offered to let me do the work defining a V3 integrity level field. My response was why bother with stale, static information when real valued operations would use much more capable dynamic, realtime, online process. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 07/28/2010 11:52 PM, Pat Farrell wrote: A lot of the smart card development in the mid-90s and beyond was based on the idea that the smart card, in itself, was the sole authorization token/algorithm/implementation. some ssl, payment, smartcard trivia ... those smartcards were used for the offline authorization (not just authentication) ... which, in at least one major product, led to the YES CARD ... relatively trivial to skim replicated a static digital certificate for a counterfeit card ... then the counterfeit card was programmed to answer YES to 1) was the correct PIN entered, 2) should the transaction be performed offline, and 3) was the transaction approved. Once the static digital certificate was skimmed, it was no longer even necessary to know the PIN, since the counterfeit card accepted every possible PIN as valid. misc. past posts mentioning YES CARD http://www.garlic.com/~lynn/subintegrity.html#yescard In a 2003, at an ATM Integrity task force meeting ... there was presentation by some LEO explaining the yes card ... and how there was little or no countermeasure once a YES CARD was in existence ... somebody in the audience loudly observed that billions were spent on proving smartcards are less secure than magstripe. In the YES CARD timeframe there was even a rather large pilot of the cards in the US ... but seemed to disappear after the YES CARD scenario was publicized (it was actually explained to the people doing the pilot, before the pilot started ... but apparently they didn't appreciate the significance). much earlier, we had been working on our ha/cmp product and cluster scaleup. we had meeting on cluster scaleup meeting during jan92 sanfran usenet (in ellison's conference room) ... past posts mentioning the jan92 meeting http:www/garlic.com/~lynn/95.html#13 this was just a few weeks before cluster scaleup was transferred (announced as supercomputer for numerical intensive only) and we were told we couldn't work on anything with more than four processors. some old email from the period on cluster scaleup http://www.garlic.com/~lynn/lhwemail.html#medusa we then leave a couple months later. two of the other people named in the jan92 meeting also leave and show up at small client/server startup responsible for something called commerce server. we get brought in to consult because they want to do payment transactions on the server ... the small client/server startup has also invented some technology called SSL they want to use. The results is now frequently called electronic commerce. Then apparently because of the work on electronic commerce ... we also get invited to participate in the x9a10 financial standard working group ... which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. About the same time there is a pilot program for magstripe-based online stored-value cards (uses existing POS magstripe terminals but the payment network routes the transactions to different backend processor, original program of its kind in the US). At the time, the US didn't have the telco connectivity availability and cost issues that many places in the rest of the world were dealing with ... and therefor didn't have that requirement to move to offline smartcard payment paradigm. However, it turns out their backend, high-availability, no-single-point-of-failure platform developed a glitch ... and even tho it was from a different vendor (than our ha/cmp product) we were asked to investigate at the various failure modes. Somewhat as a result of all of the above, when one of the major offline, smartcard, european, stored-value payment operators was looking at making an entry into the US in the 90s ... we were asked to design, size, and cost their backend dataprocessing infrastructure. Along the way, we took an indepth look at the business process and cost structure of such payment products. Turns out that the major financial motivation for that generation of smartcard stored-value payment products ... was that the operators got to keep the float on the value resident in the stored-value cards. Not too long later ... several of the major european central banks announced that the smartcard, stored-value operators would have to start paying interest on value in the smartcards (eliminating the float financial incentive to those operators). It wasn't too long after that most of the programs disappeared. The major difference between that generation of smartcard payment products and the AADS chip strawman ... was that rather than attempting to be a complex, loadable, multi-function issuer card the objective was changed to being a person-centric, highest-possible integrity, lowest-possible cost, hard-to-counterfeit authentication ... which could be registered (publickey) for arbitrary number of different environments (something you have authentication registered in manner analogous to
Re: A mighty fortress is our PKI, Part II
On 07/28/2010 11:52 PM, Pat Farrell wrote: I'd like to build on this and make a more fundamental change. The concept of a revocation cert/message was based on the standard practices for things like stolen credit cards in the early 1990s. At the time, the credit card companies published telephone book sized listings of stolen and canceled credit cards. Merchant's had the choice of looking up each card, or accepting a potential for loss. A lot of the smart card development in the mid-90s and beyond was based on the idea that the smart card, in itself, was the sole authorization token/algorithm/implementation. that was one of my points ridiculing PKI in the mid-90s ... that the CRL was a return to offline point-of-sale payment operation ... and seemed to motivate the work on OCSP. The difference was that in the move to real-time online transactions ... it got much high quality operation ... not only could it establish real-time valid/not-valid ... but also other real-time characteristics like real-time credit limit, recent pattern of transactions, and much more. by comparison, OCSP was an extremely poor man's real-time, online transaction smartcard payment cards started out being stand-alone stored-value to compensate for the extremely expensive and limited availability of point-of-sale in much of the world ... aka it was stored-value operation where the operation could be performed purely offline (the incremental cost of the smartcard chip was offset by savings not requiring realtime, online transaction). The telco economics didn't apply to the US ... as seen by the introduction of stored-value magstripe based payment cards in the US that did real-time, online transaction ... which served the same market niche that the offline smartcard was performing in other parts of the world. Between the mid-90s and now, telco costs connectivity has significantly changed around the world ... pervasive uniquitness of the internet, cellphone coverage, wireless, ... lots of things. The common scenario in the past couple decades ... was looking to add more more feature/function to smartcards to find the magical economic justification ... unfortunately, the increase in feature/function tended to also drive cost ... keeping the break even point just out of reach. Part of the certificateless public key work was to look at chips as a cost item (rather than profit item ... since lots of the smartcard work was driven by entities looking to profit by smartcard uptake). The challenge was something that had stronger integrity than highest rated smartcard but at effective fully loaded cost below magstripe (i.e. I had joked about taking a $500 milspec part, cost reducing by 3-4 orders of magnitude while improving the integrity). Another criteria was that it had to work within the time power constraints of a (ISO14443) contactless transit turnstyle ... while not sacrificing any integrity security. By comparison ... one of the popular payment smartcards from the 90s looked at the transit turnstyle issue ... and proposed a wireless sleeve for their contact card ... and 15ft electromagnetic tunnels on the approach to each transit turnstyle ... where public would walk slowly thru the tunnel ... so that the transaction would have completed by the time the turnstyle was reached. Part of achieving lower aggregate cost than magstripe ... was that even after extremely aggressive cost reduction, the unit cost was still 2-3 times that of magstripe ... however, if the issuing frequency could be reduced (for chip)... it was more than recouped (i.e. magstripe unit cost is possibly only 1% of fully loaded issuing costs). Changing the paradigm from institutional-centric (i.e. institution issued) to person-centric (i.e. person uses the same unit for multiple purposes and with multiple institutions) ... saves significant amount more (replaces an issuing model with a registration model). Turns out supposedly a big issue for a transition from an institution-centric (institution issuing) to person-centric paradigm ... was addressing how can the institution trust the unit being registered. Turns out that trust issue may have been obfuscation ... after providing a solution to institution trust ... there was continued big push back to moving off an institutional issuing (for less obvious reasons) ... some of the patent stuff (previous mentions) covered steps for moving to person-centric paradigm (along with addressing institutional trust issues). Part of it involved tweaking some of the processes ... going all the way back to while the chip was still part of wafer (in chip manufacturing ... and doing the tweaks in such a way that didn't disrupt standard chip manufacturing ... but at the same time reduced steps/costs). -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List
Re: A slight modification of my comments on PKI.
On 07/28/2010 10:34 PM, d...@geer.org wrote: The design goal for any security system is that the number of failures is small but non-zero, i.e., N0. If the number of failures is zero, there is no way to disambiguate good luck from spending too much. Calibration requires differing outcomes. Regulatory compliance, on the other hand, stipulates N==0 failures and is thus neither calibratable nor cost effective. Whether the cure is worse than the disease is an exercise for the reader. another design goal for any security system might be security proportional to risk. the major use of SSL in the world today is hiding financial transaction information ... currently mostly credit card transactions. One of the issues is that the value of the transaction information to the merchants (paying for majority of the infrastructure) is the transaction profit ... which can be a dollar or two. The value of the transaction information to the attackers is the associated account limit/balance, which can be several hundred to several thousand dollars. This results in a situation where the attackers can afford to outspend the defenders by 100 times or more. somewhat because of the work on the current payment transaction infrastructure (involving SSL, by the small client/server startup that had invented SSL), in the mid-90s, we were invited to participate in the x9a10 financial standard working group (which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments). the result was the x9.59 financial transaction standard. Part of the x9.59 financial transaction standard was slightly tweaking the paradigm and eliminating the value of the transaction information to the attackers ... which also eliminates the major use of SSL in the world today. It also eliminates the motivation behind the majority of the skimming and data breaches in the world (attempting to obtain financial transaction information for use in performing fraudulent financial transactions). note the x9.59 didn't do anything to prevent attacks on SSL, skimming attacks, data breaches, etc ... it just eliminated the major criminal financial motivation for such attacks. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A slight modification of my comments on PKI.
for the fun of it ... from today ... Twenty-Four More Reasons Not To Trust Your Browser's Padlock http://blogs.forbes.com/firewall/2010/07/29/twenty-four-more-reasons-not-to-trust-your-browsers-padlock/?boxes=Homepagechannels from above: On stage at the Black Hat security conference Wednesday, Hansen and Sokol revealed 24 new security issues with SSL and TLS, the digital handshakes that browsers use to assure users they're at a trusted site and that their communication is encrypted against snoops. ... snip ... adding further fuel to long ago motivation that prompted me to coin the term merchant comfort certificates. ... as an aside, we were tangentially involved in the cal. data breach notification legislation. we had been brought in to help wordsmith the cal. electronic signature act ... and some of the participants were heavily involved in privacy issues. They had done in-depth consumer privacy studies and the number one issue came up identity theft, namely the account fraud form where criminals use account /or transaction information (from data breaches) to perform fraudulent financial transactions. It appeared that little or nothing was being done about such data breaches ... and they appeared to believe that the publicity from the data breach notifications would motivate corrective action to be taken (and as mention in previous post ... we took a slightly different approach to the problem in the x9.59 financial transaction standard ... eliminating the ability of crooks to use such information for fraudulent transactions). -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/28/2010 12:10 AM, Paul Tiemann wrote: I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...) Another thought: Maybe this has been thought of before, but what about emulating the Sender Policy Framework (SPF) for domains and PKI? Allow each domain to set a DNS TXT record that lists the allowed CA issuers for SSL certificates used on that domain. (Crypto Policy Framework=CPF?) cpf.digicert.com IN TXT v=cpf1 /^DigiCert/ -all Get the top 5 browsers to support it, and a lot of that any CA can issue to any domain risk goes way down. Thought: Could you even list your own root cert there as an http URL, and get Mozilla to give a nicer treatment to your own root certificate in limited scope (inserted into some kind of limited-trust cert store, valid for your domains only) Is there a reason that opportunistic crypto (no cert required) hasn't been done for https? Would it give too much confidence to people whose DNS is being spoofed? Part of SSL was countermeasure to perceived weakness in domain name infrastructure ... is the server that I think I'm talking to really the server I'm talking to (things like ip-address hijacking). Now Certification Authorities typically aren't the authoritative agency for the information they are certifying ... they ask for a whole bunch of information from an SSL certificate applicant and then perform and expensive, time-consuming, and error-prone identification process, x-checking the supplied information with the information on-file at the domain name infrastructure as to the true owner of a domain (the same domain name infrastructure that has the weaknesses that SSL is designed as countermeasure). So ... something that could be backed by the Certification Authority industry as part of DNSSEC is to ask that all domain name applicants also register a public key as part of obtaining a domain name. domain name infrastructure then can required that all subsequent communication be digitally signed ... and can be verified with the onfile public key (as countermeasure to various kinds of domain name hijacking exploits, hijack domain and then apply for valid SSL certificate using dummy front company which matches the corrupted onfile information). The Certification Authority industry then could take advantage of the same infrastructure and require that all SSL domain name certificate applications, also be digitally signed (and can be verified with the onfile public key at the domain name infrastructure); replacing a time-consuming, expensive, error-prone identification process with an efficient, inexpensive, reliable authentication process. The catch-22 for the industry is if the Certification Authority industry could start doing real-time, online retrieval of public keys for authentication ... then maybe the rest of the world might also ... changing SSL to a certificateless, real-time, online publickey infrastructure. One of the possible reasons that it hasn't happened is there no startup, venture capital, IPO ... etc, gorp associated with such an incremental enhancement to the existing domain name infrastructure (it is a pure security/integrity play with no big financial motivation for anybody). W/o startup, venture capital, IPO play ... there is no big marketing budget to blitz the public on how much more comforting things would be (i.e. part of the reason that I coined the term merchant comfort certificates back in the early days). In the late 90s, we got visited by somebody that wanted to explain about the downside our comments could have on some pending Certification Authority IPO (much of internet hype from the period was actually part of IPO-mill money generating machine). I've posted frequently in the past about the catch-22 scenario for the certification authority industry. disclaimer: the inventor of domain name infrastructure did a stint at the science center a decade earlier ... working on various and sundry projects. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 07/28/2010 10:05 AM, Perry E. Metzger wrote: I will point out that many security systems, like Kerberos, DNSSEC and SSH, appear to get along with no conventional notion of revocation at all. long ago and far away ... one of the tasks we had was to periodically go by project athena to audit various activities ... including Kerberos. The original PK-INIT for kerberos was effectively certificateless public key ... aka replace registering a shared-secret password (for authentication) with a public key. There was then some amount of lobbying by the certification authority interests for pk-init to include certificate-based mode of operation (I wrote the draft-words for PK-INIT for inclusion of certificateless ecdsa). An issue with Kerberos (as well as RADIUS ... another major authentication mechanism) ... is that account-based operation is integral to its operation ... unless one is willing to go to a strictly certificate-only mode ... where all information about an individuals authority and access privileges are also carried in the certificate (and eliminate the account records totally). As long as the account record has to be accessed as part of the process ... the certificate remains purely redundant and superfluous (in fact, some number of operations running large Kerberos based infrastructure have come to realize that they have large redundant administrative activity maintaining both the account-based information as well as the duplicate PKI certificate-based information). The account-based operations have sense of revocation by updating the account-based records. This can be done in real-time and at much finer levels of granularity than the primitive, brute-force (PKI) revocation (and replacement). For instance, have you gone over your outstanding balance or credit-limit? ... are you up-to-date with you ISP account? ... or should it just be temporarily suspended bending receipt of funds. Account records can carry other kinds of real-time information ... like whether currently logged on ... and should duplicate, simultaneous logons be prevented (difficult to achieve with redundant and superfluous, stale, static certificates). The higher-value operations tend to be able to justify the real-time, higher quality, and finer grain information provided by an account-based infrastructure ... and as internet and technology has reduced the costs and pervasiveness of such operations ... it further pushes PKI, certificate-based mode of operation further and further into no-value market niches. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 07/28/2010 11:05 AM, Nicolas Williams wrote: Are you arguing for Kerberos for Internet-scale deployment? Or simply for PKI with rp-only certs and OCSP? Or other federated authentication mechanism? Or all of the above? :) as i've mentioned ... the relying-party-only certificates are almost always redundant and superfluous ... except in cases where the relying party can't justify their own repository of information and/or distributed access to such a repository of information. I previously mentioned that in the payment transaction case, even a relying-party-only certificate was a factor of 100-times payload size bloat for typical payment transactions ... aka not only was the certificate redundant and superfluous ... but it represented an enormous (redundant and superfluous) processing burden. I've mentioned a number of times that OCSP appeared after I had repeatedly ridiculed revokation process being archaic backwards step for real-time payment processes. And that even OCSP (with a certificate) is still redundant and superfluous when real-time transaction is being performed using the real information. the other scenario for rpo-certs ... besides for no-value operations ... is when the real infrastructure is down and/or not accessible. But that usually is matter of cost also, some of the higher-value operations have gone to significant redundancy and claim 100% availability. The certificate analogy is still the letters of credit/introduction from sailing ship days ... when the relying-party had no (other) access to first time interaction with complete stranger (and has to fall back to much cruder and lower quality information). There is also some scenario if the respository and the service are co-located ... that when the repository is unavailable the service will also be unavailable ... so there is no requirement for independent source of information. The catch22 for certification authority operation ... is that as they move further further into the no-value market niches (and/or market niches that can't justify the expense of higher quality operation with real-time repository) ... they are forced to cut their fees and indirectly the quality of their operation. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 07/28/2010 12:02 PM, Nicolas Williams wrote: Sorry, but this is wrong. The OCSP protocol itself really is an online certificate status protocol. Responder implementations may well be based on checking CRLs, but they aren't required to be. Don't be confused by the fact that OCSP borrows some elements from CRLs. my OCSP analogy was turning authentication into an end in itself ... basically a new kind of retail store ... instead of retail store that sells some product ... you go in and buy something ... doing a real-time payment transaction; ... there is an authentication store ... convince everybody that they need to walk into their (OCSP) authentication retail store at least once a day to perform an authentication operation (for no other reason that people should get a lot of comfort out of being authenticated at least once a day or more if necessary) ... totally divorced and unrelated to any actual business purpose. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/27/2010 10:11 AM, Peter Gutmann wrote: So a general response to the several well, what would you do? questions is I'm not sure, that's why I posted this to the list. For example should an SSL cert be held to higher standards than the server it's hosted on? In other words if it's easier to compromise a CDN host or (far more likely) a web app on it, does it matter if you're using a Sybil cert? I have no idea, and I'm open to arguments for and against. long ago and far away, we were called in to consult with a small client/server startup that wanted to do payment transactions on their server ... they had also invented this technology called SSL that they wanted to use. As part of applying the technology to the business payment process ... we also had to go around and investigate how some of these new businesses, calling themselves Certification Authorities, operated. In any case, the result is now sometimes called electronic commerce. There were lots of issues with deficiencies and vulnerabilities, resulting in my coining the term merchant comfort certificates ... aka ... as opposed to anything to do with security. Of course, I also suggested that everybody that in anyway touched on the certificates or the merchant servers ... needed to have detail FBI background check. -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/27/2010 12:09 PM, Pat Farrell wrote: Most of which we avoided by skipping the cert concept. Still, better technology has nothing to do with business success. Public Key Crypto with out all the cruft of PKI. Its still a good idea. that became apparent in the use of SSL between all the merchant servers and the payment gateway. by the time the registration and setup process was completed at both ends ... the certificate was purely an artificial attribute of the crypto library being used. there were other issues with the payment gateway protocol ... i was able to mandate things like mutual authentication ... which didn't exist in the crypto library up to that point ... however the exchange of certificates was so engrained that it wasn't possible to eliminate (even tho all the necessary information already existed at both end-points). the merchant server/browser part ... I could only recommend ... I couldn't mandate. my analogy is that certificates PKI are electronic analogy of the letters of credit/introduction from the sailing ship days ... when the relying party had no other recourse for information about the stranger that they were dealing with. This was left over from the dail-up email days of the early 80s (dial-up electronic post-office, exchange email, hangup, and possibly have first-time email from complete stranger). that design point was quickly vanishing in the 90s with the pervasive growth of the online internet. I as at annual ACM sigmod conference in the early 90s ... and one of the big sessions, somebody asked on of the panelists what was all this x.50x gorp about. Eventually somebody explained that it was a bunch of networking engineers attempting to re-invent 1960s database technologies with certificates being armored, stand-alone, stale representation of some information from a database someplace. In the later 90s, certificates attempted to find place in no-value market niches (aka, situations involving no-value operations that couldn't justify online /or real-time information) ... although this got into some conflicts ... trying to address no-value market-niche ... at the same time claiming high-value, expensive operation. There were businesses cases floated to venture community claiming $20B certificate market ... i.e. that every person in the country would have $100/annum certificate ... some predicting that the financial community would underwrite the cost. When that didn't happen, there were other approaches. We had been called in to help wordsmith the cal. state electronic signature legislation ... which was being heavily lobbied by the PKI industry to mandate certificates. I could that rube-goldberg OCSP was response to interaction I had with some of the participants ... somebody bemoaning the fact that the financial industry needed to be brought into 20th century requiring certificates appended to every financial transaction. I responded that stale, static certificates would be retrenching to before the advent of online, real-time point-of-sale payment transactions ... aka a major step backward, not a step forward. Besides the appending a stale, static certificate to every payment transaction being redundant and superfluous ... it also represents enormous overhead bloat. There were some reduced financial, relying-party-only certificates being floated in the mid-90s ... which were still 100 times larger than the typical payment payload size (increase the size of payment transaction payload by a factor of 100 times for no beneficial purpose). The X9 financial standard group ... had some participants recognizing the enormous overhead bloat certificates represented in payments started a compressed certificate standards activity ... possibly looking to reduce the 100 times overhead bloat to only 5-10 times overhead bloat (although still redundant and superfluous). One of their techniques was that all information that was common in every certificate ... could be eliminated. Then all information that the relying party already had could be eliminated. I was able to trivial show, that a relying party would have access to every piece of information in a certificate ... and therefor digital certificates could be compressed to zero bytes. Then rather than arguing whether it was mandated that every payment transaction have an appended certificate ... we could mandate that every payment transaction have a zero-byte appended certificate. disclaimer ... eventually had a couple dozen (assigned, retain no interest) patents in the area of certificate-less public key (some showing up long after we were gone) ... summary here http://www.garlic.com/~lynn/aadssummary.htm -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI
On 07/27/2010 12:09 PM, Pat Farrell wrote: In that same time, I was at CyberCash, we invented what is now sometimes called electronic commerce. and that and $5 will get you a cup of coffee. We predated SSL by a few years. Used RSA768 to protect DES sessions, etc. Usual stuff. somewhat as result of doing the SSL payment stuff ... in the mid-90s got invited to be part of the x9a10 financial standard working group ... which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the result was x9.59 retail payment financial standard ... which was specific in such a way that it would work with any secure authentication (including allowing both certificate certificate-less mode). The business process was slightly tweaked so it was no longer necessary to hide the information in a payment transaction to preserve the financial infrastructure integrity. This didn't eliminate skimming, evesdropping, data breaches ... but it eliminated the ability for the attackers to use the information to perform fraudulent transactions (and effectively also eliminates the major use of SSL in the world ... hiding the information in financial transaction). About the same time the x9a10 standards work was going on ... there were a couple other payment transaction specification work occurring ... which were mandating certificate operation ... somewhat trying to side-step the 100 times payload bloat. they would strip the certificate at internet gateway ... and forward the transaction thru the standard payment network with flag turned on (they could somewhat wave their hands that 100 times payload bloat on the internet was immaterial ... but not so in the real payment network) that certificate processing had occurred (compared to light-weight, super secure, x9.59 ... which operated end-to-end). There were later some presentations at ISO standards meetings that transactions were showing up with the certificate flag on ... but they could prove no certificate had been involved (i.e. there was financial interchange fee benefit motivating turning on the flag). shortly after they had published their (certificate-based) payment specification (but well before any operational code), I did a public-key op profile for their specification. I then got a friend that had a optimized BSAFE library (ran four times faster) to benchmark the profile on lots of different platforms ... and then reported the results to the groups publishing the profile. The response was my numbers were 100 times too slow (if they had actually run any numbers, their comment should have been it was four times too fast). Some six months later when they did have pilot code ... my profile numbers were within a couple percent of actual (i.e. the BSAFE library changes had been incorporated into standard distribution). -- virtualization experience starting Jan1968, online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
GOST RFCs 5830, 5831, 5832
welcome back announcement of RFC 5830, 5831, 5832 in today's RFC distribution abstract for 5830: This document is intended to be a source of information about the Russian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms called GOST algorithms). Recently, Russian cryptography is being used in Internet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication. This document is not an Internet Standards Track specification; it is published for informational purposes. -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On 11/21/2009 04:56 PM, John Levine wrote: we claimed we do something like two orders magnitude reduction in fully-loaded costs by going to no personalization (and other things) ... My concern with that would be that if everyone uses the the same signature scheme and token, the security of the entire industry becomes dependent on the least competent bank in the country not leaking the verification secret. For something like a chip+pin system it is my understanding that the signature algorithm is in the chip and different chips can use different secrets and different algorithms, so a breach at one bank need not compromise all the others. R's, John there is no shared secret ... there is unique chip private/public key generated at power-on/test and the public key was included/transmitted with the test result data as part of the initial power-on/test cycle (this is process that occurs while the chips are still in wafer ... before being sliced diced). the silicon is designed to never (volunteerly) divulge the private key (modulo some extremely heavy duty physical attacks). the patent stuff was all done for employer as assigned patents quite awhile ago (we've been gone for several yrs and the patent stuff keeps going on). initially there was a large number of claims and had gotten to packaged as over 60 patents and looked to be 100 before we were done. about that point, the employer looks at filing costs in the US and international ... and directs that all the claims be packaged as nine patents. Later, the patent office comes back and makes some comment about getting tired of huge patents where the filing fee doesn't even cover the cost of reading all the claims ... and directed that the claims be packaged as larger number of claims. http://www.garlic.com/~lynn/aadssummary.htm while there are claims related to unique devices with unique digital signatures in other applications ... there was a patent application (in our name ... years after we are gone) this year http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PG01p=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmlr=1f=Gl=50s1=%2220090158029%22.PGNR.OS=DN/20090158029RS=DN/20090158029 all the initial chips were ec/dsa (each chip with its own unique public/private key) ... all done in fab that had security certified by US, EU other gov. institutions and also financial institutions (no compromised chips substituted for real ones) ... I even got to walk the fab in bunny suit doing my own certification. if you want different algorithms (or key lengths) ... you have to cut a new mask and make different wafer runs. if the number of wafers in wafer runs are too small ... you would start to drive the cost/chip above a few cents. There is no single-point-of-compromise. Compromising a single chip is equivalent to skimming a single magstripe ... can do fraudulent transactions against the accounts for that chip/token (and chip compromise significantly more difficult than magstripe skimming). In theory there might be weakness found in specific chip or specific algorithm ... but design allows for a large number of different chips and algorithms to interoperate in the same environment. For the initial chips ... I got a EAL4+ common criteria certification (by accredited lab in germany). I wanted a higher certification ... but had a problem that EC/DSA verification suite had been withdrawn. There were some higher certifications on similar chips by others ...but their design involved loading the crypto after the certification (they got certification done on chip before any software loaded). My chip had everything in silicon (all feature/functions) ... and so the certification was done on everything that would be in actual use. in the person-centric scenario ... each chip's private key becomes somewhat akin to fingerprint or iris pattern ... a unique something you have ... as opposed to unique something you are (and much easier to replace/change if there is a specific compromise). some of the patents cover not only recording public key for each account the corresponding token is authorized for (and multiple different tokens might be authorized for same account) ... but also knowledge about the assurance level of the related chip. Real-time updates are then available about chip assurance level ... and real-time authorizations can not only take into account whether the transaction is within the account balance ... but potentially is the assurance level of the chip is high enough for authorizing the transaction. X9.59 financial standard transaction protocol also allows for the environment that the transaction is performed in to also sign the transaction (in addition to the person's chip). Real-time authorization then may take into account both the assurance level (potentially updated in real-time) of the user's chips as well as the assurance level of the transaction environment (in determining if there is sufficient
Re: Crypto dongles to secure online transactions
On 11/21/2009 05:56 PM, Jerry Leichter wrote: On Nov 18, 2009, at 6:16 PM, Anne Lynn Wheeler wrote: ... we could moved to a person-centric paradigm ... where a person could use the same token for potentially all their interactions ... we claimed we do something like two orders magnitude reduction in fully-loaded costs by going to no personalization (and other things) ... and then another two orders magnitude reduction in number of tokens by transitioning from institutional-centric paradigm to person-centric paradigm (compared to proposed smartcard/dongle replacing every pin/password). we then came up against that the bank marketing departments have taken advantage of the requirement for institutional personalization ... to put their brand and other stuff on every token It goes deeper than that. Oh, sure, marketing loves having a presence - but their desire fits into corporate cultural biases. When I go to work, I have to carry two key cards - one for the building, one for my employer. They use the same technology - if you use the wrong one, the reader beeps in recognition but of course won't unlock the door. In fact, they interfere with each other - you have to make sure to keep the wrong one a couple of inches away from the reader or it will usually be confused. It's a pain, actually. Now, it's certainly possible that there's something proprietary on one card or the other - though as we've discussed here before, that's only true on badly designed systems: It's no big deal to read these cards, and from many times the inch or so that the standard readers require. So all that should be on the cards is an essentially random number which acts as a key into the lock systems database. It's just that the owners of each system insist on assigning that random number themselves. Does it give them any additional security? Hardly. If you think through the scenarios, you confirm that quickly - a direct consequence of the lack of any inherent value in the card or its contained number in and of themselves: The real value is in the database entry, and both institutions retain control of their own databases. What's needed is some simple cooperation and agreement on how to assign unique numbers to each card. There already has to be cooperation on the issuance and invalidation of building cards. But institutions insist on their sense of control and independence, even when it has no real payoffs for them (and, in fact, raises their costs). -- Jerry We went thru all the scenarios with the objections on why they wanted institutional-centric paradigm ... part of the scenario was putting the assurance level of the chip on level with assurance level of your fingerprint or iris pattern ... and asking when institutions were going to start issuing individual, institutional-specific fingers for people to use. this is various person-centric claims here and there (assigned and still having activity after we've been gone for yrs) http://www.garlic.com/~lynn/aadssummary.htm there is specific granted patent here: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PALLp=1u=%2Fnetahtml%2FPTO%2Fsrchnum.htmr=1f=Gl=50S1=6978369.PN.OS=PN/6978369RS=PN/6978369 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On 11/21/2009 06:31 PM, Jerry Leichter wrote: Well, my building card is plain white. If anyone duplicated it, there'd be nothing stopping them from going in. But then the actual security offered by those cards - and the building controls - is more for show (and I suppose to keep the riffraff out - than anything else. My work card has my photo and name on it, but there's nothing to correlate name with underlying ID in normal operation. Snap a photo of the card while you clone it, make up a reasonable simulacrum with your own picture and name, and walk right in. Not really more or less secure than the old days when you flashed you (easily copied) badge to a card who probably only noticed that it was about the right size and had roughly the right color. But it's higher tech, so an improvement. :-) Physical security for most institutions has never been very good, and fortunately has never *needed* to be very good. Convenience wins out, and technology gives a nice warm feeling. A favorite example: My wife's parents live in a secured retirement community. The main entrance has a guard who checks if you're on a list of known visitors, or calls the people you're visiting if not. Residents used to have a magnetic card, but that's a bit of pain to use. So it was replaced by a system probably adapted from railroad freight card ID systems: You stick big barcode in your passenger side window, and a laser scanner on a post reads it and opens the door. Simplest card/token is basically (single-factor) something you have authentication the cheapest RFID proximity card is just some static data ... that can be trivially copied and reproduced ... think of it somewhat akin to a wireless magstripe. that has also the YES CARD point-of-sale contact card vulnerability. Compromised POS terminal that recorded the static data from card transaction and trivially used to produce a counterfeit card (little or no difference from compromised POS terminal that records magstripe data). What made it worse than magstripe was that POS terminals were programmed to ask a validated chip three questions 1) was the entered PIN correct, 2) should the transaction be done offline, and 3) is the transaction within the account credit limit. A counterfeit YES CARD would answer YES to all three questions (it wasn't necessary to even know the correct pin with counterfeit YES CARD ... and deactivating the account ... as in magstripe ... wasn't sufficient to stop the fraud). A counterfeit YES CARD was also some other counterme asures that had been built into the infrastructure: http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html a little more secure is two-factor token that requires both the token and possibly something you know. However, two-factor authentication is assumed more secure is based on single factor authentication is based on the different factors having independent compromises. In the case of the YES CARD (supposedly two-factor) ... it was only necessary to compromise the token's static data ... and it wasn't even necessary to know the correct PIN. In the case of pin-debit cards ... skimming compromises of ATMs or point-of-sale terminals can collect both the PIN and the magstripe data at the same time (invalidating assumption about independent compromises). we had somewhat been asked in the mid-90s to participate in the x9a10 financial standard group (which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments) because of having worked on this stuff now frequently called electronic commerce. This was *ALL* as in debit, credit, ACH, internet, point-of-sale, low-value, high-value, face-to-face, unattended, and/or transit. Transit-turnstyle has similar requirements to building access ... although the contactless power limitations and contactless elapsed time requirements can be more stringent than building access. Somewhat as a result ... the related work on the AADS chip strawman, had all sorts of requirements ... form factor agnostic, very-very fast, very-very low-power, contactless capable ... but for high-value ... had to no have *NO* static data and very difficult to counterfeit ... but at the same time ... for low-value ... had to have as close to zero cost as possible. Most of the alternatives from the period ... tended to only consider a very small subset of those requirements ... and therefor created a solution that had a single, specific operation and were ill-suited for a general purpose use. A simple issue was having the same token that was multi-factor authentication agile ... operate with single-factor (something you have) at a transit turnstyle (no time to enter PIN) ... but works the same way at a high-security building access turnstyle that requires multi-factor authentication (something you have token in conjunction with PIN something-you-know or palm finger
Re: Crypto dongles to secure online transactions
On 11/18/2009 12:22 PM, Bill Frantz wrote: Perhaps I'm missing something, but my multiple banks will all accept my signature when made with the same pen. Why wouldn't they not accept my signature when made with the same, well protected, signing/user verifying device. I might have to take it to the bank to give them its public key in person, but that seems a minor inconvenience. This kind of device sounds like a fine device for a banking industry committee to specify. we ran into that with doing chip that required to post-fab personalization ... eliminating lots of the costs thruout the whole infrastructure (eliminating personalization actually makes the delivered cost to the user less than the current infrastructure). we then looked at the current institutional-centric paradigm ... where each institution wants to deliver token/card to user ... with having eliminating any personalization requirement ... then we claimed we could moved to a person-centric paradigm ... where a person could use the same token for potentially all their interactions ... having to wade through all the institutional arguments ... and addressing each one that stood in the way of moving from an institutional-centric paradigm to person-centric paradigm. the smartcard industry was looking at possibly replacing every pin/password with a unique smartcard/dongle. we claimed we do something like two orders magnitude reduction in fully-loaded costs by going to no personalization (and other things) ... and then another two orders magnitude reduction in number of tokens by transitioning from institutional-centric paradigm to person-centric paradigm (compared to proposed smartcard/dongle replacing every pin/password). we then came up against that the bank marketing departments have taken advantage of the requirement for institutional personalization ... to put their brand and other stuff on every token. They started out saying they didn't want to do chip because it increased costs ... and when we showed we can come very close to driving costs to zero ... it turns out the marketing departments like the current infrastructure (despite the costs) ... because they feel it is important to have their brand on the token in each person's wallet. There were various sorts of distractions/obfuscations ... like what happens if the only token fails ... there is nothing that prevents a person from having two person-centric tokens (or personally choosing to have a their own unique token per institution). Then it was ... what happens if the only token is stolen. It turns out that the standard threat is the wallet/purse is stolen with all the cards (eliminating any different between there being single token or multiple tokens). In any case ... with a paradigm that has been in place for this long ... there are quite a large number of people that don't want to change ... some for no other real reason than its different ... for others they have leveraged current paradigm for things that couldn't have been independently justified on its own. Early on uptake in various standards organization was good ... until some of the change implications started percolating thru the infrastructure. It was analogous to what we did with secure x9.59 financial transaction standard ... and then the implications of eliminating all the associated fraud started to sink in. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On 11/10/2009 09:44 AM, Jerry Leichter wrote: Not that this should block the use of devices like the ZTIC! They're still much more secure than the alternatives. But it's important to keep in mind the vulnerabilities we engineer *into* systems at the same time we engineer others *out*. vulnerabilities tend to be proportional to complexity. we had been asked in to consult with small client/server startup that wanted to do payment transactions on their server ... they had also invented this technology called SSL applied to the process. The result is frequently called electronic commerce. The major use/purpose of that SSL in the world today is hiding the account number and other transaction details. somewhat as a result, in the mid-90s we were invited to to participate in the x9a10 financial standard working group which had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. Part of that was detailed threatvulnerability studies of different payment methods and environments. One of the biggest problems was vulnerability of leaking account number ... since it was trivial for crooks to use it for originating fraudulent transactions ... and at the same time required by millions of business processes around the world. So part of the resulting standard was slightly tweaking the paradigm and eliminating the account number (and transaction details) as a vulnerability (which then also eliminates the major use of SSL in the world today). along the way, i also made semi-facetious comment that i would take a $500 milspec item and aggressively cost reduce it by 2-3 orders of magnitude while making it more secure. Part of the effort effectively worked out getting it close to the EPC RFID technology process (items targeted at replacing UPC barcodes on grocery items at a few cents or less) w/o reducing security. Basically it is all silicon ... which not only reduces a lot of after-FAB vulnerabilities ... but also eliminates the costs of a lot of the post-FAB processing steps (as silicon cost goes to zero, post-FAB processing costs started to dominate). Along with it is the concept of security proportional to risk ... at the issuing authorization end of a transaction ... the security characteristics of the originating components can be evaluated ... in the case of the chip ... the security level of the chip can even be updated in real time as vulnerabilities are identified. This can help decide like a when a few cent item might be needed to be replaced for higher value transactions -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On 11/08/2009 02:07 AM, John Levine wrote: At a meeting a few weeks ago I was talking to a guy from BITS, the e-commerce part of the Financial Services Roundtable, about the way that malware infected PCs break all banks' fancy multi-password logins since no matter how complex the login process, a botted PC can wait until you login, then send fake transactions during your legitimate session. This is apparently a big problem in Europe. I told him about an approach to use a security dongle that puts the display and confirmation outside the range of the malware, and although I thought it was fairly obvious, he'd apparently never heard it before. When I said I'd been thinking about it for a while, he asked if I could write it up so we could discuss it further. So before I send it off, if people have a moment could you look at it and tell me if I'm missing something egregiously obvious? Tnx. I've made it an entry in my blog at http://weblog.johnlevine.com/Money/securetrans.html Ignore the 2008 date, a temporary fake to keep it from showing up on the home page and RSS feed. R's, John deja vu 1999 this should be covered in enormous detail in the EU finread standards documents from the late 90s. note that the EU finread standard from late 90s (over decade ago) was countermeasure to most every kind of PC compromise that you can think of. Basically it moved the end point out to independent hardware device with its own display and pin-pad. The transaction was still composed on the PC ... but had to be sent to the hardware finread device for approval/authentication. transaction to be approved/executed would be displayed on finread device for approval. It then required physical PIN entry to execute the approval process ... typically assumed to be a digital signature ... which was returned to the PC. compromised PC could still do a denial of service ... but the independent finread device effectively moved the end-point from the PC out to the finread. the independent display pin-pad ... was countermeasures to various kinds of exploits ... including * keylogging ... trojan horse or other could execute transactions w/o users actual knowledge * is the transaction that the user sees the actual transaction being executed bad design might have used the finread for session authentication in lieu of separately authentication/approval for every transaction (which would allow trojans on compromised pcs to execute fraudulent transactions within the boundaries of the session. infrastructure would still be vulnerable to various kinds of social engineering ... convincing end-user to execute valid transactions for the benefit of the attacker. There was some conjecture (again more than decade ago) that if finread deployment eliminated all the other kinds of compromises ... that user education programs could purely concentrate on social engineering exploits (sort of like the stuff for little kids to have nothing to do with strangers). EU finread program got caught up in the disastrous deployment of serial-port card acceptor device at the start of the decade (many versions had the appearance of card acceptor device with its own independent display and pin-pad ... slightly akin to small POS terminals that might appear at point-of-sale). The disastrous serial-port acceptor device deployment resulted in rapidly spreading opinion in the financial industry that smartcards and card readers weren't practical in the consumer market ... resulting in nearly all such programs quickly evaporating w/o hardly a trace. As i've mentioned before ... it wasn't actually a problem with smartcards and/or card readers but with the serial-port interface. In the 1995 time-frame there were a number of presentations about moving the dial-up home banking programs to the internet ... in large part motivated by the significant customer support costs associated with supporting serial-port modems (one such bank program claimed to have a library of over 60 serial port modem software drivers to try and cover some reasonable set of their customers. Problems with the whole serial-port gorp was also big motivator behind development of USB. In any case, i've commented before about the financial industry institutional knowledge and experience apparently rapidly evaporated between the migration of dial-up home banking (migration to the internet) and 2000. A partial/possible explanation might be that the vendor, knowing that everything was moving to USB, saw a really great chance to unload their stock of obsolete serial-port devices on a client that didn't really know what they were doing. lots of past EU finread standard posts: http://www.garlic.com/~lynn/subintegrity.html#finread random trivia ... i was at an eu finread standard meeting in brussels not long before the whole thing with serial-port resulted in all such programs imploding (even those not using serial-port ... radiation from the event
Re: Client Certificate UI for Chrome? -- OT anonymous-transaction
On 08/20/09 00:11, Ray Dillinger wrote: No. This juvenile fantasy is complete and utter nonsense, and I've heard people repeating it to each other far too often. If you repeat it to each other too often you run the risk of starting to believe it, and it will only get you in trouble. This is a world that has not just cryptographic protocols but also laws and rules and a society into which those protocols must fit. That stuff doesn't all go away just because some fantasy-world conception of the future of commerce as unlinkable anonymous transactions says it should. most of the financial industry digital certificate specifications were relying party only digital certificates ... effectively only containing an account number ... because of privacy (both in us and europe) and liability issues. some of this was also about the time that EU-DPD made statements that electronic retail transactions should be w/o names (i.e. remove person names from payment cards ... also a form of relying party only instrument). this somewhat side-stepped whether it was linkable or not ... since it then was back at the financial institution whether the account number was linked to a person or anonymous ... but did meet privacy requirements for retail payments depending on gov. financial institution with regard to any possible know your customer mandates ... a court order to the financial institution had the potential of revealing any linkage There were a couple issues: 1) even as a relying-party-only digital certificate ... the digital certificate gorp resulted on the order of 100 times payload bloat for typical payment transaction payload size. there were two approaches a) strip the digital certificate off the payment transaction as early as possible to minimize the onerous payload penalty; b) financial standards looked at doing compressed relying-party-only digital certificates ... possibly getting the payload bloat down to only a factor of ten times (instead of one hundred times). 2) it was trivial to show that the issuing financial institution already had a superset of information carried in the relying-party-only digital certificate ... so it was redundant and superfluous to repeatedly send such a digital certificate back to the issuing financial institution appended to every payment transactions (completely redundant and superfluous was separate issue from representing factor of 100 times payload bloat). so there were two possible solutions to the enormous payload bloat a) just digital sign the transaction and not bother to append the redundant and superfluous relying party only certificate b) the standards work on compression included eliminating fields that the issuing financial institution already possessed ... since it was possible to demonstrate that the issuing financial institution had a superset of all information in a relying-party-only digital certificate ... it was possible to compress the size of the digital certificate to zero bytes. then it was possible to mandate that zero byte digital certificates be appended to every payment transaction (also addressing the enormous payload bloat problem). the x9.59 financial transaction standard ... some refs http://www.garlic.com/~lynn/x959.html#x959 just specified requirement for every payment transaction to be authenticated ... and didn't really care whether there was no digital certificate appended ... or whether it was mandated that zero-byte digital certificates were appended. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Client Certificate UI for Chrome?
On 08/06/09 07:33, James A. Donald wrote: The fundamental problem with certificates is getting them. digital certificate design point supposedly was the dial-up email of the early 80s, dial-up, exchange email, hang-up ... and then faced with how to deal with first time email from complete stranger. basically electronic analog for letters of credit/introduction from sailing ship days. in the 90s, because of numerous privacy and liability issues ... there was some number of relying-party only certificates; individual registered their public key with the institution, institution then created a digital certificate with the public key, archived it, and returned a copy to the individual. the individual, in communication with the institution would digitally sign the communication and then append the digital certificate. However, it was trivial to prove that the institution/relying-party already had a copy of the information ... and the appended digital certificate was redundant and superfluous. misc. past posts discussion relying-party only digital certificates http://www.garlic.com/~lynn/subpubkey.html#rpo furthermore, major foreys into this sector were by financial institutions for the purpose of payment transactions. a complicating factor ... besides the digital certificates being redundant and superfluous ... they added a 100 times payload size bloat to the typical payment transactions. misc. past posts http://www.garlic.com/~lynn/subpubkey.html#bloat there was a financial standards effort that looked at possibly doing compressed digital certificates (trying to achieve only ten times bloat) ... eliminating redundant fields and information already in the possession of the individual's financial institution. we showed that the individual's financial institution already had superset of the information in the digital certificate ... so it was possible to compress digital certificates to zero bytes ... and then mandate that financial transactions would always have zero-byte certificates appended (as opposed to no appended digital certificate). Something similar was demonstrated for RADIUS and Kerberos ... registering a public key in lieu of password ... some past references http://www.garlic.com/~lynn/subpubkey.html#radius and http://www.garlic.com/~lynn/subpubkey.html#kerberos and also something similar for registering public key with domain name registration with domain name infrastructure ... for use in lieu of SSL digital certificates http://www.garlic.com/~lynn/subpubkey.html#catch22 that left institutions and relying party with no-value business processes as digital certificate opportunities ... i.e. no-value transactions where the relying party couldn't justify the cost of their own entity repository and/or justify the cost of doing an online transactions to obtain such entity information ... and of course ... the original design point, the offline email scenario with first time communication with complete strangers. One of the problems with no-value market segment is that it is hard for institutions and individuals to justify paying for things without any value ... and therefor it is hard to find entities looking at selling things for nothing. -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: password safes for mac
On 07/01/2009 02:10 PM, Nicolas Williams wrote: I should add that a hardware token/smartcard, would be even better, but the same issue arises: keep it logged in, or prompt for the PIN every time it's needed? If you keep it logged in then an attacker who compromises the system will get to use the token, which I bet in practice is only moderately less bad than compromising the keys outright. Nominally, hardware token is something you have authentication. In many implementations, business rules are added to the chip for stuff like business requirements for multi-factor authentication (like in conjunction with PIN). The resulting situation is business rule/environment specific. In the late 90s, there was work on EU FINREAD standard for external trusted card-acceptor device ... that had trusted pin-entry and trusted display. The objective was countermeasure to lots of well known compromises of PCs (including keylogger ... implying that compromised PC could operate an external hardware token, even if PIN was required per transaction). A lot of this evaporated in the early part of this decade in the wake of with various troubles associated with hardware tokens. As an aside ... one of the things we did in the AADS patent portfolio was to remove business rules from the hardware token ... as part of enabling person centric operation (i.e. the same token might be used for lots of different environments ... as opposed to having hardware token for every unique business environment). An AADS hardware token can support both single-factor as well as multi-factor authentication operation ... but it is up to the business application interacting with the hardware token to indicate the amount of authentication integrity (some assumption about security proportional to risk ... for instance, whether or not PIN might be required for every operation, or at all). -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Solving password problems one at a time, Re: The password-reset paradox
On 05/09/09 07:33, Jerry Leichter wrote: I had a discussion with a guy at a company that was proposing to create secure credit cards by embedding a chip in the card and replacing some number of digits with an LCD display. The card would generate a unique card number for you when needed. They actually had the technology working - the card was pretty much indistinguishable from any other. (Of course, how rugged it would be in typical environments is another question - but they claimed they had a solution.) Deloitte staff trial Visa card with built in OTP generator for IT access control http://www.finextra.com/fullstory.asp?id=20019 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Solving password problems one at a time, Re: The password-reset paradox
On 05/09/09 07:33, Jerry Leichter wrote: On May 8, 2009, at 3:39 PM, Ian G wrote: The difficulty with client certs is that I need them to also work on my laptop. And my other laptop. And my phone. So, how do I get hold of them when I'm on the road? Good point. The difficulty with my passwords is that I have so many that are so long that I can only manage them on my laptop, and have to carry my laptop with me ... We can imagine all sorts of techie solutions to this, but it does appear that we are in a bit of a grey zone with auth at the moment, and the full solution might take a while to emerge. Try them all? This is part of a broader UI issue. I had a discussion with a guy at a company that was proposing to create secure credit cards by embedding a chip in the card and replacing some number of digits with an LCD display. The card would generate a unique card number for you when needed. They actually had the technology working - the card was pretty much indistinguishable from any other. (Of course, how rugged it would be in typical environments is another question - but they claimed they had a solution.) I pointed out that my wife knows one of her CC numbers by heart. The regularly quotes it, both on phone calls and to web forms. The card itself is buried in a thick wallet, which is buried in her pocketbook, which is somewhere in the house - likely not near the phone or the computer. Hell, one of the nice things about on-line shopping is that I can do it in my bathrobe - except that I *don't* know my CC by heart, so in fact I tend to put off buying until later when I have my wallet with me. (This does save me money) When I'm in a store, I'm used to having to have my CC with me, because I always had to have the wallet with money anyway. At home, it's a whole different story. In any case, merchants are trying to make the in-store experience as simple as possible, pushing for things like RFID credit cards and even fingerprint recognition. So many people would see these safer cards as a big step backwards in usability. Why would they want such a thing? The card companies are trying to sell safety, but in the US, where your liability is at most $50 if your CC number is stolen (and where in practice it's $0), the only cost you as an individual bear is the inconvenience of replacing a card. Because replacements for security problems have gotten so common, the CC companies have streamlined the process. It's really no big deal. I've had CC numbers stolen a couple of times (by means unknown); recently, two of my CC's were replaced by the companies based on some information known only to them. In every case, the process was very quick and painless. Hell, these days even on-line continuing charges often update to the new number automatically (though I've learned to keep track of those and check). The person arguing for this claimed that CC companies could offer a discount for users of the secure cards. But if you look at actual loss rates - how much could you offer? (I'd guess it's about the same as Discover offers: About a 1.5% rebate on most purchases. Not enough to let Discover steal customers from Visa and MC. Given all the other charges - and the absurdly high interest rates - on cards, anything like this gets lost in the noise.) Security that depends on people changing their habits in a way that is inconvenient to them ... won't happen (unless you're in an environment where you can *force* such changes). -- Jerry at least the initial introduction of one-time-account number displays had a problem because they couldn't meet the flexing specification (like cards in mens wallet and getting sat on). note that there has been big push to signature debit (similar interchange fees and fraud as signature credit) with 15 times the fraud of PIN-debit (which has significantly lower interchange fees compared to signature debit) reference http://www.digitaltransactions.net/newsstory.cfm?newsid=73 mentioned in this post from 2006 http://www.garlic.com/~lynn/2006e.html#21 there has been some articles about unsafe cards being a profit item for financial institutions ... since they charge merchants a significantly higher interchange fee. there have been references that there can be as much as a order of magnitude difference in fees between unsafer transaction fees and safer transaction... with unsafe transaction fees contributing significantly to reports that payment fees have represented as much as 40% of bottom line for US consumer financial institutions (an order of magnitude reduction would be a big hit). part of thread on this subject in this mailing list from two years ago http://www.garlic.com/~lynn/aadsm27.htm#31 http://www.garlic.com/~lynn/aadsm27.htm#32 http://www.garlic.com/~lynn/aadsm27.htm#33 http://www.garlic.com/~lynn/aadsm27.htm#34 http://www.garlic.com/~lynn/aadsm27.htm#35 http://www.garlic.com/~lynn/aadsm27.htm#37 http://www.garlic.com/~lynn/aadsm27.htm#38
Re: Has any public CA ever had their certificate revoked?
On 05/05/09 14:01, Thierry Moreau wrote: Before the collapse of the .com market in year 2000, there were grandiose views of global PKIs, even with support by digital signature laws. Actually, it turned out that CA liability avoidance was the golden rule at the law and business model abstraction level. Bradford Biddle published a couple of articles on this topic, e.g. in the San Diego Law Review, Vol 34, No 3. The main lesson (validated after the PKI re-birth post-2002) is that no entity will ever position itself as a commercially viable global CA unless totally devoid of liability towards relying parties. Thus no punishment is conceivable beyond the Peter's opinions (they are protected by Freedom of speech at least). That was predicted by the Brad Biddle analysis 12 years ago. we had been brought in to help word-smith the cal. state electronic signature law. there was some legal types who very clearly differentiated what was required for something to be considered human signature (implication that something has been read, understood, agrees, approves, /or authorizes) and PKI digital signatures used for authentication. we've periodically commented that there may be some cognitive dissonance because both terms contain the word signature. slightly related pontification http://www.garlic.com/~lynn/2009g.html#48 regarding this recent article mentioning SSL Inventor: SSL security woes are really the fault of browser design http://www.fiercecio.com/techwatch/story/inventor-ssl-security-woes-really-fault-browser-design/2009-05-05 -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Certificates turn 30, X.509 turns 20, no-one notices
On 11/27/08 05:13, Nicholas Bohm wrote: I've never been quite sure whether Public qualifies Key or Infrastructure - this may make a difference to what you count as a PKI. SWIFT (interbank messaging), BOLERO (bills of lading) and CREST (dealing in dematerialised stocks and shares) all use public key cryptography, I believe, and have all been reasonably successful; but they are all closed systems where each of the participants believes that it and the others can stand the risk of contractually-imposed non-repudiation rules (or they used to believe it, anyway). But what these examples illustrate, by the lack of open comparables, is the very limited utility of the technology. in the past capitalization referred to CAs making the rounds of wallstreet with $20B/annum business case (i.e. approx. $100/annum per adult in the US). The lower case public key met that an entity could make their public key available ... as countermeasure to the shortcomings of shared-secret (password/PIN) paradigm ... where a unique shared-secret was required for every unique security domain (the current scenario where scores or hundreds of unique shared-secrets have to be managed). going from lower-case ... where an entity could share the same public key with large number of different entities, to upper-case, was the scenario justifying the $20B/annum business case. sometimes the issue isn't whether the public key is open/closed ... the issue is whether the business liability is between the parties involved ... or should random, unrelated participants also get involved in the business processes. there have been some attempts at obfuscation ... attempting to confuse the boundaries between the authentication technology and the parties involved in business processes liability i was at annual acm sigmod (aka database) conference in 91 (92?) and during one of the sessions, somebody asked a question regarding what was all this X.5xx stuff going on ... and the reply was that a bunch of networking engineers were trying to re-invent 1960s database technology. -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Secure64 Develops First Automated DNSSEC Signing Application to Help Secure the Internet Worldwide
Secure64 Develops First Automated DNSSEC Signing Application to Help Secure the Internet Worldwide http://www.businesswire.com/news/google/20080730005428/en from above: Secure64 Software Corporation has developed a product that dramatically simplifies the implementation and management of DNSSEC. Secure64 DNS Signer™ is the first and only product that addresses each of the obstacles that have slowed the widespread deployment of DNSSEC zone signing, including the need for simplicity, security, auditability and scalability. While recent patching efforts have mitigated the impact of the cache poisoning vulnerability identified by Dan Kaminsky and widely reported by the media, deployment of DNSSEC is widely regarded as the only viable long-term solution to securing the Domain Name System (DNS). ... snip ... One of the people behind Itanium design ... was one of the Secure64 founders ... somewhat as part of demonstrating what could be done with features that had been included in Itanium chip architecture. I've noted before that they had been heavily involved in earlier RISC chip efforts ... including original 801 risc chip. misc. past posts mentioning 801, risc, romp, rios, somerset, fort knox, power/pc, etc http://www.garlic.com/~lynn/subtopic.html#801 -- 40+yrs virtualization experience (since Jan68), online at home since Mar70 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The PKC-only application security model ...
Thierry Moreau wrote: Anne Lynn Wheeler wrote about various flavors of certificateless public key operation in various standards, notably in the financial industry. Thanks for reporting those. No doubt that certificateless public key operation is neither new nor absence from today's scene. The document I published on my web site today is focused on fielding certificateless public operations with the TLS protocol which does not support client public keys without certificates - hence the meaningless security certificate. Nothing fancy in this technique, just a small contribution with the hope to facilitate the use of client-side PKC. this post references scenario for replacing the SSL server domain name certificates with a certificate-less public key infrastructure http://www.garlic.com/~lynn/2008k.html#49 The PKC-only application security model the first reply http://www.garlic.com/~lynn/2008k.html#48 The PKC-only application security model mentions certificate-less X9.59 (financial transaction), certificate-less KERBEROS (large number of infrastructure and application authentication operation) and certificate-less RADIUS (possibly dominant client authentication infrastructure in the world today used by lots of ISP, corporate intranets, webhosting operations, etc). RADIUS provides a generalized authentication, authorization, and accounting infrastructure ... where AAA specifics can be specified on an account or client basis (i.e. including being able to easily accomodating both password and public key concurrently). http://www.garlic.com/~lynn/subpubkey.html#radius There are even RADIUS plug-ins for webservers for doing webserver client authentication. A combination of replacing SSL server domain name certificates with certificate-less server operation and and using certifcate-less RADIUS (client) authentication ... covers mutual (client server) operation. RADIUS references from our rfc index: http://www.garlic.com/~lynn/rfcietff.htm click on Term (term-RFC#) field and then click on RADIUS (in the Acronym fastpath): Remote authentication dial in user service (RADIUS) see also authentication , network access server , network services 5176 5090 5080 5030 4849 4818 4679 4675 4673 4672 4671 4670 4669 4668 4603 4590 4372 4014 3580 3579 3576 3575 3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138 2059 2058 clicking on any of the RFC numbers, retrieves the RFC summary in the lower frame. Clicking on the .txt=nnn field (in a RFC summary) retrieves the actual RFC. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The PKC-only application security model ...
Thierry Moreau wrote: In draft-ietf-sip-dtls-srtp-framework, the detailed scheme uses self-signed certificates created by client end-entities themselves. The basic idea is identical. At the detailed level in my document, the client end-entity auto-issues a security certificate with a breached CA private key. In the TLS Certificate request message, a list of CA distinguished names is provided to the end entity. Referring to a breached CA public key is an invitation to submit a meaningless end-entity certificate, making the detailed scheme more plain with respect to TLS options (i.e. an empty list in a certificate request message could be a not so well supported mode in TLS software implementations). So, maybe the reference to the notion of self-signed EE certificates in draft-ietf-sip-dtls-srtp-framework could be replaced by meaningless EE certificates (or something else), which would include both self-signed or auto-issued. In such a case, the RFC publication for my document would become more pressing. A related discussion occurred on the IETK PKIX mailing list in June 2008 under the subject RFC 5280 Question. re: http://www.garlic.com/~lynn/2008k.html#48 The PKC-only application security model http://www.garlic.com/~lynn/2008k.html#49 The PKC-only application security model http://www.garlic.com/~lynn/2008k.html#51 The PKC-only application security model another approach that X9 financial standard organization took to attempt the enormous digital certificate bloat was standards effort for compressed digital signature ... possibly reducing 100-times bloat to possibly only 5 to 10 times bloat. There was some conjecture that such lightweight digital certificates might also find place in wireless applications. part of compression effort was to recognize that the server already had much of the information was exactly the same in every certificate and/or the server already possessed. I raised the issue (rather than harping on the theme that digital certificates being redundant and superfluous ... besides 100 times bloat) that (for all the situations they were looking at) the server already had all the information in a digital certificate. Therefor, it would be possible to define a new class of zero byte digital certificates that would be appended to every digitally signed transaction. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The PKC-only application security model ...
Thierry Moreau wrote: A)The big picture refers to the PKC-only application security scheme, in which client-server applications may be secured with client-side public key pairs, but *no trusted certification authority* is involved (server operators are expected to maintain a trusted database of their clients' public keys). original PK-init (public key) draft for Kerberos was (only) certificateless public key operation ... i.e. kerberos server operators maintaining trusted database of their clients' public keys (in lieu of passwords) ... PKI/certificate mode of operation was eventually added to the specification. lots of past posts about certificateless public key kerberos http://www.garlic.com/~lynn/subpubkey.html#kerberos similar implementation was done for RADIUS http://www.garlic.com/~lynn/subpubkey.html#radius general posts about certificateless (sometimes naked) public key http://www.garlic.com/~lynn/subpubkey.html#certless X9.59 is financial transaction standard also using certificateless public key operation http://www.garlic.com/~lynn/x959.html#x959 part of the issue was that 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. One of the issues for x9.59 was that it had to be lightweight enough to operate in existing infrastructures. Some of the certificate-oriented payment transaction standards from the period resulted in factor of 100 times (two orders of magnitude) payload (i.e. certificate payload overhead could be 100 times larger than basic payment transaction) and processing (i.e. certificate processing overhead could be 100 times larger than basic payment transaction) bloat http://www.garlic.com/~lynn/subpubkey.html#bloat general discussions of the account authority public key model (as contrast to certification authority public key model) http://www.garlic.com/~lynn/x959.html#aads - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WoW security: now better than most banks.
Perry E. Metzger wrote: My bank doesn't provide any sort of authentication for logging in to bank accounts other than passwords. However, Blizzard now allows you to get a one time password keychain frob to log in to your World of Warcraft account. post in thread here a yr ago (1jul07) about financial institutions attempting some (disastrous) deployments in the 99/00 time-frame ... and then instead of taking blame for deployment problems ... there was quickly spreading opinion that hardware tokens weren't practical in the consumer market place http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game as noted in another post ... the disastrous failures were somewhat a case of institutional knowledge not permeating different part of the organizations. banking conferences in the mid-90s were attributing the existing online banking migration to the internet in large part motivated by significant customer support problems with serial port modems (mostly with the serial port part). http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game that even if a little bit of the experience form the earlier online banking programs had carried over into the later hardware token deployments ... much of the deployment problems could have been averted. In any case, the claim could be made that the industry is still attempting to recover from those disasters. a couple other posts on the same subject in other threads: http://www.garlic.com/~lynn/2007n.html#65 Poll: oldest computer thing you still use http://www.garlic.com/~lynn/2007t.html#22 'Man in the browser' is new threat to online banking http://www.garlic.com/~lynn/2007u.html#11 Public Computers - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The wisdom of the ill informed
James A. Donald wrote: Committees of experts regularly get cryptography wrong - consider, for example the Wifi debacle. Each wifi release contains classic and infamous errors - for example WPA-Personal is subject to offline dictionary attack. One would have thought that after the first disaster they would have hired someone who could do it right, but as Ian long ago pointed out, in the market for silver bullets, they are unable to tell who can do it right. The only people who know who the real experts are, are the real experts. If you knew who to hire, you could do it yourself, and probably should do it yourself. So they hire expert salesmen, not cryptography experts. the other scenario was that the cryptography part was done from such a myopic standpoint ... that they failed to consider the end-to-end infrastructure. I've repeatedly heard excuses that the cryptographers in the wifi debacle believed that they could only design a solution based on significant hardware restrictions/constraints. part of what i observed ... by the time any of them shipped ... the hardware restrictions/constraints no longer existed . the other thing that i observed was that with relatively trivial knowledge about chips ... it was possible to come up with an integrated solution that incorporated both the necessary hardware and the necessary cryptography ... there has got to be some analogy here someplace about the blind trying to describe an elephant; in addition to the point solution analogy, failing to take in the overall infrastructure. i've repeatedly claimed that we did that in the AADS chip strawman solution http://www.garlic.com/~lynn/x959.html#aads that including addressing all the issues that showed up in scenarios like with the yes cards http://www.garlic.com/~lynn/subintegrity.html#yescards - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Own a piece of the crypto wars
archeological email about proposal for doing pgp-like public key (from 1981): http://www.garlic.com/~lynn/2006w.html#email810515 the internal network was larger than the arpanet/internet from just about the beginning until sometime summer of '85. corporate guidelines had become that all links/transmission leaving corporate facilities were required to be encrypted. in the '80s this met lots of link encryptors (in the mid-80s, there was claim that internal network had over half of all the link encryptors in the world). a major crypto problem was with just about every link that crossed any national boundary created problems with both national gov. links within national boundaries would usually get away with argument that it was purely internal communication within the same corporate entity. then there was all sorts of resistance encountered attempting to apply that argument to links that cross national boundary (from just about every national entity). For other archeological lore ... old posting with new networking activity from 1983 http://www.garlic.com/2006k.html#8 above posting includes listing of locations (around the world) that had one or more new network links (on the internal network) added sometime during 1983 (large precentage involved connections requiring link encryptors). more recent post http://www.garlic.com/~lynn/2008h.html#87 mentioning coming to the realization (in the 80s) that there were three kinds of crypto. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ransomware
John Ioannidis wrote: This is no different than suffering a disk crash. That's what backups are for. At Jim Gray's tribute on the 31st, Bruce Lindsay gave a talk about Jim's formalization of transaction processing enabled online transactions ... i.e. needed trust in the integrity of integrity of transaction as prerequisite to move from manual/paper processes. In the early 90s, when glasshouse and mainframes seeing significant downturn in their use ... with lots of stuff moving off to PCs, there was a study that half of the companies that had a disk failure involving (business) data that wasn't backed up ... filed for bankruptcy within 30 days. The issue was that glasshouse tended to have all sorts of business processes to backup business critical data. Disk failures that lost stuff like billing data had significant impact on cash flow (there was case of large telco that had bug in its nightly backup and when the disk crashed with customer billing data ... they found that there didn't have valid backups). Something similar also showed up in the Key Escrow meetings in the mid-90s with regard to business data that was normally kept in encrypted form ... i.e. would require replicated key backup/storage in order to retrieve data (countermeasure to single point of failure). part of the downfall of key escrow was that it seem to want all keys ... not just infrastructure where business needed to have replicated its own keys. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Bill Frantz wrote: really used for strangers. For people we know, recognition and memory are more compelling ways of trusting. We can use this recognition and memory in the online world as well. SSH automatically recognizes previously used hosts. Programs such as the Pet Names Toolhttp://www.waterken.com/user/PetnameTool/ recognize public keys used by web sites, and provide us with a human-recognizable name so we can remember our previous interactions with that web site. Once we can securely recognize a site, we can form our own trust decisions, without the necessity of involving third parties. that was one of the business case problems early in SSL for electronic commerce ... namely majority of ecommerce was with repeat sites ... while design point of digital certificates is for first time communication between strangers. the other factor that bounded what merchants would pay was liability in electronic commerce ... there were already paying significant interchange fees as part of protecting the consumer. certification authorities weren't looking at taking on any of that aspect. the combination has been pushing digital certificates into the no-value market segment ... which, in turn, further limits what would could be charged for. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: not crypto, but fraud detection + additional
Allen wrote: I don't know what the policy is in Ireland, but here in the USA there is no stop loss on debit cards so the banks are not obligated to make good on fraudulent withdrawals. I believe that most have out of fear of bad PR, but you have to fight for it if it is just a few that it happens to. If this happens too much then people might stop using debit cards. I have advised my mother, 87, to not use them as she is getting a little slow on the uptake and might miss something like this if it happened to her. Now to show how screwy the system is, I was shopping the other day and the power went off in the grocery store I was at. They had backup power so they were able to check out people; however, they couldn't use debit cards, except Well, the screwy thing was if you entered the charge at terminal as a credit card, even when it was only a debit card, it would accept it. I checked my bank, and sure enough the charge showed as a POS charge! I think the logic is a little screwy and might be able to be exploited though I'm not sure how at the moment. in theory signature debit (i.e. debit transaction w/o PIN) and credit could both work ... since they both go thru the same way. pin-debit goes thru in real time and the merchant has assurance that the transaction has been approved (and pin authenticated). as a result, the interchange fee is much lower ... because the related risk/fraud is presumed to be much lower. signature debit and credit basically go thru the network the very same way. the machine (either the actual POS terminal or a store controller) remembers all the transactions and there is periodic batch settlement (end of shift, or end of day). Settled transaction may or may not have a separate, associated real time authorization transaction. The merchant pays extra charge for each real time authorization transaction (which tend to be credit card specific regarding whether the account is active and the new transaction is within the card's credit limit or open to buy). the associated interchange fee is lower on transactions with real time authorizations (presumably transactions with real time authorizations tend to have lower risk/fraud). However, transactions may also be settled w/o an associated real time authorization (which will have a higher interchange fee since there is presumption of higher risk/fraud). there are some old merchant small fraud stories ... where the merchant claimed in the settlement transaction to have a separate real time authorization ... when there wasn't one (they got both the lower interchange fee w/o actually having to pay for a real-time authorization transaction ... this was before some financial institutions had the ability to reconcile the information). All have associated risk/fraud ... one of the tricks is for the financial institution to appropriately adjust the interchange fee to cover the financial institutions associated risk. There has been recent congressional hearings, EU anti-trust actions and merchant complaints that the financial institutions have adjusted the interchange fees way over what is needed to cover the associated risk. There were snide articles that financial institutions are making significant profits off of the risk adjusted interchange fees. 2-3 yrs ago supposedly something like 40percent of US financial institution bottom line was coming from these (risk adjusted) interchange fees ... and for many retailers it represented their single largest expense. this is been highlighted in the significant expense going into TV spots to promote signature debit since the interchange fee and especially the profit is significantly higher (vis-a-vis pin-debit). some of this was discussed in the bank fraud blame game thread that went on in this mailing list last june, july ... my posts archived here. http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#37 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#38 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#41 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#42 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#43 a fraud is a sale, Re: The bank fraud blame game - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
not crypto, but fraud detection
*Irish Bank Debit Card Skimmers Net €1m* http://www.epaynews.com/index.cgi?survey=ref=browsef=viewid=121179135013743148197block= from above: Most of the withdrawals took place at the end of April and early May 2008. Many of the victims contacted their banks to notify them of the withdrawals, as the banks’ fraud detection systems had failed to spot the suspicious activity. ... snip ... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
SSL use
I've periodically posted that certain assumptions were made about safe SSL deployment for electronic commerce that were almost immediately invalidated. The original assumptions assumed that the enduser knew the binding between the webserve that they thot they were talking to and the corresponding URL ... which they would then type into the browser. Then SSL would provide the assurance that the webserver that was actually being talked to corresponding URL. The two pieces together than provided that the enduser thot they were talking to was, in fact, the webserve that they were talking to. Almost immediately merchants invalidated the assumptions when they found that SSL represeted 4-5 times degradation in webserver thruput ... and dropped back to just using SSL for payment/checkout portion of the electronic commerce. Now a web button was clicked, providing an URL. Now the only thing going on was that SSL would verify that whatever webserver, the webserver claimed to be, was the webserver it claimed. This button clicking operation invalidated the original safety assumptions regarding the use of SSL for electronic commerce. The URL supplied by the button can be anything. Some amount of 3rd party payment processing outsources appeared to have taken advantage of this feature. A lot of phishing email also takes advantage of the paradigm also. I was recently invited to resister at a website with a non-US country domain. My registration would not even closely work since it appeared to require IE ... and since I don't have any windows machines ... I also don't have any IE browser. However in the process I thot I would poke around a little. I prefixed the URL with https (instead) of http. This got me a warning that the certificate was not for the indicated domain. When i looked at the certificate, it came from a certification authority that my browser recognized but was for a .com domain associated with some NIGERIAN payment processing operation. I then check the ip-address of the original (non-US country) domain and found it mapped to some US-based webhosting company. I then check the ip-address of the NIGERIAN payment processing operation and found it mapped to some other US-based webhosting company. I can only speculate that the first webhosting operation has some sort of default configuration for electronic commerce ... where SSL gets mapped to payment processing operation of this NIGERIAN payment processing operation. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Designing and implementing malicious hardware
Leichter, Jerry wrote: While analysis of the actual silicon will clearly have to be part of any solution, it's going to be much harder than that: 1. Critical circuitry will likely be tamper-resistant. Tamper-resistance techniques make it hard to see what's there, too. So, paradoxically, the very mechanisms used to protect circuitry against one attack make it more vulnerable to another. What this highlights, perhaps, is the need for transparent tamper-resistance techniques, which prevent tampering but don't interfere with inspec- tion. traditional approach is to make the compromise more expensive that any reasonable expectation of benefit (security proportional to risk). helping bracket expected fraud ROI is an infrastructure that can (quickly) invalidate (identified) compromised units. there has been some issues with these kinds of infrastructures since they have also been identified with being able to support DRM ( other kinds of anti-piracy) efforts. disclaimer: we actually have done some number of patents (that are assigned) in this area http://www.garlic.com/~lynn/aadssummary.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
re: http://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL so lots of the AADS http://www.garlic.com/~lynn/x959.html#aads scenarios are that every place a password might appear, have a public key instead. for various of the cookie authentication operations ... also think kerberos tickets. recent reference http://www.garlic.com/~lynn/2008c.html#31 Kerberized authorization service part of the scenario for cookie/ticket encryption ... involving servers, is brute force attack on the server secret key. the cookie instead of all encrypted data ... has some sort of client registration value ... analogous to an account number or userid. the cookie caries the registration value followed by the server encrypted data. the encryption part uses a derived key ... formed by combination of the server's secret key and the client's registration value. these derived key scenarios are also found in transit system operation (both magstripe and memory chip) as well as financial transactions. the issue then is initial registration ... the part where the user chooses their userid (and/or the client registration value is otherwise selected) and supplies a password (but in this case a public key). m'soft and others have been using CAPTCHA to weed-out the non-humans, but this has come under attacks. reference to recent news items http://www.garlic.com/~lynn/2008d.html#2 Spammer' bot cracks Microsoft's CAPTCHA the ticket/cookie carries the clients public key (and whatever other characteristics) ... which then can be used by the server(s) to perform dynamic authentication (digital signing of some server supplied, random data, countermeasure to replay attacks). this is in lieu of server having to maintain the client account record ... ala a RADIUS scenario where public key has been registered in lieu of a password (some sort of online access to RADIUS account records). various RADIUS public key in lieu of password postings: http://www.garlic.com/~lynn/subpubkey.html#radius the ticket/cookie scenario (with derived key encryption) is cross between dynamic server-side account record data (say RADIUS repository) and stale, static digital certificate scenario. as in the transit gate operation, the ticket/cookie could also be retrieved, decrypted, updated, re-encrypted, and returned as part of the operation. initial server hand-shakes can include server sending some random challenge data. The client returns the digital signature and their previously obtained cookie. in the straight RADIUS public key handshake scenario, just the digital signature and client userid/account-number is returned since the rest of the cookie/ticket equivalent info is online in the RADIUS account repository. The straight RADIUS scenario would be to combine the server-side random challenge data and combine it with the client registration value (account number, userid) and whatever else the client-side digital signing requires ... and return the userid/account-number any other data and digital signature (i.e. server-side has to be able to reconstruct what the client actually digitally signed as part of verifying the digital signature). In the straight RADIUS scenario, the public key (and any associated permissions, authorization, etc) is obtained from the RADIUS repository. In cookie/ticket scenario, it is obtained from the cookie/ticket appended to the message. The business process still has the initial registration phase ... where the original cookie is created (or in the RADIUS scenario, where the userid definitiion is initially created) and the public key is supplied (in lieu of a password). This is also effectively the original certificateless pk-init scenario for kerberos (aka public key in lieu of password) http://www.garlic.com/~lynn/subpubkey.html#kerberos The cookie scenario is standard client/server ... attempting to eliminate the server having to retain the account record on behalf of every client (as in either the RADIUS and/or KERBEROS scenario). Encrypting of the cookie data is standard ... although transit systems and financial transactions have gone to derived key for the situation ... as countermeasure to brute force attack on the infrastructure secret key. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
David Wagner wrote: I'd be interested in hearing your take on why SSL client certs aren't widely adopted. It seems like they could potentially help with the phishing problem (at least, the problem of theft of web authenticators -- it obviously won't help with theft of SSNs). If users don't know the authentication secret, they can't reveal it. The nice thing about using client certs instead of passwords is that users don't know the private key -- only the browser knows the secret key. The standard concerns I've heard are: (a) SSL client supports aren't supported very well by some browsers; (b) this doesn't handle the mobility problem, where the user wants to log in from multiple different browsers. So you'd need a different mechanism for initially registering the user's browser. By the way, it seems like one thing that might help with client certs is if they were treated a bit like cookies. Today, a website can set a cookie in your browser, and that cookie will be returned every time you later visit that website. This all happens automatically. Imagine if a website could instruct your browser to transparently generate a public/private keypair for use with that website only and send the public key to that website. Then, any time that the user returns to that website, the browser would automatically use that private key to authenticate itself. For instance, boa.com might instruct my browser to create one private key for use with *.boa.com; later, citibank.com could instruct my browser to create a private key for use with *.citibank.com. By associating the private key with a specific DNS domain (just as cookies are), this means that the privacy implications of client authentication would be comparable to the privacy implications of cookies. Also, in this scheme, there wouldn't be any need to have your public key signed by a CA; the site only needs to know your public key (e.g., your browser could send self-signed certs), which eliminates the dependence upon the third-party CAs. Any thoughts on this? in AADS http://www.garlic.com/~lynn/x959.html#aads and certificateless public key http://www.garlic.com/~lynn/subpubkey.html#certless we referred to the scenario as person-centric ... as a contrast to institutional-centric oriented implementations. past posts in this thread: http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch Transport Card Broken) http://www.garlic.com/~lynn/aadsm28.htm#24 Fixing SSL (was Re: Dutch Transport Card Broken) http://www.garlic.com/~lynn/aadsm28.htm#26 Fixing SSL (was Re: Dutch Transport Card Broken) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
a recent reference Research unmasks anonymity networks http://www.techworld.com/security/news/index.cfm?newsID=11295 Research unmasks anonymity networks http://www.networkworld.com/news/2008/020108-research-unmasks-anonymity.html Research unmasks anonymity networks http://www.arnnet.com.au/index.php/id;1270745171;fp;4194304;fpid;1 Paper Outlines Methods for Beating Anonymity Technology http://www.darkreading.com/document.asp?doc_id=144606 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
StealthMonger wrote: They can't be as anonymous as cash if the party being dealt with can be identified. And the party can be identified if the transaction is online, real-time. Even if other clues are erased, there's still traffic analysis in this case. What the offline paradigm has going for it is the possibility of true, untraceable anonymity through the use of anonymizing remailers and related technologies. most people who heard the statement, understood that. i think that possibly 2nd level detail was that they didn't want PII easily associated by casual merchant. Initial response was to remove name from payment cards magstripes. This also precluded merchants from requesting other forms of identification to see if the names matched the name on the payment card. The implication being that the payment infrastructure would have to come up with other mechanisms to improve the infrastructure integrity. The offline payment paradigms ... while touting true anonymity were actually primarily justified based on other factors. We had been asked to design and cost the dataprocessing supporting US deployments of some of the offline products (that were being used in Europe). Along the way, we did some business process and revenue analysis and realized that the primary motivation behind these system deployments was the float. About the same time that there was the EU about the privacy of electronic retail payments ... there was also a statement by the EU (and some of the country central banks) that the offline products would be allowed to keep the float for a short grace period to help in the funding of the infrastructure deployment ... but after the grace period ... the operators would have to start paying interest on the balance held in the offline instruments (eliminating float from the equation). After that, much of the interest in the offline deployments drifted away. In that time frame we had also done design, implementation and deployment of a payment transaction infrastructure supporting target marketing ... recent reference http://www.garlic.com/~lynn/2008c.html#27 Diversity support was for a small pilot of 60mil accounts and 1.5million transaction/day ... but capable of scaling up to 20-30 times that amount. There was significant attention paid to privacy issues and it was subject to quarterly auditing by some dozen or so privacy organizations. there had to be a large amount of sensitive treatment of the information along the lines of what HIPAA specifies for health information. aka: anonymized Previously identifiable data that have been deidentified and for which a code or other link no longer exists. An investigator would not be able to link anonymized information back to a specific individual. [HIPAA] (see also anonymous, coded, directly identifiable, indirectly identifiable) as part of co-authoring x9.99 financial privacy standard, one of the things we created was a privacy merged glossory and taxonomy ... including GLBA, HIPAA, and EU-DPD references some notes: http://www.garlic.com/~lynn/index.html#glosnote in our work on x9.59 financial transaction standard http://www.garlic.com/~lynn/x959.html#x959 we made the statement that it was privacy agnostic ... since the transactions were tied to accounts ... but then whether or not the accounts were tied to individuals was outside the x9.59 standard http://www.garlic.com/~lynn/subpubkey.html#x959 As a total aside ... as part of the Digicash liquidation, we were brought in to evaluate the patent portfolio. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Victor Duchovni wrote: SMTP does not need TCP to provide reliability for the tail of the session, the application-level . (end-of-data) and server 250 response complete a transaction, everything after that is optional, so for example Postfix will send (when PIPELINING). DATACRLF354 Go ahead Message-Content Lots of acks .CRLFQUITCRLF 250 Ok and will disconnect after reading the 250 response without waiting for the 221 response. The TCP 3-way shutdown (FIN, FIN-ACK, ACK) happens in the kernel in the background, the SMTP server and client are by that point handling different connections. So the reliable shutdown latency is of no consequence for application throughput. A pipelined SMTP delivery can be completed over TCP in 5 RTTs not 7. 0. SYN SYN-ACK 1. ACK 220 2. EHLO 250 3. MAIL RCPT DATA 250 250 354 4. MSG . QUIT 250 221 5. close socket TCP is fine, latency is primarily the result of application protocol details, not TCP overhead. The only TCP overhead above is 1 extra RTT for the connection setup. Everything else is SMTP not TCP, and running SMTP over UDP (with ideal conditions and no lost packets, ...) would save just 1 RTT. re: http://www.garlic.com/~lynn/aadsm28.htm#21 Dutch Transport Card Broken sorry, I didn't say that TCP required seven round-trips for reliable exchange; the statement was that minimum TCP operation was seven packet exchange (for reliable operation) sort of 3.5 round-trips. That VMTP (rfc 1045) reduced that to minimum of five packet exchange (sort of 2.5 round-tips) ... and that XTP got it to a minimum of three packet exchange (sort of 1.5 round-trips) for reliable operation. from my RFC index http://www.garlic.com/~lynn/rfcietff.htm rfc 1045 summary http://www.garlic.com/~lynn/rfcidx3.htm#1045 1045 E VMTP: Versatile Message Transaction Protocol: Protocol specification, Cheriton D., 1988/02/01 (123pp) (.txt=264928) (Refs 955, 966, 969) (Ref'ed By 1050, 1072, 1105, 1106, 1190, 1263, 1323, 1453, 1458, 1700, 2018, 2375, 2757) (VMTP) as always, clicking on the .txt=nnn field (in rfc summary) retrieves the actual RFC. If there is more than minimum amount of data ... TCP might involve more than seven packet exchange ... but the minimum packet exchange is seven packets (not round-trips). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Ian G wrote: The PII equation is particularly daunting, echoing Lynn's early '90s experiences. I am told (but haven't really verified) that the certificate serial number is PII and therefore falls under the full weight of privacy law regs ... this may sound ludicrous, but privacy and security are different fields with different logics. If that is true, the liability is far too high for something that should be private, but is already public by dint of its exposure in certificates. Privacy liabilities are sky-high in some places, and not only that, they are incalculable, unknowable, and vary with the person you are talking to. So a superficial conclusion would be don't use client certificates because of the privacy issues although the issues are somewhat more complex than PII revealed in SSL key exchange. As I say, they'll plug on, as they need to prove that the cert is worth issuing. It's a data point, no more, and it doesn't exactly answer your spec above. But I'm having fun observing them trying to prove that client certs are worth any amount of effort. the problem that digital certificates were suppose to address was first time communication between strangers ... the electronic analogy of the letters of credit/introduction from sailing ship days. this harks back to the offline email days of the early 80s ... dial-up electronic post-office, exchange email, hangup, and now authenticate first-time email from total stranger. the design point assumptions are invalidated if the relying party has their own repository of information about the party being dealt with (and therefor can included that party's public key) and/or has online, timely electronic access to such information. one of my favorite exchanges from the mid-90s was somebody claiming that adding digital certificates to the electronic payment transaction infrastructure would bring it into the modern age. my response was that it actually would regress the infrastructure at least a couple decades to the time when online, real-time transactions weren't being done. The online, real-time transaction provides much higher quality and useful information than a stale, static digital certificate (with an offline paradigm from before modern communication). Having an available repository about the party being dealt with ... including things like timely, aggregated information (recent transactions) is significantly mover valuable than the stale, static digital certificate environment (the only thing that it has going for it, is it is better than nothing in the oldtime offline environment). misc. past posts referencing certificate-less public key operation http://www.garlic.com/~lynn/subpubkey.html#certless for some real topic drift ... i've mentioned x9.59 financial standard protocol that can use digital signatures for authentication w/o requiring digital certificates http://www.garlic.com/~lynn/x959.html#x959 part of the issue included that digital certificates (even relying party only digital certificates) can add a factor of one hundred times payload bloat to a typical payment transaction http://www.garlic.com/~lynn/subpubkey.html#bloat however, we were also got involved in co-authoring the x9.99 privacy standard ... as part of that we had to look at a number of things, HIPAA, GLBA ... as well as EU-DPD. as part of that we had also done a privacy merged taxonomy and glossary ... some notes http://www.garlic.com/~lynn/index.html#glosnote EU had also made a statement in the mid-90s that electronic retail payments should be as anonymous as cash. The dominant use of SSL in the world today is electronic commerce between a consumer and a merchant. Passing a client certificate (with PII information) within an encrypted SSL channel to a merchant ... still exposes the information to the merchant ... also violating making purchases as anonymous as cash. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Nicolas Williams wrote: I don't have one that exists today and is practical. But we can certainly imagine possible ways to improve this situation: move parts of TLS into TCP and/or IPsec. There are proposals that come close enough to this (see the last IETF SAAG meeting's proceedings, see the IETF BTNS WG) that it's not too farfetched, but for web stuff I just don't think they're remotely likely. my view of ipsec was that it faced a significant barrier to entry since it required upgrading lots of installed kernels all over the infrastructure (aka tcp/ip protocol stack have been integrated kernel implementations) both SSL and VPN offered implementations that require having to upgrade existing deployed kernels (something that has gotten somewhat easier in the last decade plus). about the same time as SSL, a friend that we had worked on off with over a couple decades introduced what was to become called VPN in gateway committee at fall '94 IETF meeting in san jose. my view was this resulted in some amount of consternation with the ipsec forces as well as some of the router vendors. the ipsec forces were somewhat mollified by being able to refer to vpn as lightweight ipsec (while others then would refer to ipsec as heavyweight ipsec). the initial proposal involved border routers providing authentication and (encryption) tunneling through the internet. some of the router vendors had processors that could handle the encryption load. however, there was opposition from the router vendors that didn't have products with processors that could handle the encryption load (or at least stalling until they had such a product). in any case, uptake of both SSL and VPN ... was the significantly easier and less complex deployment ... vis-a-vis ipsec. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Victor Du Jumping in late, but the idea that *TCP* (and not TLS protocol design) adds round-trips to SSL warrants some evidence (it is very temping to express this skepticism more bluntly). With unextended SMTP for example, the minimum RTT count is: 0. SYN SYN-ACK 1. ACK 220 2. HELO 250 3. MAIL 250 4. RCPT 250 ... n recipients RCPT 250 4+n DATA 354 5+n ... stream of message content segmentsCRLF.CRLF 250 so it takes at least 6 RTTs to perform a delivery (of a short single-recipient message), but only 1 of the 6 RTTs is TCP overhead. This is improved with PIPELINING: 0. SYN SYN-ACK 1. ACK 220 2. EHLO 250 ... PIPELINING ... 3. MAIL RCPT(n times) DATA 250 250 (n times) 354 4. ... stream of message content segmentsCRLF.CRLF 250 re: http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch Transport Card Broken) TCP requires minimum of seven message exchange for reliable transport VMTP (rfc 1045) got that down to minimum of five messages, and XTP then got it down to three messages minimum for reliable transport (disclaimer we were on the XTP technical advisory board). i've frequently pontificated that with reliable registration of public keys in the dns system and then piggy-backing any registered public key in standard DNS response then it would be possible to encode the randomly generated secret key (with that public key) and the encrypted message in the XTP packet for minimum 3 packet exchange. http://www.garlic.com/~lynn/subtopic.html#subpubkey.html#catch22 http already went thru its period of problems of implicit assumptions with tcp. tcp sessions were assumed to be long lived and session shutdown was assumed to be relatively infrequently. non-session activity like http was always assumed to use udp for efficiency. the http ignored all of that and used tcp for non-session activity. as a result, webserver systems went thru a period where the processors was spending 95+ percent of processor in the session shutdown processing. systems then were retrofited with new kind of tcp session shutdown implementation to handle the misuse by http. the original ssl deployment was to 1) encrypt data in transit and 2) authenticate the server. the implicit assumption was that the user understood the binding between the business and the url. the browser then provided the second part, verifying the binding between the url and the server contacted (was the server that the user thot they were talking to, the server they were actually talking to). The dependency for valid ssl operation was violated almost immediately when merchants found that ssl overhead reduced thru thruput by 5-10 times. the regression was instead of initial contact of the webserver (presumably url supplied by user) being ssl, ssl was moved to checkout/pay phase where the user clicked on a button (and url) provided by the webserver (not a url provided by the user). It was no longer possible to provide any assurances as to the authentity of the webserver contacted (ssl purely being reduced to encrypting data in transmission). we had been called in to consult with the small client/server company on using this technology (they created) called SSL for payment transactions http://www.garlic.com/~lynn/subnetwork.html#gateway and had to go thru detailed walk thrus of the technology as it applied to actual business processes (and the associated implicit dependencies) ... as well as detailed walk thrus of the new business operations that were calling themselves certification authorities. the other issue that we came up in applying this SSL technology was communication between webservers and something called the payment gateway. for this communication we mandated mutual authentication ... this was before mutual authentication had been implemented in SSL. It turns out that by the time we had it all implemented and deployed ... it also became very apparent that the things called digital certificates were redundant and superfluous. the basic design point for digital certificates is first time communication between total strangers. the payment gateway business processes required that all the merchants had to be pre-registered with the payment gateway and the payment gateway pre-registered with all the merchants violating the basic justification for having digital certificates. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Philipp Gühring wrote: Yes, sending client certificates in plaintext while claiming that SSL/TLS is secure doesn´t work in a world of phishing and identity theft anymore. We have the paradox situation that I have to tell people that they should use HTTPS with server-certificates and username+password inside the HTTPS session, because that´s more secure than client certificates ... Does anyone have an idea how we can fix this flaw within SSL/TLS within a reasonable timeframe, so that it can be implemented and shipped by the vendors in this century? (I don´t think that starting from scratch and replacing SSL makes much sense, since it´s just one huge flaw ...) re: http://www.garlic.com/~lynn/aadsm28.htm#15 Dutch Transport Card Broken http://www.garlic.com/~lynn/aadsm28.htm#16 Dutch Transport Card Broken aka ... that was part of the relying-party-only certificates from the mid-90s; http://www.garlic.com/~lynn/subpubkey.html#rpo i.e. the x.509 identity digital certificates from the early 90s, were becoming more and more overloaded with personal information ... and by the mid-90s, lots of institutions were starting to realize all that personal information represented significant privacy and liability issues ... and the RPO digital certificates were born. However, it was trivial to demonstrate that (for all those business processes) that the digital certificates were redundant and superfluous (however, there was some amount of industry brain washing that digital certificates were mandatory ... especially if digital signatures was used ... even if they served no useful purpose). this also showed up in work on pk-init for kerberos supporting digital signature authentication ... and got into the confused mess with redundant and superfluous digital certificates http://www.garlic.com/~lynn/subpubkey.html#kerberos and similarly digital signatures for radius http://www.garlic.com/~lynn/subpubkey.html#radius (between kerberos and radius, they represent possibly the majority of authentication in the world today) part of the confusion regarding the necessity for digital certificates could be seen in the X9F financial standards work ... the appending of even a relying-party-only digital certificate (lacking any personal information) could represent a factor of 100 times payload bloat http://www.garlic.com/~lynn/subpubkey.html#bloat for a nominal electronic payment transactions (and also 100 times processing bloat). as a result, there was some standardization effort looking at compressed (relying party only) digital certificates (even tho they were serving no useful purpose), attempting to get the payload bloat down to possibly only 5-10 times (instead of 100 times). I took the opportunity to demonstrate that it would be logically possible to compress such digital certificates to zero bytes ... totally eliminating the payload bloat. then rather than advocating the elimination of totally useless, redundant and superfluous digital certificates http://www.garlic.com/~lynn/subpubkey.html#certless there could be an infrastructure that mandated zero-byte digital certificates appended to every transaction. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Lack of fraud reporting paths considered harmful.
Perry E. Metzger wrote: This evening, a friend of mine who shall remain nameless who works for a large company that regularly processes customer credit card payments informed me of an interesting fact. His firm routinely discovers attempted credit card fraud. However, since there is no way for them to report attempted fraud to the credit card network (the protocol literally does not allow for it), all they can do is refuse the transaction -- they literally have no mechanism to let the issuing bank know that the card number was likely stolen. This seems profoundly bad. I hope that someone on the list has the right contacts to get the right people to do something about this. some chance they are doing this to save money on transactions that aren't likely to be approved ... i.e. rather than be charged for a transaction that they send thru to the issuer that they are sure to be rejected ... they reject it upfront. now the associations have standard procedure to perform stand-in when the network accepts a transaction from an acquirer but isn't able to forward it to the issuer. stand-in allows the network to decide whether to approve or reject the transaction using simplified rules. later, when contact is re-established with the issuer ... the issuer has to be informed of all the stand-in activity. a possible simplified mechanism is to be able to generate a simulated stand-in report of rejected transactions. the issue then in such a simulated stand-in role ... for all the reasons that they chose to reject a transaction ... do they map into the standard iso 8583 codes for reasons that the issuer would reject the transaction. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Aram Perez wrote: Not to defend the designers in any way or fashion, but I'd like to ask, How much security can you put into a plastic card, the size of a credit card, that has to perform its function in a secure manner, all in under 2 seconds (in under 1 second in parts of Asia)? And it has to do this while receiving its power via the electromagnetic field being generated by the reader. we sort of saw that in the mid-90s when we were doing the x9.59 financial standard http://www.garlic.com/~lynn/x959.html#x959 and getting comments that it wasn't possible to have both low cost and high security at the same time. we looked at it and made the semi-facetious statements that we would take a $500 milspec part and aggresively cost reduce it by 2-3 orders of magnitude will improving the security. along the way we got tapped by some in the transit industry to also be able to meet the (then) transit gate requirements (well under 1 second and do it within iso 14443 power profile). part of it was having to walk the whole end-to-end process ... all the way back to chip design and fab manufacturing process ... little drift about walking fab in a bunny suit http://www.garlic.com/~lynn/2008b.html#13 we effectively did get it on close to the RFID chip (i.e. the one that they are targeting for UPC) technology curve ... i.e. chip fabrication cost is roughly constant per wafer ... wafer size and circuit size have been leading to higher number of chips per wafer (significantly reducing cost/chip). As circuit size shrank with a corresponding shrinkage in the size of chips (that didn't have corresponding increase in number of circuits) there was a blip on the cost/chip curve as the area of the cuts (to separate chips in the wafer) exceeded the (decreasing) chip size. Earlier this decade there was a new cutting process that significantly reduced the cut area ... allowing yield of (small) chips per wafer to continue to significantly increase (allowing pushing close to four orders of magnitude reduction ... rather than 3-4 orders of magnitude reduction). aads chip strawman references http://www.garlic.com/~lynn/x959.html#x959 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
my impression has been that with lack of takeup of various kinds of security solutions that were extensively marketed in the 90s ... that the current situation has many of those same organizations heavily involved in behind the scenes lobbying saw some of that nearly a decade ago when we were brought in to help wordsmith the cal. state electronic signature legislation which led to also be brought in on federal electronic signature legislation ... some past posts http://www.garlic.com/~lynn/subpubkey.html#signature some other references ... Hackers break into transport smart card http://www.dutchnews.nl/news/archives/2008/01/german_hackers_break_transport.php Transport smart card hacked again (update) http://www.dutchnews.nl/news/archives/2008/01/transport_smart_card_hacked_ag.php - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Death of antivirus software imminent
Leichter, Jerry wrote: Virtualization has become the magic pixie dust of the decade. When IBM originally developed VMM technology, security was not a primary goal. People expected the OS to provide security, and at the time it was believed that OS's would be able to solve the security problems. re: http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software iminent http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software iminent http://www.garlic.com/~lynn/aadsm28.htm#8 Death of antivirus software iminent the other claim was that it was assumed that basic systems were built to be secure, so it would have been quite foreign idea it would be necessary to build a secure specific system. besides the referenced fairly wide use of gov and commercial institutions requiring high integrity systems ... the early virtual machine systems (cp67 and vm370) were also used by commercial time-sharing service bureaus. most of these created cms padded cell modifications, a lot of it was to prevent users from damaging themselves (as opposed to the underlying security that prevented uses from damaging the system and/or each other). at least some of these services provided online, concurrent services to (competitive) wall street firms ... who would be using the online services for highly sensitive financial activities (as example of integrity requirements). a little related x-over from posting in this thread http://www.garlic.com/~lynn/2008.html#14 hacked TOPS-10 monitors - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Death of antivirus software imminent
Bill Frantz wrote: My favorite virtual machine use is for the virus to install itself as a virtual machine, and run the OS in the virtual machine. This technique should be really good for hiding from virus scanners. re: http://www.garlic.com/~lynn/aadsm28.htm#2 Death of antivirus software imminent http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software imminent i commented on that in reference posts mentioning that there have been uses of virtual machines to study virus/trojans ... but that some of the new generation virus/trojans are now looking to see if they are running in virtual machine (studied?). some of the current trade-off is whether that virtual machine technology can be used to partition off basically insecure operations (which are widely recognized as being easy to compromise) and then completely discard the environment and rebuild from scratch after every session (sort of the automated equivalent of having to manually wipe an infected machine and re-install from scratch). the counter argument is that crooks can possibly also use similar technology to hide ... once they have infected the machine. the current issue is that a lot of the antivirus/scanning techniques are becoming obsolete w/o the attackers even leveraging virtual machine technology. The attackers can leverage the technology in an otherwise poorly defended machine. Some years ago there was a product claiming that it could operate even at a public access machine because of their completeness of their antivirus countermeasures ... even on an infected machine. I raised the issue that it would be trivial to defeat all such countermeasures using virtual machine technology. Somewhat of a skirmish resulted since they had never considered (or heard of) virtual machine technology ... for all i know there is still ongoing head-in-the-sand situation. for little topic drift ... this blog entry: https://financialcryptography.com/mt/archives/000991.html and http://www.garlic.com/~lynn/aadsm28.htm#3 http://www.garlic.com/~lynn/aadsm28.htm#5 there is some assertion that the crooks overwhelming the defenders countermeasures because they are operating significantly faster and more efficiently. however, another interpretation is that the defenders have chosen extremely poor position to defend ... and are therefor at enormous disadvantage. it may be necessary to change the paradigm (and/or find the high ground) in order to successfully defend. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Death of antivirus software imminent
re: Storm, Nugache lead dangerous new botnet barrage http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1286808,00.html from above: The creators of these Trojans and bots not only have very strong software development and testing skills, but also clearly know how security vendors operate and how to outmaneuver defenses such as antivirus software, IDS and firewalls, experts say. They know that they simply need to alter their code and the messages carrying it in small ways in order to evade signature-based defenses. Dittrich and other researchers say that when they analyze the code these malware authors are putting out, what emerges is a picture of a group of skilled, professional software developers learning from their mistakes, improving their code on a weekly basis and making a lot of money in the process. ... snip ... ... and somewhat related Virtualization still hot, death of antivirus software imminent, VC says http://www.networkworld.com/news/2007/121707-crystal-ball-virtualization.html from above: Another trend Maeder predicts for 2008 is, at long last, the death of antivirus software and other security products that allow employees to install and download any programs they'd like onto their PCs, and then attempt to weed out the malicious code. Instead, products that protect endpoints by only allowing IT-approved code to be installed will become the norm. ... snip ... and post about dealing with compromised machines http://www.garlic.com/~lynn/2007u.html#771 folklore indeed mentioning sophistication in other ways: Botnet-controlled Trojan robbing online bank customers http://www.networkworld.com/news/2007/121307-zbot-trojan-robbing-banks.htm from above: If the attacker succeeds in getting the Trojan malware onto the victim's computer, he can piggyback on a session of online banking without even having to use the victim's name and password. The infected computer communicates back to the Trojan's command-and-controller exactly which bank the victim has an account with. It then automatically feeds code that tells the Trojan how to mimic actual online transactions with a particular bank to do wire transfers or bill payments ... snip ... there have been some number of online banking countermeasures for specific kinds of system compromises like keyloggers ... but they apparently didn't bother to get promises from the crooks to only limit the kinds of attacks to those exploits. some related comments on such compromised machines http://www.garlic.com/~lynn/aadsm27.htm#66 2007: year in review http://www.garlic.com/~lynn/aadsm28.htm#0 2007: year in review - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 2008: The year of hack the vote?
Jack Lloyd wrote: The only reason this 'must' be true is because an anonymous and secure payment system is a terror which thankfully our federal governments and central banks protect us from. While Amazon and others obviously like being able to build customer profiles of everyone, I don't doubt that they would be perfectly willing to accept an anonymous payment as long as the money is good (and, of course, that the transaction costs are no more than a credit card and/or the order flow is sufficient that it is worth building support for it). in the mid-90s, the x9a10 financial standard working group had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments ... which resulted in the x9.59 standard http://www.garlic.com/~lynn/x959.html#x959 in the same timeframe, the EU (in conjunction with eu-dpd) made statements that electronic payments at point-of-sale should be as anonymous as cash. this was interpreted as meaning that names should be removed from payment cards (plastic and magstripe). the contention was that (because of poor authentication) retail outlets could cross-check names on the cards against some other form of ID. the implication that removing names might help promote other integrity measures. in the x9.59 standard, we claimed that the improved integrity allowed meeting the EU-DPD objectives. We also claimed that x9.59 was privacy agnostic i.e. it allowed for privacy. The ALL requirement given to the x9a10 financial standard working group met internet, face-to-face, point-of-sale, electronic commerce. It also met debit, credit, ACH, as well as stored-value cards ... aka the same X9.59 was applicable to *ALL*. In the debit/credit scenario some countries have know your customer mandates associating account numbers with individuals ... which we claimed was outside the x9.59 standard. Supposedly with appropriate regulated access to information, govs can obtain information associating account activity with individuals. However, the very same x9.59 standard also works with stored-value/gift cards ... which doesn't have similar know your customer mandates. http://www.garlic.com/~lynn/subpubkey.html#privacy And in fact, most stored-value/gift cards share a lot of the same exact processing with the debit/credit processing ... the addition of x9.59 could provide for the exactly same level of integrity thruout debit, credit, and stored-value/gift processing. for other drift, in the mid-90s ... there were some of the other payment efforts specifically for the internet which had so much payload and processing bloat that it made it impractical past the toy demo stage http://www.garlic.com/~lynn/subpubkey.html#bloat related recent post on infrastructure provisioning and bloat of toy demos: http://www.garlic.com/~lynn/2007v.html#64 folklore indeed about the same time, there were completely different chip card oriented efforts for point-of-sale. one of the scenarios of some of the chipcard pilot projects in the late 90s and early part of this century was that they managed to increase the vulnerabilities (magstripe vis-a-vis chipcards) http://www.garlic.com/~lynn/subintegrity.html#yescard the common excuse from the period, was that chips cost so much that it wasn't possible to afford integrity that actually improved over magstripe. The other possible observation was that some of the chipcard efforts were so chip myopic ... that they couldn't realize that they were actually making it worse for the overall infrastructure. A big issue for merchants isn't anonymous payments ... it is cost of doing business. This has been in the news quite a bit recently in the form of interchange fees ... recent posts http://www.garlic.com/~lynn/2007v.html#62 folklore indeed the other area is in the liability related to breaches (and/or the costs of countermeasures to breaches). i've mentioned before that we had been called in to consult with small client/server startup that wanted to do payments on their server. They had this technology they called SSL and it is frequently now referred to as electronic commerce http://www.garlic.com/~lynn/subnetwork.html#gateway and then we got dragged into involved with the x9a10 financial standard. as part of attempting to meet the requirement to preserve the integrity of the financial infrastructure for all retail payments ... we did some detailed threat and vulnerability analysis. A big item that came out were infrastructure vulnerabilities ... breaches, skimming, harvesting, evesdropping, ... a whole slew of things. we identified that much of the vulnerability could be attributed to the account number and transaction information has diametrically opposing requirements ... 1) it has to be readily available for large number of different business processes and 2) since the crooks can use the same information for various kinds of essentially replay attacks ... the information has to be kept confidential and never
Re: Fingerprint Firefox Plugin?
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. http://www.garlic.com/~lynn/2007q.html#2 Windows Live vs Kerberos http://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 http://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 http://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
Re: a fraud is a sale, Re: The bank fraud blame game
re: http://www.garlic.com/~lynn/aadsm27.htm#39 a fraud is a sale, Re: The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#40 a fraud is a sale, Re: The bank fraud blame game 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: http://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=viewArticleBasicarticleId=9010082aintsrc=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=newscmd=detailsnewsid=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. ttp://www.informationweek.com/news/showArticle.jhtml?articleID=197800774 ID fraud soaring across the pond http://www.silicon.com/financialservices/0,3800010322,39166236,00.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
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: http://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 the 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. 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 http://www.garlic.com/~lynn/subintegrity.html#yescard For the float issue with regard to this 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 http://www.garlic.com/~lynn/aepay11.htm#28 Solving the problem of micropayments http://www.garlic.com/~lynn/aepay11.htm#70 Confusing Authentication and Identiification? (addenda) http://www.garlic.com/~lynn/aadsm16.htm#12 Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed) http://www.garlic.com/~lynn/aadsm18.htm#39 Financial identity is *dangerous*? (was re: Fake companies, real money) http://www.garlic.com/~lynn/aadsm21.htm#12 Payment Tokens http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash http://www.garlic.com/~lynn/2001m.html#4 Smart Card vs. Magnetic Strip Market http://www.garlic.com/~lynn/2002c.html#22 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002c.html#23 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002d.html#41 Why? http://www.garlic.com/~lynn/2002e.html#22 Opinion on smartcard security requested http://www.garlic.com/~lynn/2003h.html#54 Smartcards and devices http://www.garlic.com/~lynn/2004j.html#39 Methods of payment http://www.garlic.com/~lynn/2004j.html#43 Methods of payment http://www.garlic.com/~lynn/2005g.html#34 Maximum RAM and ROM for smartcards - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
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. http://www.garlic.com/~lynn/aepay6.htm#cacr7 7th CACR Information Security Workshop http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS http://www.garlic.com/~lynn/aadsm18.htm#42 Payment Application Programmers Interface (API) for IOTP http://www.garlic.com/~lynn/aadsm20.htm#7 EMV http://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards? http://www.garlic.com/~lynn/aadsm23.htm#23 Payment systems - the explosion of 1995 is happening in 2006 http://www.garlic.com/~lynn/aadsm25.htm#31 On-card displays http://www.garlic.com/~lynn/2002e.html#14 EMV cards http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002g.html#53 Are you sure about MONDEX? http://www.garlic.com/~lynn/2002g.html#54 Are you sure about MONDEX? http://www.garlic.com/~lynn/2004j.html#12 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento http://www.garlic.com/~lynn/2004j.html#14 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento http://www.garlic.com/~lynn/2005i.html#10 Revoking the Root http://www.garlic.com/~lynn/2005v.html#1 Is Mondex secure? http://www.garlic.com/~lynn/2007b.html#47 newbie need help (ECC and wireless) http://www.garlic.com/~lynn/2007i.html#57 John W. Backus, 82, Fortran developer, dies - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
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) http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game that even the transfer of a little bit of institutional knowledge would have enabled the avoidance of later smartcard reader deployment disasters http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game However, following some of the early yes card deployments http://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. that aspect was highlighted in an 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 http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP http://www.garlic.com/~lynn/2002m.html#37 Convenient and secure eCommerce using POWF http://www.garlic.com/~lynn/2002m.html#39 Convenient and secure eCommerce using POWF - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: a fraud is a sale, Re: The bank fraud blame game
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. http://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#29 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#58 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#61 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007e.html#62 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#19 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#59 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/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. http://www.garlic.com/~lynn/2007k.html#12 IBM Unionization http://www.garlic.com/~lynn/2007k.html#13 IBM Unionization http://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based and articles about interchange fee represents the single large expense for some retail merchants http://www.garlic.com/~lynn/aadsm23.htm#37 3 of the big 4 - all doing payment systems http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now http://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop http://www.garlic.com/~lynn/2007.html#27 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007c.html#38 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007i.html#47 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#72 Free Checking - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
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: http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game 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. 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 plugplay. 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 conflicts, serial 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 plugplay (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 plugplay) 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 plugplay 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 http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP http://www.garlic.com/~lynn/2002m.html#37 Convenient and secure eCommerce using POWF http://www.garlic.com/~lynn/2002m.html#39 Convenient and secure eCommerce using POWF http://www.garlic.com/~lynn/2003n.html#35 ftp authentication via smartcard - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
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: http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game 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 were supporting something like 65 different software modem drivers (different modems, 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 remote 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 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 some 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 attack actually provides a URL to their own webserver for which they have a valid SSL digital certificate ... then they 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 image/picture authentication stuff is to imcrease 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 preclude the security attacks). lots of past posts mentioning MITM-attacks http://www.garlic.com/~lynn/subintegrity.html#mitm some specific past posts about MITM-attacks and bank site authentication http://www.garlic.com/~lynn/aadsm19.htm#21 Citibank discloses private information to improve security http://www.garlic.com/~lynn/aadsm26.htm#28 man in the middle, SSL http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL http://www.garlic.com/~lynn/aadsm26.htm#31 man in the middle, SSL ... addenda 2 http://www.garlic.com/~lynn/aadsm26.htm#56 Threatwatch: MITB spotted: MITM over SSL from within the browser http://www.garlic.com/~lynn/2007d.html#26 Securing financial transactions a high priority for 2007 part of this harks back to when were originally called
Re: TPM, part 2
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: http://www.garlic.com/~lynn/2006p.html#41 Device Authentication - The answer to attacks lauched using stolen passwords? http://www.garlic.com/~lynn/aadsm27.htm#9 Enterprise Right Management vs. Traditional Encryption Tools http://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 http://www.garlic.com/~lynn/x959.html#aads - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
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 http://www.garlic.com/~lynn/x959.html#aads other posts in this thread: http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#33 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#34 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
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 http://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 http://www.garlic.com/~lynn/x959.html#x959 that are armored with digital signature (integrity and authentication) ... misc. posts mentioning naked transaction metaphor http://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. http://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 threat and vulnerability 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 http://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 was moving across 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 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 Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
re: http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game slight addendas ... 1) EU finread http://www.garlic.com/~lynn/subintegrity.html#finread http://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 (fraud) 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-2dc2ad205126k=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) http://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 Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: The bank fraud blame game
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: http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game 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 party. 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). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A secure Internet requires a secure network protocol
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: http://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. http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://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 signing 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
A secure Internet requires a secure network protocol
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. http://www.garlic.com/~lynn/subintegrity.html#payment - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why self describing data formats:
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) http://www.garlic.com/~lynn/subtopic.html#sgml was invented at the science center in 1969 http://www.garlic.com/~lynn/subtopic.html#545tech ... some recent (science center) topic drift/references in this post http://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) 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 in the states 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 http://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 cp67vm370 for time-sharing services (both for internal corporate use and customers offering commercial, online time-sharing services using the platform) http://www.garlic.com/~lynn/subtopic.html#timeshare lots of past posts about long term performance monitoring, workload profiling, benchmarking and stuff leading up to things like capacity planning http://www.garlic.com/~lynn/subtopic.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 certificateless digital signature infrastructures http://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. 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
Re: Why self describing data formats:
re: http://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 http://www.garlic.com/~lynn/subtopic.html#systemr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A crazy thought?
re: http://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 http://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 http://www.garlic.com/~lynn/2007l.html#67 nouns and adjectives http://www.garlic.com/~lynn/2007l.html#68 nouns and adjectives http://www.garlic.com/~lynn/2007l.html#69 nouns and adjectives http://www.garlic.com/~lynn/2007l.html#70 nouns and adjectives the last posts drifts into the subject of some of the recent churn around identity activities ... also lengthy post on the subject here: http://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 http://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 http://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). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A crazy thought?
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: http://www.garlic.com/~lynn/aadsm27.htm#22 A crazy thought? http://www.garlic.com/~lynn/aadsm27.htm#26 A crazy thought? http://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 http://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 their 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: http://www.garlic.com/~lynn/aadsm27.htm#24 Why self describing data formats: http://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. http://www.garlic.com/~lynn/subpubkey.html#bloat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A crazy thought?
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 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 http://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 http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec? http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec? http://www.garlic.com/~lynn/aadsm27.htm#19 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#20 307 digit number factored http://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) http://www.garlic.com/~lynn/2007i.html#5 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#17 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#48 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007i.html#51 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007k.html#79 John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#0 Re: John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#2 Re: John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#6 Re: John W. Backus, 82, Fortran developer, dies http://www.garlic.com/~lynn/2007l.html#9 Re: John W. Backus, 82, Fortran developer, dies - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
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: http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec? http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec? http://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 http://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 http://www.garlic.com/~lynn/subpubkey.html#bloat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: dnssec?
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) http://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) http://www.garlic.com/~lynn/2006w.html#email850515 in this post http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network and rfc editor announcement from today my rfc index http://www.garlic.com/~lynn/rfcietff.htm http://www.garlic.com/~lynn/rfcindx16.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) http://www.garlic.com/~lynn/rfcindx16.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) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
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: http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored http://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: http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec? http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec? somewhat topic drift with DNS related trivia ... more than a decade before DNS http://www.garlic.com/~lynn/2007k.html#33 and some old email (predating dns) suggesting online, realtime public key server http://www.garlic.com/~lynn/2006w.html#email810515 in this post http://www.garlic.com/~lynn/2006w.htmL#12 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 307 digit number factored
re: http://www.garlic.com/~lynn/aadsm27.htm#14 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#15 307 digit number factored http://www.garlic.com/~lynn/aadsm27.htm#16 dnssec? http://www.garlic.com/~lynn/aadsm27.htm#17 dnssec? http://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 http://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. http://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 http://www.garlic.com/~lynn/aadsm11.htm#24 Proxy PKI. Was: IBM alternative to PKI? http://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch? http://www.garlic.com/~lynn/aadsm25.htm#19 Hamiltonian path as protection against DOS http://www.garlic.com/~lynn/2003e.html#34 Use of SSL as a VPN http://www.garlic.com/~lynn/2003l.html#23 Why more than 1 hole in FW for IPSec http://www.garlic.com/~lynn/2007d.html#37 MAC and SSL http://www.garlic.com/~lynn/2007g.html#63 The Perfect Computer - 36 bits? http://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
Re: 307 digit number factored
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. 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 verify 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 issue is that if 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 infrastructure. some collected catch-22 posts http://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 http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 and collection of posts mentioning payment processing and payment gateway http://www.garlic.com/~lynn/subnetworkhtml#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 http://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
Re: 307 digit number factored
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. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: 0wned .gov machines (was Re: Russian cyberwar against Estonia?)
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: http://www.garlic.com/~lynn/2007k.html#48 somewhat older reference: http://www.nsa.gov/selinux/list-archive/0409/8362.cfm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Enterprise Right Management vs. Traditional Encryption Tools
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). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Public key encrypt-then-sign or sign-then-encrypt?
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: http://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, authorizes, agrees, and/or approves) 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, approves, agrees, 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. http://www.garlic.com/~lynn/subpubkey.html#signature related and slightly facetious posting here: http://www.garlic.com/~lynn/aadsm26.htm#69 survey of RFC S/MIME signature handling as part of this thread http://www.garlic.com/~lynn/aadsm26.htm#67 survey of RFC S/MIME signature handling - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
