Re: A mighty fortress is our PKI, Part II
On Aug 17, 2010, at 4:20 AM, Peter Gutmann wrote: Your code-signing system should create a tamper-resistant audit trail [0] of every signature applied and what it's applied to. Peter. [0] By this I don't mean the usual cryptographic Rube-Goldbergery, just log the details to a separate server with a two-phase commit protocol to minimise the chances of creation of phantom non-logged signatures. ...thus once again demonstrating how much of good cryptographic practice is just good engineering/release management practice. A number of years ago, in addition to being in charge of much of the software development, I had the system management organization of the small software maker I worked at reporting to me. I formalized a process that the (already well run) organization already had in place. Any time *any* build of the software left the building, even if just for a demo, we marked that build as locked. We would never delete a locked build without a careful determination that it was, in fact, dead: No longer in use at any customer. We also, within 24 hours, did a special backup of the build onto a tape that went into permanent off-site storage. The one time I know of that we didn't follow these procedures (before they were officially put into place), a very large customer, at their insistence and after the sales guy who dealt with them swore they agreed to delete the copy we gave them, got a snapshot of a build from a developer's workstation just to see how the new version would look. Without telling us, the customer proceeded to roll this out at hundreds of sites, resulting in years of support grief, since it was impossible for us to determine exactly what went into the code they were running. We were later acquired by a much larger company that claimed they would teach us how to do big-league software engineering. Hah. That company was shipping software built on developer workstations as a day-to-day practice - they were just beginning to develop mechanisms to ensure that the stuff they shipped came through traceable, reproducible builds. Oh ... but their stuff was in Java, so was signed The signing was tightly controlled at a central location. Cue classic joke about using an armored car to deliver an envelope to someone living in a cardboard box. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Aug 04, 2010 at 10:46:44PM -0700, Jon Callas wrote: I think you'll have to agree that unlike history, which starts out as tragedy and replays itself as farce, PKI has always been farce over the centuries. It might actually end up as tragedy, but so far so good. I'm sure that if we look further, the Athenians had the same issues with it that we do today, and that Sophocles had his own farcical commentary. If you want to see a PKI tragedy in the making, have a look at the CRLs used by the US DoD. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Thor Lancelot Simon t...@rek.tjls.com writes: If you want to see a PKI tragedy in the making, have a look at the CRLs used by the US DoD. Only in the making? Actually it's all relative, in Japan the Docomo folks turned off CRLs because they found that even a relatively modest CRL (not just the DoD monsters) presented a nice DoS when sent over cellular data links. What happened was that as the CRLs grew, performance got worse and worse as the phone downloaded the CRL. It took them quite some time to diagnose that they were being DoS'd by their own PKI. Peter. - 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
On 2010-08-05 11:30 AM, David-Sarah Hopwood wrote: Signatures are largely a distraction from the real problem: that software is (unnecessarily) run with the full privileges of the invoking user. By all means authenticate software, but that's not going to prevent malware. A lot of devices are locked down so that you cannot install bad software. This is somewhat successful in preventing bad software from being installed, and highly successful in irritating users. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
And what else should Windows say? We put this through our time machine and noticed that at some time in the past it was signed and now it isn't? Absolutely, on initial install there's no way to know it was originally signed (if you're smart about it). But in another architecture Microsoft makes available (ClickOnce) software _upgrades_ that _were_ initially signed - but now are not - do not give indication that something fishy is going on. -tom - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
David-Sarah Hopwood david-sa...@jacaranda.org writes: Huh? I don't understand the argument being made here. It's a bogus argument, the text says: He took a legitimate software package and removed the signature of the digital certificate it contained, then installed the package on his computer. The Installer application didn't indicate that the certificate had been modified. The certificate wasn't modified, they just stripped the signature from the executable. Only an expert will be able to detect a problem, Schouwenberg said. And all Microsoft will tell you is that the file is not signed. And what else should Windows say? We put this through our time machine and noticed that at some time in the past it was signed and now it isn't? The rest of the story isn't much better: The Stuxnet worm, which surfaced last month, used fake Verisign digital certificates No, they were genuine certs, just in the wrong hands. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 30, 2010, at 4:58 AM, Peter Gutmann wrote: [0] I've never understood why this is a comedy of errors, it seems more like a tragedy of errors to me. That is because a tragedy involves someone dying. Strictly speaking, a tragedy involves a Great Person who is brought to their undoing and death because of some small fatal flaw in their otherwise sterling character. In contrast, comedies involve no one dying, but the entertaining exploits of flawed people in flawed circumstances. PKI is not a tragedy, it's comedy. No one dies in PKI. They may get embarrassed or lose money, but that happens in comedy. It's the basis of many timeless comedies. Specifically, PKI is a farce. In the same strict definition of dramatic types, a farce is a comedy in which small silly things are compounded on top of each other, over and over. The term farce itself comes from the French to stuff and is comedically like stuffing more and more feathers into a pillow until the thing explodes. So farces involve ludicrous situations, buffoonery, wildly improbable / implausible situations, and crude characterizations of well-known comedic types. Farces typically also involve mistaken identity, disguises, verbal humor including sexual innuendo all in a fast-paced plot that doesn't let up piling things on top of each other until the whole thing bursts at the seams. PKI has figured in tragedy, most notably when Polonius asked Hamlet, What are you signing, milord? and he answered, OIDs, OIDs, OIDs, but that was considered comic relief. Farcical use of PKI is far more common. We all know the words to Gilbert's patter-song, I Am the Very Model of a Certificate Authority, and Wilde's genius shows throughout The Importance of Being Trusted. Lady Bracknell's snarky comment, To lose one HSM, Mr. Worthing, may be regarded as a misfortune, but lose your backup smacks of carelessness, is pretty much the basis of the WebTrust audit practice even to this day. More to the point, not only did Cyrano issue bogus short-lived certificates to help woo Roxane, but Mozart and Da Ponte wrote an entire farcical opera on the subject of abuse of issuance, EV Fan Tutti. There are some who assert that he did this under the control of the Freemasons, who were then trying to gain control of the Austro-Hungarian authentication systems. These were each farcical social commentary on the identity trust policies of the day. Mozart touched upon this again (libretto by Bretzner this time) in The Revocation of the Seraglio, but this was comic veneer over the discontent that the so-called Aluminum Bavariati had with the trade certifications in siding sales throughout the German states, as well as export control policies since Aluminum was an expensive strategic metal of the time. People suspected the Freemasons were behind it all yet again. Nonetheless, it was all farce. Most of us would like to forget some of the more grotesque twentieth-century farces, like the thirties short where Moe, Larry, and Shemp start the Daddy-O DNS registration company and CA or the 23 Skidoo DNA-sequencing firm as a way out of the Great Depression. But S.J. Perleman's Three Shares in a Boat shows a real-world use of a threshold scheme. I don't think anyone said it better than W.C. Fields did in Never Give a Sucker an Even Break and You Can't Cheat an Honest Man. I think you'll have to agree that unlike history, which starts out as tragedy and replays itself as farce, PKI has always been farce over the centuries. It might actually end up as tragedy, but so far so good. I'm sure that if we look further, the Athenians had the same issues with it that we do today, and that Sophocles had his own farcical commentary. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Jon Callas j...@callas.org writes: But S.J. Perleman's Three Shares in a Boat Uhh. minor nitpick, it was Jerome K.Jerome who wrote Three Shares in a Boat. He followed it up with Three Certificates on the Bummel, a reference to the sharing of commercial vendors' code-signing keys with malware authors. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Aug 4, 2010, at 11:29 PM, Peter Gutmann wrote: Jon Callas j...@callas.org writes: But S.J. Perleman's Three Shares in a Boat Uhh. minor nitpick, it was Jerome K.Jerome who wrote Three Shares in a Boat. He followed it up with Three Certificates on the Bummel, a reference to the sharing of commercial vendors' code-signing keys with malware authors. Oh, well. You are, of course, correct. Jon - 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: A mighty fortress is our PKI, Part II
Anne Lynn Wheeler wrote: 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. Huh? I don't understand the argument being made here. Obviously Windows can't distinguish an unsigned executable from one where the was a signature that has been stripped. How could it possibly do that? Signatures are largely a distraction from the real problem: that software is (unnecessarily) run with the full privileges of the invoking user. By all means authenticate software, but that's not going to prevent malware. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com signature.asc Description: OpenPGP digital signature
Re: A mighty fortress is our PKI, Part II
On 7/28/10 at 8:52 PM, pfarr...@pfarrell.com (Pat Farrell) wrote: When was the last time you used a paper Yellow Pages? Err, umm, this last week. I'm in a place where cell coverage (ATT, Verizon has a better reputation) is spotty and internet is a dream due to a noisy land line. I needed to find a ceramic tile store. The paper yellow pages had survived being left in the driveway in the rain and I used it. However, I agree that this is the 2% case for many parts of the world. Cheers - Bill --- Bill Frantz|Web security is like medicine - trying to do good for 408-356-8506 |an evolved body of kludges - Mark Miller www.periwinkle.com | - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
At 07:16 AM 7/28/2010, Ben Laurie wrote: SSH does appear to have got away without revocation, though the nature of the system is s.t. if I really wanted to revoke I could almost always contact the users and tell them in person. This doesn't scale very well to SSL-style systems. Unfortunately, there _are_ ways that it can scale adequately. Bank of America has ~50 million customers, so J. Random Spammer sends out 500 million emails saying Bank of America is updating our security procedures, please click on the following link to update your browser. It's more efficient for BofA to send out the message themselves, only to actual subscribers, with the actual keys, helping to train them to accept phishing mail in the process, but apparently even doing it the hard way scales well enough for some people to make money. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Steven Bellovin s...@cs.columbia.edu writes: When I look at this, though, little of the problem is inherent to PKI. Rather, there are faulty communications paths. Oh no my Lord, I assure you that parts of it are excellent! :-). [...] how should the CA or Realtek know about the problem? [...] That was the whole point, that the whole system doesn't work, and it's the system as a whole that has to work, not just some parts of it. Here's another description, without the possibly confusing 't +/- x' stuff: Shortly after the malware appeared (or at least got noticed) it was added to anti-virus vendor databases and pushed out to users via updates. Some time later when it made headlines because of its use of the Realtek certificate, the CA that had issued it read about it in the news, contacted the certificate owner, and revoked it. However due to the dysfunctional nature of revocation handling, the certificate was still regarded as valid by Windows systems after it had been revoked, and of a range of machines running Windows 7, Vista, and XP, all with the latest updates and hotfixes applied and with automatic updates turned on, the first machine to notice the revocation and treat the signature as invalid didn't do so until a full week after the revocation had occurred, and some machines still regard the signature as valid even now (I've heard this before a number of times in software developer forums and mailing lists, plaintive complaints from users to the effect that I know this certificate is revoked, but no matter what I do I can't get the software to stop using it!). So while PKI and code-signing promise the user a fairly deterministic series of events in which A occurs, the B occurs, then C occurs, and then the user is safe, what actually happens in practice is that A occurs, then a comedy of errors ensues [0], and then the user is still unsafe while possibly being under the mistaken impression that they're actually safe. [0] I've never understood why this is a comedy of errors, it seems more like a tragedy of errors to me. A real-world demonstration of the relative effectiveness of various protection mechanisms occurred when I wanted to evaluate the ability of code-signing to protect users. A researcher sent me a copy of the signed malware (thanks!), and because of its nature encrypted it with AES using the RAR archiver. Because RAR (and indeed most other archivers) don't protect file metadata, the message was blocked by email scanners that identified the overall contents from the metadata even though the file contents themselves were encrypted. After some discussion with the IT people (yes, I am certain what the file is, it's a rather nasty piece of Windows malware, and I trust the sender to have sent me malware) they forwarded the email to the PowerPC Linux machine on which I read email, and which is rather unlikely to be affected by x86 Windows malware. Unfortunately I never could check it on the Windows system that I wanted to test it on because the instant it appeared on there the resident malware protection activated and deleted it again, despite various attempts to bypass the protection. Eventually I got it onto a specially-configured Windows system, which reported that both the signature and its accompanying certificate were valid (this is now two weeks after the CA had declared the certificate revoked). So it actually proved quite difficult to see just how ineffective PKI and code-signing actually was in protecting users from malware because the real protection mechanisms were so effective at doing their job. (It's also rather an eye-opener about the effectiveness, at least in some cases, of malware-protection software, no matter what I did I couldn't get the malware files onto a Windows PC in order to have the code-signing declare them valid and, by implication, perfectly safe). What's interesting here is the claim that AV companies could respond much faster. I'd say it's more than just a claim, the malware was first detected around 1 1/2 months ago and added to AV vendor databases, a full month later the certificate was declared revoked by the CA, and currently the majority of Windows systems still regard the signature as valid (I've had a report from someone else of one machine that records it as revoked, so at least one machine has been belatedly protected by the code signing, assuming the user doesn't just click past the warning as pretty much all of them will). So yes, I'd say the AV companies respond a helluva lot faster, and a helluva lot more effectively. The bigger lesson, for people who ever believed this to be the case, is don't rely on code signing to protect you from malware. Peter. - 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 08:44 PM, Steven Bellovin wrote: When I look at this, though, little of the problem is inherent to PKI. Rather, there are faulty communications paths. You note that at t+2-3 days, the CA read the news. Apart from the question of whether or not 2-3 days is shortly after -- the time you suggest the next step takes place -- how should the CA or Realtek know about the problem? [snip] The point about the communications delay is that it's inherent to anything involving the source company canceling anything -- whether it's a PKI cert, a pki cert, a self-validating URL, a KDC, or magic fairies who warn sysadmins not to trust certain software. While I'm quoting Steve, his comment really drives me to a bigger break. 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. How about we posit that there is networking everywhere? People carry cell phones that are serious computers and are connected to serious networks. When was the last time you used a paper Yellow Pages? How about thinking of a solution that addresses 98% of all transactions for 98% of all people in the places where 98% of business is done. At some point, the perfect is the enemy of the good. If you have a selling hut in the middle of nowhere, well, you probably don't have a lot of computer power either. So calculating to do an RSA signature is out of the question anyway. A risk based approach would have an algorithm that looks at the value of the transaction. Buying a meal at a fast food place is not worth a lot of effort, so the definition of shortly after can be a second or so. Buying new 3D TV can have a longer time, with the time allowance, and expected/acceptable response time, perhaps time for automated actuarial analysis. When you are signing a contract to buy a house, you can take a day to verify that everything is proper. We have fast computers and ubiquitous networking. Why are we still thinking about systems based on 3 inch think paper books? We seem to be solving a problem that no longer exists when you look at it from first principals. Pat -- Pat Farrell http://www.pfarrell.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Thu, Jul 29, 2010 at 3:09 AM, Nicolas Williams nicolas.willi...@oracle.com wrote: This is a rather astounding misunderstanding of the protocol. An OCSPResponse does contain unauthenticated plaintext[*], but that plaintext says nothing about the status of the given certificates -- it only says whether the OCSP Responder was able to handle the request. If a Responder is not able to handle requests it should respond in some way, and it may well not be able to authenticate the error response, thus the status of the responder is unauthenticated, quite distinctly from the status of the certificate, which is authenticated. Obviously only successful responses are useful. I agree on this and but the implementation of OCSP has to deal with all non definitive (to take the wording of the RFC) answers. That's where the issue is. All the exception case, mentioned in 2.3, are all unauthenticated and it seems rather difficult to provide authenticated scheme for that part as you already mentioned in [*]. That's why malware authors are already adding fake entries of OCSP server in the host file... simple and efficient. I just wanted to raise the point that a model like PK-i relying on complex scheme for security will easily fail at the obvious as the attacker is often choosing the shortest/fastest path to reach his goal. [*] It's not generally possible to avoid unauthenticated plaintext completely in cryptographic protocols. The meaning of a given bit of unauthenticated plaintext must be taken into account when analyzing a cryptographic protocol. -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- Knowledge can create problems, it is not through ignorance -- that we can solve them Isaac Asimov - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 2010-07-29 12:18 AM, Peter Gutmann wrote: This does away with the need for a CA, because the link itself authenticates the cert that's used. Then there are other variations, cryptographically generated addresses, ... all sorts of things have been proposed. The killer, again, is the refusal of any browser vendor to adopt any of it. Bittorrent links have this property. A typical bittorent link looks like magnet:?xt=urn:btih:2ac7956f6d81bf4bf48b642058d31912479d8d8edn=South+Park+S14E06+201+HDTV+XviD-FQM+%5Beztv%5Dtr=http%3A%2F%2Fdenis.stalker.h3q.com%3A6969%2Fannounce It is the equivalent of an immutable file in Tahoe. In the case of FF someone actually wrote the code for them, and it was rejected. Without support from browser vendors, it doesn't matter what cool ideas people come up with, it's never going to get any better. The browser vendors are married to the CAs - 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: 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 mighty fortress is our PKI, Part II
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerry Leichter leich...@lrw.com writes: The only conceivable purpose for using a signature is that you can check it *offline*. If you assume you can connect to the network, and that you can trust what you get from the network - why bother with a signature? Simply check a cryptographic hash of the driver against an on-line database of known good drivers. This is right in line with Lynn Wheeler's frequent mention here that the use case for offline verification of certs for commerce basically doesn't exist. It was a nice theory to develop 30 years ago, but today the rest of the framework assumes connectivity, and you buy nothing but additional problems by focusing on making just one piece work off-line. Not quite. Untraceable anonymity and untraceable pseudonymity remain one of the important applications of cryptography, and both depend on store and forward anonymizing networks which mix traffic by using high random latency. The saving qualifier for your assertion is for commerce. True, there is not yet a way to securely transmit and store commercial value (money) offline, but it has not been proven impossible. For these applications, the security has to be in the message, not the connection. Offline verification is essential. -- StealthMonger stealthmon...@nym.mixmin.net -- stealthmail: Scripts to hide whether you're doing email, or when, or with whom. mailto:stealthsu...@nym.mixmin.net Finger for key. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iEYEARECAAYFAkxReuIACgkQDkU5rhlDCl7izQCfXuxcHdDT5c54EpATviI+PXCO MFEAoI62kO/DZcwkw++BpQ4Ey5jTVro6 =6mIw -END PGP SIGNATURE- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Thu, Jul 29, 2010 at 10:50:10AM +0200, Alexandre Dulaunoy wrote: On Thu, Jul 29, 2010 at 3:09 AM, Nicolas Williams nicolas.willi...@oracle.com wrote: This is a rather astounding misunderstanding of the protocol. [...] I agree on this and but the implementation of OCSP has to deal with all non definitive (to take the wording of the RFC) answers. That's where the issue is. All the exception case, mentioned in 2.3, are all unauthenticated and it seems rather difficult to provide authenticated scheme for that part as you already mentioned in [*]. That's why malware authors are already adding fake entries of OCSP server in the host file... simple and efficient. A DoS attack on OCSP clients (which is all this really is) should either cause the clients to fallback on CRLs or to fail the larger operation (TLS handshake, whatever) altogether. The latter makes this just a DoS. The former makes this less than a DoS. The real risk would be OCSP clients that don't bother with CRLs if OCSP Responder can't respond successfully, but which proceed anyways af if peers' certs are valid. If there exist such clients, don't blame OCSP. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Ben Laurie b...@links.org writes: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. This wouldn't make any difference, except for the special case of x64, signatures are only verified on install, so existing installed code isn't affected and anything new that's being installed is, with either form of sig-checking. In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. Previous experience with revoked certs has been that they remain valid more or less indefinitely (which would be really great if CAs offered something like domain-tasting for certs, you could get as many free certs as you wanted). The way to revoke a cert for signed malware is to wait 0-12 hours for the malware signature to be added to AV databases, not to actually expect PKI to work. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 00:14, Paul Tiemann wrote: On Jul 27, 2010, at 3:34 PM, Ben Laurie wrote: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. I like that idea, as long as a verifiable timestamp is included. Without a trusted timestamp, would the bad guy be able to backdate the signature? Note that I avoided this issue by using the date of receipt. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 09:57, Peter Gutmann wrote: Ben Laurie b...@links.org writes: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. This wouldn't make any difference, except for the special case of x64, signatures are only verified on install, so existing installed code isn't affected and anything new that's being installed is, with either form of sig-checking. Obviously if you are going to change revocation you can also change when signatures are checked. This hardly seems like a show-stopper. In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. Previous experience with revoked certs has been that they remain valid more or less indefinitely (which would be really great if CAs offered something like domain-tasting for certs, you could get as many free certs as you wanted). Again, citing the failure to use revocation correctly right now does not tell us anything much about the possibility of using it correctly in the future. The way to revoke a cert for signed malware is to wait 0-12 hours for the malware signature to be added to AV databases, not to actually expect PKI to work. At which time they release another version? Doesn't sound like the optimal answer to me. I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 27, 2010, at 5:34 PM, Ben Laurie wrote: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. There is, of course, the problem of knowing when a signature was stolen! You can know that it was definitely stolen *by* a particular date, but never that it wasn't stolen earlier. Given that it was stolen, what evidence could you produce that it wasn't stolen - and simply kept around for later use - at the moment it was created? Beyond that, you it's often hard to know when you received a file. Perhaps the actual attack was to stick it on your system and backdate it! A forensic examination could look at backups, but we're talking about how to decide whether to accept a signature in an operational setting. You can't, of course, rely on any dates within the file itself, as they are protected from fakery only by the signature that you can't trust. You could rely on a digital time-stamping service ... but that just brings into sharper focus the absurdity that actually began the moment you needed to check an on-line CRL. The only conceivable purpose for using a signature is that you can check it *offline*. If you assume you can connect to the network, and that you can trust what you get from the network - why bother with a signature? Simply check a cryptographic hash of the driver against an on-line database of known good drivers. This is right in line with Lynn Wheeler's frequent mention here that the use case for offline verification of certs for commerce basically doesn't exist. It was a nice theory to develop 30 years ago, but today the rest of the framework assumes connectivity, and you buy nothing but additional problems by focusing on making just one piece work off-line. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Ben Laurie b...@links.org writes: I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? It's not just that the world doesn't work that way now, it's quite likely that it'll never work that way (for the case of PKI/revocations mentioned in the message, not the original SNI). We've been waiting for between 20 and 30 years (depending on what you define as the start date) for PKI to start working, and your reponse seems to indicate that we should wait even harder. If I look at the mechanisms we've got now, I can identify that commercial PKI isn't helping, and revocations aren't helping, and work around that. I'm after effective practical solutions, not just a solution exists, QED solutions. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 13:18, Peter Gutmann wrote: Ben Laurie b...@links.org writes: I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? It's not just that the world doesn't work that way now, it's quite likely that it'll never work that way (for the case of PKI/revocations mentioned in the message, not the original SNI). We've been waiting for between 20 and 30 years (depending on what you define as the start date) for PKI to start working, and your reponse seems to indicate that we should wait even harder. If I look at the mechanisms we've got now, I can identify that commercial PKI isn't helping, and revocations aren't helping, and work around that. I'm after effective practical solutions, not just a solution exists, QED solutions. The core problem appears to be a lack of will to fix the problems, not a lack of feasible technical solutions. I don't know why it should help that we find different solutions for the world to ignore? -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 01:21:33PM +0100, Ben Laurie wrote: On 28/07/2010 13:18, Peter Gutmann wrote: Ben Laurie b...@links.org writes: I find your response strange. You ask how we might fix the problems, then you respond that since the world doesn't work that way right now, the fixes won't work. Is this just an exercise in one-upmanship? You know more ways the world is broken than I do? [...]. I'm after effective practical solutions, not just a solution exists, QED solutions. The core problem appears to be a lack of will to fix the problems, not a lack of feasible technical solutions. I don't know why it should help that we find different solutions for the world to ignore? Solutions at higher layers might have a better chance of getting deployed. No, I'm not suggesting that we replace TLS and HTTPS with application-layer crypto over HTTP, not entirely anyways. I am suggesting that we use what little TLS does give us in ways that don't require changing TLS much or at all. Application-layer authentication with tls-server-end-point channel bindings seems like a feasible candidate. This too would require changes on clients and servers, which makes it not-that-likely to get implemented and deployed, but not changes at the TLS layer (other than an API by which to extract a TLS connection's server cert). It could be deployed incrementally such that users who can use it get better security. Then if the market gives a damn about security, it might get closer to fully deployed in our lifetimes. The assumption here is that improvements at the TLS and PKI layers occur with enormous latency. If this were true at all layers then we could just give up, or aim to fix not just today's problems, but tomorrow's, a decade or three from now (ha). It'd be nice if that assumption were not true at all. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 28, 2010, at 8:21 33AM, Ben Laurie wrote:
On 28/07/2010 13:18, Peter Gutmann wrote:
Ben Laurie b...@links.org writes:
I find your response strange. You ask how we might fix the problems, then
you
respond that since the world doesn't work that way right now, the fixes
won't
work. Is this just an exercise in one-upmanship? You know more ways the
world
is broken than I do?
It's not just that the world doesn't work that way now, it's quite likely
that
it'll never work that way (for the case of PKI/revocations mentioned in the
message, not the original SNI). We've been waiting for between 20 and 30
years (depending on what you define as the start date) for PKI to start
working, and your reponse seems to indicate that we should wait even harder.
If I look at the mechanisms we've got now, I can identify that commercial
PKI
isn't helping, and revocations aren't helping, and work around that. I'm
after effective practical solutions, not just a solution exists, QED
solutions.
The core problem appears to be a lack of will to fix the problems, not a
lack of feasible technical solutions.
I don't know why it should help that we find different solutions for the
world to ignore?
There seem to be at least three different questions here: bad code (i.e., that
Windows doesn't check the revocation status properly), the UI issue, and the
conceptual question of what should replace the current PKI+{CRL,OCSP} model.
For the last issue, I'd note that using pki instead of PKI (i.e., many
different per-realm roots, authorization certificates rather than identity
certificates, etc.) doesn't help: Realtek et al. still have no better way or
better incentive to revoke their own widely-used keys.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 11:38:17 +0100 Ben Laurie b...@links.org wrote: On 28/07/2010 09:57, Peter Gutmann wrote: In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. Previous experience with revoked certs has been that they remain valid more or less indefinitely (which would be really great if CAs offered something like domain-tasting for certs, you could get as many free certs as you wanted). Again, citing the failure to use revocation correctly right now does not tell us anything much about the possibility of using it correctly in the future. The US Securities and Exchange Commission has long forced companies to state, when selling advisory services, that past performance is no indicator of future performance. However, I think that's pretty much clearly untrue in most disciplines. Empirical reasoning is entirely about observing and drawing conclusions based on what we observe. Virtually all of modern science comes, in fact, from observing what happens in the real world and extrapolating from it. After a few decades of trying to get PKI to work, we have failed to do so. At some point, one has to have very firm justifications for the belief that these decades of experience should be dismissed as mere experimental error. In another message you say: The core problem appears to be a lack of will to fix the problems, not a lack of feasible technical solutions. I'm unsure whether you are correct here, but I will point out that any solution which can never be deployed *is*, in fact, infeasible, and that if human beings cannot be convinced to use a particular solution (which is one form of the lack of will problem), then we might as well dismiss that solution. Now, I've been saying PKI can never be made to work for something like the last fifteen years. I was on a panel with Steve Kent at a Usenix workshop long ago, where I expressed the opinion that PKI very poorly models the actual legal and de facto relationships between parties, and I think that experience has borne that out. We've watched the rise and fall of substantial companies dedicated to trying to get PKI sold into enterprises, and the best efforts that Certco and Entrust and the like made were not enough. There is also considerable evidence that many of the technologies PKI requires, like reliable revocation, cannot be made to work, and whether that is because of a lack of will or because of something deeper, the fact is that these techniques have failed in practice over the course not of months or years but of decades, and we cannot ignore that forever. It is not always the case that a dead technology has failed because of infeasibility or inapplicability. I'd say that a number of fine technologies have failed for other reasons. However, at some point, it becomes incumbent upon the proponents of a failed technology to either demonstrate that it can be made to work in a clear and convincing way, or to abandon it even if, on some level, they are certain that it could be made to work if only someone would do it. I think we are at or even past that point with PKI. The odor of putrefaction is unmistakable. -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Peter, In any case though the whole thing is really a moot point given the sucking void that is revocation-handling, the Realtek certificate was revoked on the 16th but one of my spies has informed me that as of yesterday it was still regarded as valid by Windows. I can confirm that, at least for XP SP3: revocation just doesn't matter. What's even more worrying is the fact that one of the stuxnet/tmphider variants used the lnk exploit to install a dll signed w/ the (expired) Realtek key but w/ a *broken* signature in the first place. Still, it doesn't matter altough, as wireshark tells me, the host connects to microsoft.com in order to fetch certificates. When looking at the file properties, though, Windows tells you that this digital signature is not valid ... :-( Cheers, Stefan. -- Stefan Kelm sk...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstrasse 100 Tel: +49-721-96201-1 D-76133 Karlsruhe Fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Steven Bellovin s...@cs.columbia.edu writes: For the last issue, I'd note that using pki instead of PKI (i.e., many different per-realm roots, authorization certificates rather than identity certificates, etc.) doesn't help: Realtek et al. still have no better way or better incentive to revoke their own widely-used keys. I think the problems go a bit further than just Realtek's motivation, if you look at the way it's supposed to work in all the PKI textbooks it's: Time t: Malware appears signed with a stolen key. Shortly after t: Realtek requests that the issuing CA revoke the cert. Shortly after t': CA revokes the cert. Shortly after t'': Signature is no longer regarded as valid. What actually happened was: Time t: Malware appears signed with a stolen key. Shortly after t: Widespread (well, relatively) news coverage of the issue. Time t + 2-3 days: The issuing CA reads about the cert problem in the news. Time t + 4-5 days: The certificate is revoked by the CA. Time t + 2 weeks and counting: The certificate is regarded as still valid by the sig-checking software. That's pretty much what you'd expect if you're familiar with the realities of PKI, but definitely not PKI's finest hour. In addition you have: Time t - lots: Stuxnet malware appears (i.e. is noticed by people other than the victims) Shortly after t - lots: AV vendors add it to their AV databases and push out updates (I don't know what lots is here, it seems to be anything from weeks to months depending on which news reports you go with). So if I'm looking for a defence against signed malware, it's not going to be PKI. That was the point of my previous exchange with Ben, assume that PKI doesn't work and you won't be disappointed, and more importantly, you now have the freedom to design around it to try and find mechanisms that do work. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 14:05, Perry E. Metzger wrote: It is not always the case that a dead technology has failed because of infeasibility or inapplicability. I'd say that a number of fine technologies have failed for other reasons. However, at some point, it becomes incumbent upon the proponents of a failed technology to either demonstrate that it can be made to work in a clear and convincing way, or to abandon it even if, on some level, they are certain that it could be made to work if only someone would do it. To be clear, I am not a proponent of PKI as we know it, and certainly the current use of PKI to sign software has never delivered any actual value, and still wouldn't if revocation worked perfectly. However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. And still needs revocation. Is there a good replacement for pk for this purpose? -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie b...@links.org wrote: On 28/07/2010 14:05, Perry E. Metzger wrote: It is not always the case that a dead technology has failed because of infeasibility or inapplicability. I'd say that a number of fine technologies have failed for other reasons. However, at some point, it becomes incumbent upon the proponents of a failed technology to either demonstrate that it can be made to work in a clear and convincing way, or to abandon it even if, on some level, they are certain that it could be made to work if only someone would do it. To be clear, I am not a proponent of PKI as we know it, and certainly the current use of PKI to sign software has never delivered any actual value, and still wouldn't if revocation worked perfectly. However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. I agree with that fully. And still needs revocation. Does it? 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. Is there a good replacement for pk for this purpose? I think public key cryptography is a wonderful thing. I'm just not sure I believe at all in PKI -- that is, persistent certification via certificates, certificate revocation, etc. PKI was invented by Loren Kohnfelder for his bachelor's degree thesis at MIT. It was certainly a fine undergraduate paper, but I think we should forget about it, the way we forget about most undergraduate papers. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28 July 2010 15:05, Perry E. Metzger pe...@piermont.com wrote: On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie b...@links.org wrote: On 28/07/2010 14:05, Perry E. Metzger wrote: It is not always the case that a dead technology has failed because of infeasibility or inapplicability. I'd say that a number of fine technologies have failed for other reasons. However, at some point, it becomes incumbent upon the proponents of a failed technology to either demonstrate that it can be made to work in a clear and convincing way, or to abandon it even if, on some level, they are certain that it could be made to work if only someone would do it. To be clear, I am not a proponent of PKI as we know it, and certainly the current use of PKI to sign software has never delivered any actual value, and still wouldn't if revocation worked perfectly. However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. I agree with that fully. And still needs revocation. Does it? 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- The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 10:05:22AM -0400, Perry E. Metzger wrote: PKI was invented by Loren Kohnfelder for his bachelor's degree thesis at MIT. It was certainly a fine undergraduate paper, but I think we should forget about it, the way we forget about most undergraduate papers. PKI alone is certainly not the answer to all our problems. Infrastructure (whether of a pk variety or otherwise) and transitive trust probably have to be part of the answer for scalability reasons, even if transitive trust is a distasteful concept. However, we need to be able to build direct trust relationships, otherwise we'll just have a house of transitive trust cards. Again, think of the the SSH leap-of- faith and SSL pinning concepts, but don't constrain yourselves purely to pk technology. Nico -- - 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
Perry, I think public key cryptography is a wonderful thing. I'm just not sure I believe at all in PKI -- that is, persistent certification via certificates, certificate revocation, etc. I'm sure you remember Peter Honeyman's PK-no-I talk from the '99 USENIX Security Symposium? :-) Cheers, Stefan. -- Stefan Kelm sk...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstrasse 100 Tel: +49-721-96201-1 D-76133 Karlsruhe Fax: +49-721-96201-99 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 15:18, Peter Gutmann wrote: Ben Laurie b...@links.org writes: However, using private keys to prove that you are (probably) dealing with the same entity as yesterday seems like a useful thing to do. And still needs revocation. It depends on what you mean by revocation, traditional revocation in the PKI sense isn't needed because (well apart from the fact that it doesn't work, you can't un-say something after you've already said it) if you look at what a PK or a cert is, it's just a capability, and the way to revoke (in the capability sense) a capability is to do something like rename the object that the capability refers to or use a level of indirection and break the link when you want to revoke (in the capability sense) the access. This means that no matter how many copies of the capability are floating around out there and whether the relying party checks CRLs or not, they're not going to be able to get in. Now you are talking my language! Have I mentioned that my new project at Google is all about finding good UI for exposing capabilities to users? Is there a good replacement for pk for this purpose? Which purpose? If you mean securing the distribution channel for binaries, here's a very simple one that doesn't need PK at all, it's called a self-authenticating URL. To use it you go to your software site, and here's a real-world example that uses it, the Python Package Index, and click on a download link, something like http://pypi.python.org/packages/package.gz#md5= (yeah, I know, it uses MD5...). This link can point anywhere, because the trusted source of the link includes a hash of the binary (and in this case it's a non-HTTPS source, you can salt and pepper it as required, for exammple make it an HTTPS link and use key continuity to manage the cert). In this form the concept is called link fingerprints, it was actually implemented for Firefox as a Google Summer of Code project, but then removed again over concerns that if it was present people might actually use it (!!). It's still available in DL managers like DownThemAll. The problem here is that it doesn't directly give me an upgrade path. Of course, I agree that this is sufficient to give me a link to the right binary, but what about its successors? Another option is to cryptographically bind the key to the URL, so you again have a trusted link source for your download and the link is to https://base64.downloadsite.com, where base64 is a fingerprint of the cert you get when you connect to the site. This does away with the need for a CA, because the link itself authenticates the cert that's used. Yes, this is of course the YURL scheme. Then there are other variations, cryptographically generated addresses, ... all sorts of things have been proposed. The killer, again, is the refusal of any browser vendor to adopt any of it. In the case of FF someone actually wrote the code for them, and it was rejected. Without support from browser vendors, it doesn't matter what cool ideas people come up with, it's never going to get any better. Peter. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 08:48:14AM -0400, Steven Bellovin wrote:
There seem to be at least three different questions here: bad code
(i.e., that Windows doesn't check the revocation status properly),
the UI issue, and the conceptual question of what should replace the
current PKI+{CRL,OCSP} model. For the last issue, I'd note that
using pki instead of PKI (i.e., many different per-realm roots,
authorization certificates rather than identity certificates, etc.)
doesn't help: Realtek et al. still have no better way or better
incentive to revoke their own widely-used keys.
With a sufficiently fine grained authorization model inside the OS,
there is no reason in principle that something like attribute
certificates couldn't work - RealTek would have a code signing cert
only valid for drivers that talked to network cards with specific PCI
vendors IDs, and UI tools that talked to that driver - the signature
on the worm binary in question would be valid, but the worm would not
be given the permissions it wants to actually do its thing. (Eg, when
was the last time you had a network driver that needed to access an
MSSQL db). Windows is not that OS. (Neither is Linux or BSD of
course). It looks like Singularity has some features which could
support this sort of model [1].
This is not to suggest this is at all an easy course of action to
take; my point is just that it's possible to do much better here
without having to alter anyone's incentives: the CAs still collect
their rent, and RealTek's drivers still work. Fixing the OS is
probably easier than somehow fixing PKI to do what we'd nominally want
it to do here (though actually revoking the cert would have been a
good start) or modifying the obvious incentives.
-Jack
[1] http://research.microsoft.com/apps/pubs/default.aspx?id=59976
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 03:16:32PM +0100, Ben Laurie wrote: Maybe it doesn't, but no revocation mechanism at all makes me nervous. I don't know Kerberos well enough to comment. DNSSEC doesn't have revocation but replaces it with very short signature lifetimes (i.e. you don't revoke, you time out). Kerberos too lacks revocation, and it also makes up for it with short ticket lifetimes. OCSP Responses are much like a PKI equivalent of Kerberos tickets. All you need to do to revoke a principal with OCSP is to remove it from the Responder's database or mark it revoked. To revoke an individual certificate you need only mark a date for the given subject such that no cert issued prior to it will be considered valid. An OCSP Responder implementation could be based on checking a real CRL or checking a database of known subjects (principals). Whichever is likely to be smaller over time is best, though the latter is just simpler to administer (since you don't need to know the subject public key nor the issuerserial, nor the actual TBSCertificate in order to revoke, just the subject name and current date and time). SSH does appear to have got away without revocation, though the nature of the system is s.t. if I really wanted to revoke I could almost always contact the users and tell them in person. This doesn't scale very well to SSL-style systems. The SSH ad-hoc pubkey model is a public key pre-sharing (for user keys) and pre-sharing and/or leap-of-faith (for host keys) model. It doesn't scale without infrastructure. Add infrastructure and you're back to a PKI-like model (maybe with no hierarchy, but still). Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 15:16:32 +0100 Ben Laurie b...@google.com wrote: On 28 July 2010 15:05, Perry E. Metzger pe...@piermont.com wrote: On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie b...@links.org wrote: And still needs revocation. Does it? 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 Maybe it doesn't, but no revocation mechanism at all makes me nervous. I think that is because you are thinking in terms of certificates, which naturally would require such a mechanism. I don't know Kerberos well enough to comment. In kerberos, tickets are short lived -- one can simply fail to give the person who stole a credential new ones, and in the interim, one can remove the authorization that a particular principal has. DNSSEC doesn't have revocation but replaces it with very short signature lifetimes (i.e. you don't revoke, you time out). Yes. Precisely. SSH does appear to have got away without revocation, though the nature of the system is s.t. if I really wanted to revoke I could almost always contact the users and tell them in person. No, that's not what SSH does, or rather, it confuses the particular communications channel (i.e. some out of band mechanism) with the method that actually de-authorizes the key. The point is that in SSH, if a key is stolen, you remove it from the list of keys allowed to log in to a host. The key now need never be thought about again. We require no list of revoked keys be kept, just as we required no signed list of keys that were authorized. We just had some keys in a database to indicate that they were authorized, and we removed a key to de-authorize it. This doesn't scale very well to SSL-style systems. I believe it does scale. Pretty much by definition, if you can get to a web site, your Internet connectivity is working. That means that there is no need for methods like having a signed key that lasts for years so you can cache it for offline use. I'm sure you remember the 1960s and 1970s well, as we are both a bit past our youth. In the US, at least, every store clerk had in their hands an unwieldy, telephone-book sized list of stolen credit card numbers they had to consult at each credit card transaction. In those days, there were no cheap modems and doing on-line verification was impossible. The whole point of Kohnfelder's thesis was, in effect, to turn the 1970s era books of stolen numbers into an offline machine readable list. You signed a long-lived credential so that it could be checked offline, and you kept a big book of withdrawn credentials around so you could check them offline as well. It was a model from the era in which everyone had a paper phone book. It was designed for the era where networks were a rarity. We no longer live in that era. The models used by Kerberos, DNSSEC, SSH, and such, make far more sense. We no longer need revocation. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 10:42:43AM -0400, Anne Lynn Wheeler wrote:
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 ...
And PKINIT today also allows for rp-only user certs if you want them.
They must be certificates, but they needn't carry any useful data beyond
the subject public key, and the KDC must know the {principal,
cert|pubkey} associations.
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).
This is true time you have rp-only certs or certs that carry less
information than the rp will require. The latter almost always true.
The account can be local to each rp, however, or centralized -- that's
up to the relying parties.
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).
Agreed. Certificates should, as much as possible, be rp-only.
The account-based operations have sense of revocation by updating the
account-based records. [...]
Exactly. OCSP can work in that manner. CRLs cannot. In terms of
administration updating an account record is much simpler than updating
a CRL (because much less information needs to be available for the
former than for the latter).
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.
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? :)
Nico
--
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 28/07/2010 16:01, Perry E. Metzger wrote: On Wed, 28 Jul 2010 15:16:32 +0100 Ben Laurie b...@google.com wrote: SSH does appear to have got away without revocation, though the nature of the system is s.t. if I really wanted to revoke I could almost always contact the users and tell them in person. No, that's not what SSH does, or rather, it confuses the particular communications channel (i.e. some out of band mechanism) with the method that actually de-authorizes the key. The point is that in SSH, if a key is stolen, you remove it from the list of keys allowed to log in to a host. The key now need never be thought about again. We require no list of revoked keys be kept, just as we required no signed list of keys that were authorized. We just had some keys in a database to indicate that they were authorized, and we removed a key to de-authorize it. I am referring to the SSH host key. Fully agree for user keys. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 09:30:22 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 10:05:22AM -0400, Perry E. Metzger wrote: PKI was invented by Loren Kohnfelder for his bachelor's degree thesis at MIT. It was certainly a fine undergraduate paper, but I think we should forget about it, the way we forget about most undergraduate papers. PKI alone is certainly not the answer to all our problems. Infrastructure Let me interrupt here and say that when I refer to PKI, I mean the Kohnfelder model which we have been following, which is the model of very long lived phone books of hierarchically issued certificates along with very long lived lists of revoked certificates, all designed with an offline world in mind. I have no objections to infrastructure -- bridges, the Internet, and electrical transmission lines all seem like good ideas. However, lets avoid using the term Public Key Infrastructure for things that depart radically from the Kohnfelder and subsequent X.509 models. Infrastructure (whether of a pk variety or otherwise) and transitive trust probably have to be part of the answer for scalability reasons, even if transitive trust is a distasteful concept. Well, it depends a lot on what kind of trust. Let me remind everyone of one of my long-standing arguments. Say that Goldman Sachs wants to send Morgan Stanley an order for a billion dollars worth of bonds. Morgan Stanley wants to know that Goldman sent the order, because the consequences of a mistake on a transaction this large would be disastrous. Should they trust Verisign's ExtraSuperHighValue certificate presented by Goldman? No. Why? Because Verisign disclaims all effective liability for the use of its certs. It is not a party to the transaction being conducted. If it was actually insuring all transactions conducted with the certificate, then Morgan could trust them, because the counterparty who's credit would be at issue would no longer be Goldman but Verisign. However, Verisign won't even pay out if it turned out that they gave signed a Goldman cert and it was in fact held by a scammer. The problem with Certification Authorities is they certify NOTHING. There can be no reliance on them, because they have no liability of any sort in any transaction. So, in the real world, Goldman and Morgan come up with ways of making sure they trust each other's communications and credit lines. Even when we're dealing with small transactions, like buying a book at a book store with a credit card, if you trace it out, we're dealing with nothing but a web of bilateral commercial relationships. So, I have no trouble with various kinds of trust. What I have trouble with is the sort of false trust that a CA implies. CAs certify nothing in a real world business sense -- they are just toll collectors. However, we need to be able to build direct trust relationships, otherwise we'll just have a house of transitive trust cards. Again, think of the the SSH leap-of- faith and SSL pinning concepts, but don't constrain yourselves purely to pk technology. I believe we may, in fact, be in violent agreement here. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 11:13:36AM -0400, Perry E. Metzger wrote: On Wed, 28 Jul 2010 09:30:22 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: I have no objections to infrastructure -- bridges, the Internet, and electrical transmission lines all seem like good ideas. However, lets avoid using the term Public Key Infrastructure for things that depart radically from the Kohnfelder and subsequent X.509 models. Well, OK. But PKI no longer means that, not with bridges and what not in the picture. Infrastructure (whether of a pk variety or otherwise) and transitive trust probably have to be part of the answer for scalability reasons, even if transitive trust is a distasteful concept. Well, it depends a lot on what kind of trust. Let me remind everyone of one of my long-standing arguments. Say that Goldman Sachs wants to send Morgan Stanley an order for a billion dollars worth of bonds. Morgan Stanley wants to know that Goldman sent the order, because the consequences of a mistake on a transaction this large would be disastrous. Indeed. They must first establish a direct trust relationship. They might leverage transitive trust to bootstrap direct trust if doing so makes the process easier (which it almost certainly does, and which we use in the off-line world all the time using pieces of paper or plastic issued by various authorities, such as drivers' licenses, passports, ...). However, we need to be able to build direct trust relationships, otherwise we'll just have a house of transitive trust cards. Again, think of the the SSH leap-of- faith and SSL pinning concepts, but don't constrain yourselves purely to pk technology. I believe we may, in fact, be in violent agreement here. We are. Perhaps I hadn't made my point obvious enough: transitive trust is necessary, but primarily as a method of bootstrapping direct trust relationships. I really should have used that specific formulation. Nico -- - 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
Nicolas Williams nicolas.willi...@oracle.com writes: Exactly. OCSP can work in that manner. CRLs cannot. OCSP only appears to work in that manner. Since OCSP was designed to be 100% bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and not an OCSP. Specifically, if I submit a freshly-issued, valid certificate to an OCSP responder and ask is this a valid certificate then it can't say yes, and if I submit an Excel spreadsheet to an OCSP responder and ask is this a valid certificate then it can't say no. It takes quite some effort to design an online certificate status protocol that's that broken. (For people not familiar with OCSP, it can't say yes because a CRL can't say yes either, all it can say is not on the CRL, and it can't say no for the same reason, all it can say is not on the CRL. The ability to say vslid certificate or not valid certificate was explicitly excluded from OCSP because that's not how things are supposed to be done). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 10:50:52 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 11:38:28AM -0400, Perry E. Metzger wrote: On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: OCSP Responses are much like a PKI equivalent of Kerberos tickets. All you need to do to revoke a principal with OCSP is to remove it from the Responder's database or mark it revoked. Actually, that's untrue in one very important respect. In a Kerberos style system, you actively ask for credentials to do things at frequent intervals, and if the KDCs refuse to talk to you, you get no credentials. In OCSP, we've inverted that. You have the credentials, for years in most cases, and someone else has to actively check that they're okay -- and in most instances, if they fail to get through to an OCSP server, they will simply accept the credentials. No, they really are semantically equivalent. Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Peter Gutmann has pointed out other critical distinctions, but I'll let his message stand for itself. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
Nicolas Williams nicolas.willi...@oracle.com writes: Sorry, but this is wrong. The OCSP protocol itself really is an online certificate status protocol. It's not an online certificate status protocol because it can provide neither a yes or a no response to a query about the validity of a certificate. (For an online status protocol I want to be able to submit a cert and get back a straight valid/not valid response, exactly as I can for credit cards with their authorised/declined response. Banks were doing this twenty years ago with creaky mainframes over X.25 and (quite probably) wet bits of string, but we still can't do this today with multicore CPUs and gigabit links if we're using OCSP). Responder implementations may well be based on checking CRLs, but they aren't required to be. They may be, or they may not be, but you as a relying party have no way of telling. OCSP covers not only the three incompatible business models of the different authors' employers but, for good measure, an extra anything else you may care to do option if the first three aren't enough. A decade after it was published, PKI experts are still arguing over what various bits of the OCSP spec actually mean (the PKIX list has only just gone through yet another round of this... *ten years* later and domain experts still can't agree on how it's supposed to work). So given the schizophrenic nature of the RFC you can easily claim but you can do X because chances are if you read it just right you probably can. Unfortunately this doesn't give a relying party much to rely on, because they have absolutely no idea what they're getting, it could be anything from a live database query to a value from a month-old CRL to (thanks to the removal of nonces from the protocol a few years ago) an attacker replaying an old not-revoked value (although I don't know why they'd even bother with that, given the state of revocation checking in client software). In any event though since OCSP can't say yes or no, it doesn't matter whether the response is coming from a live database or a month-old CRL, since it's still a fully CRL-bug-compatible blacklist I can trivially avoid it with a manufactured-cert attack. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 11:23:16 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 11:20:51AM -0500, Nicolas Williams wrote: On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote: Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Whether PKI can run w/o OCSP is up to the relying parties. Today, because OCSP is an afterthought, they have little choice. Also, requiring OCSP will probably take less effort than switching from PKI to Kerberos. In other words: eveything sucks. I wouldn't suggest that everything on earth move to Kerberos. I mentioned Kerberos only to show that entirely different models are possible. As to OCSP being a reasonable solution because it can be deployed easily, it clearly will not solve the browser security problem. So long as security depends on reliance on the lowest common denominator among the policies of hundreds of CAs, many of which are quite questionable, and so long as the certifications made by even the best of those CAs are effectively meaningless, and so long as the users are well trained to ignore every browser warning they ever get, the entire question of OCSP is somewhat irrelevant -- it would just be a way of spritzing the skunk with eau de cologne. I fully recognize that the odds we will fix the browser security problem are very low, if only because no one can deploy a truly new solution in a world where we can't even get IE 6 to die. However, in discussing this at a high level, as though we could improve things, we shouldn't kid ourselves about the current model. It is fatally broken. Hanging garlands from the corpse's ears will not convince anyone that it has a vibrant future ahead. Perry -- Perry E. Metzgerpe...@piermont.com - 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, Part II
On Thu, Jul 29, 2010 at 04:23:52AM +1200, Peter Gutmann wrote:
Nicolas Williams nicolas.willi...@oracle.com writes:
Sorry, but this is wrong. The OCSP protocol itself really is an online
certificate status protocol.
It's not an online certificate status protocol because it can provide neither
a yes or a no response to a query about the validity of a certificate.
You should be more specific. I'm looking at RFC2560 and I don't see
this.
OCSP Responses allow the Responder to assert:
- A time at which the given cert was known to be valid (thisUpdate;
REQUIRED).
Relying parties are free to impose a freshness requirement (e.g.,
thisUpdate must be no more than 5 minutes in the past).
Perhaps you're concerned that protocols that allow for carrying OCSP
Responses don't provide a way for peers to indicate what their
freshness requirements are?
- A time after which the given OCSP Response is not to be considered
valid (nextUpdate, which is OPTIONAL).
- The certificate's status (certStatus, one of good, revoked, unknown;
REQUIRED).
How is responding certStatus=good, thisUpdate=now - a few minutes
not a yes response to a query about the validity of a certificate?
What am I missing?
(For an online status protocol I want to be able to submit a cert and get back
a straight valid/not valid response, exactly as I can for credit cards with
their authorised/declined response. Banks were doing this twenty years ago
with creaky mainframes over X.25 and (quite probably) wet bits of string, but
we still can't do this today with multicore CPUs and gigabit links if we're
using OCSP).
OCSP gives you that. Seriously. In fact, an OCSP Responder either must
not respond or it must give you at least {certStatus, thisUpdate}
information about a cert. Yes, certStatus can be unknown, but a
Responder that regularly asserts certStatus=unknown would be a rather
useless responder.
Responder implementations may well be based on checking CRLs, but they aren't
required to be.
They may be, or they may not be, but you as a relying party have no way of
telling.
And why would a relying party need to know internal details of the OCSP
Responder?
In any event though since OCSP can't say yes or no, it doesn't matter whether
the response is coming from a live database or a month-old CRL, since it's
still a fully CRL-bug-compatible blacklist I can trivially avoid it with a
manufactured-cert attack.
Manufactured cert attack? If you can mint certs without having the CA's
private key then who cares about OCSP. If you can do it only as a
result of hash collisions, well, switch hashes. Let's not confuse hash
collision issues with whether OCSP does what it's advertised to do.
Nico
--
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote: Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Whether PKI can run w/o OCSP is up to the relying parties. Today, because OCSP is an afterthought, they have little choice. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 11:20:52 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote: Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Whether PKI can run w/o OCSP is up to the relying parties. Today, because OCSP is an afterthought, they have little choice. My mother relies on many certificates. Can she make a decision on whether or not her browser uses OCSP for all its transactions? I mention this only because your language here is quite sticky. Saying it is up to the relying parties is incorrect. It is really up to a host of people who are nowhere near the relying parties. In most cases, the relying parties aren't even capable of understanding the issue. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 01:25:21PM -0400, Perry E. Metzger wrote: My mother relies on many certificates. Can she make a decision on whether or not her browser uses OCSP for all its transactions? I mention this only because your language here is quite sticky. Saying it is up to the relying parties is incorrect. It is really up to a host of people who are nowhere near the relying parties. In most cases, the relying parties aren't even capable of understanding the issue. Precise and concise language in a fast moving thread with participants with diverse backgrounds is going to be hard to come by. Better to quit than hold out for that (unless you enjoy being disappointed). I'm hardly the only sinner here on that score. up to the relying parties means up to the browsers, where users-as- relying-parties are concerned. That also means getting software updated, which to some degree means getting my mom to do stuff she doesn't and shouldn't have to know how. It shouldn't mean getting my mom to enable OCSP -- that would be hopeless. up to the relying parties means up to the server as well, since servers too are relying-parties. Again, if everything is too hard, why do we bother even talking about any of this? ETOOHARD cannot usefully be a retort to every suggestion. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 12:38:10 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: Again, if everything is too hard, why do we bother even talking about any of this? ETOOHARD cannot usefully be a retort to every suggestion. Well, not everything is too hard. In fact, one of the important characteristics of systems that work is that they're simple, and thus tractable. We were just discussing the problem of needing users to make fine grained security decisions. Several obvious solutions exist here. For example, the there should be one mode, and it should be secure rule lowers the complexity users encounter quite a bit. I know of at least one project to fix the browser PKI mess which claims that they want to involve the users more, not less. This would seem to be a big mistake to me. On the other edge of the spectrum, many people now use quite secure protocols (though I won't claim the full systems are secure -- implementation bugs are ubiquitous) for handling things like remote login and file transfer, accessing shared file systems on networks, etc., with little to no knowledge on their part about how their systems work or are configured. This seems like a very good thing. One may complain about many issues in Microsoft's systems, for example, but adopting Kerberos largely fixed the distributed authentication problem for them, and without requiring that users know what they're doing. Yet another reason (one of dozens) that X.509 has never worked right for most users is the sheer number of knobs. There are too many choices for mortals, and there will always be subtle configuration failures that can catch even experts. (I am reminded of the similar death-by-complexity of the IPSec protocol's key management layers, where I am sad to report that even I can't easily configure the thing. Some have proposed standardizing on radically simplified profiles of the protocol that provide almost no options -- I believe to be the last hope for the current IPSec suite.) Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 02:41:35PM -0400, Perry E. Metzger wrote: On the other edge of the spectrum, many people now use quite secure protocols (though I won't claim the full systems are secure -- implementation bugs are ubiquitous) for handling things like remote login and file transfer, accessing shared file systems on networks, etc., with little to no knowledge on their part about how their systems work or are configured. This seems like a very good thing. One may complain about many issues in Microsoft's systems, for example, but adopting Kerberos largely fixed the distributed authentication problem for them, and without requiring that users know what they're doing. Hear, hear! But... great for corporate networks, not quite for Internet-scale, but a great example of how we can make progress when we want to. (I am reminded of the similar death-by-complexity of the IPSec protocol's key management layers, where I am sad to report that even I can't easily configure the thing. Some have proposed standardizing on radically simplified profiles of the protocol that provide almost no options -- I believe to be the last hope for the current IPSec suite.) IPsec is a great example of another kind of failure: lack of APIs. Applying protection to individual packets without regard to larger context is not terribly useful. Apps have no idea what's going on, if anything, in terms of IPsec protection. Worse, the way in which IPsec access control is handled means that typically many nodes can claim any given IP address, which dilutes the protection provided by IPsec as the number of such nodes goes up. Just having a way to ask that a TCP connection's packets all be protected by IPsec, end-to-end, with similar SA pairs (i.e., with same peers, same transforms) would have been a great API to have years ago. The lack of APIs has effectively relegated IPsec to the world of VPN. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, Jul 28, 2010 at 5:51 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Nicolas Williams nicolas.willi...@oracle.com writes: Exactly. OCSP can work in that manner. CRLs cannot. OCSP only appears to work in that manner. Since OCSP was designed to be 100% bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and not an OCSP. Specifically, if I submit a freshly-issued, valid certificate to an OCSP responder and ask is this a valid certificate then it can't say yes, and if I submit an Excel spreadsheet to an OCSP responder and ask is this a valid certificate then it can't say no. It takes quite some effort to design an online certificate status protocol that's that broken. OCSP is even better for an attacker. As the OCSP responses are unauthenticated[1], you can be easily fake the response with what ever the attacker likes. http://www.thoughtcrime.org/papers/ocsp-attack.pdf [1] Would be silly to run OCSP over SSL ;-) -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- Knowledge can create problems, it is not through ignorance -- that we can solve them Isaac Asimov - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 28, 2010, at 9:51 AM, Peter Gutmann wrote: Nicolas Williams nicolas.willi...@oracle.com writes: Exactly. OCSP can work in that manner. CRLs cannot. OCSP only appears to work in that manner. Since OCSP was designed to be 100% bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and not an OCSP. This isn't true for all OCSP services. For example, DigiCert's is not CRL based, so it really can say Yes and it really can say Unknown meaningfully. (For people not familiar with OCSP, it can't say yes because a CRL can't say yes either, all it can say is not on the CRL, and it can't say no for the same reason, all it can say is not on the CRL. The ability to say vslid certificate or not valid certificate was explicitly excluded from OCSP because that's not how things are supposed to be done). True for off-the-shelf OCSP responders that base themselves on CRL. Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Wed, 28 Jul 2010 14:40:14 -0600 Paul Tiemann paul.tiemann.use...@gmail.com wrote: On Jul 28, 2010, at 11:25 AM, Perry E. Metzger wrote: On Wed, 28 Jul 2010 11:20:52 -0500 Nicolas Williams nicolas.willi...@oracle.com wrote: On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote: Again, I understand that in a technological sense, in an ideal world, they would be equivalent. However, the big difference, again, is that you can't run Kerberos with no KDC, but you can run a PKI without an OCSP server. The KDC is impossible to leave out of the system. That is a really nice technological feature. Whether PKI can run w/o OCSP is up to the relying parties. Today, because OCSP is an afterthought, they have little choice. My mother relies on many certificates. Can she make a decision on whether or not her browser uses OCSP for all its transactions? That might depend. I tell Firefox to use OCSP if a responder is referenced in the certificate, and I check that little checkbox that says When an OCSP connection fails, treat the certificate as invalid. I believe you've missed an important point. First, my mother would never understand what that box means. Second, my mother has no control over whether the CA provides OCSP. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: A mighty fortress is our PKI, Part II
On Jul 27, 2010, at 3:34 PM, Ben Laurie wrote: On 24/07/2010 18:55, Peter Gutmann wrote: - PKI dogma doesn't even consider availability issues but expects the straightforward execution of the condition problem - revoke cert. For a situation like this, particularly if the cert was used to sign 64-bit drivers, I wouldn't have revoked because the global damage caused by that is potentially much larger than the relatively small-scale damage caused by the malware. So alongside too big to fail we now have too widely-used to revoke. Is anyone running x64 Windows with revocation checking enabled and drivers signed by the Realtek or JMicron certs? One way to mitigate this would be to revoke a cert on a date, and only reject signatures on files you received after that date. I like that idea, as long as a verifiable timestamp is included. Without a trusted timestamp, would the bad guy be able to backdate the signature? Paul Tiemann (DigiCert) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
A mighty fortress is our PKI, Part II
Have you ever wondered what would happen if malware started appearing that was authenticated by signing keys belonging to major hardware or software vendors? Over the last week or two we've had a chance to find out: One of the scariest scenarios for code signing is when the malware authors manage to get their hands on a legitimate developer's code-signing key. Since many development shops see the signing process as nothing more than an annoying speedbump that stands in the way of application deployment, not helped by the fact that code-signing tools like Windows SignTool and Unix' GPG are hard to use and poorly integrated into the development process, developers have generally used the most expedient means possible to sign their code, with signing keys left unprotected or with easy-to-guess passwords (password is a favourite in web advice columns that give examples of how to do code signing), or passwords hard-coded into the scripts that are needed in order to integrate the signing into the build process. Combine this with the existence of entire families of malware such as Adrenalin, Nuklus/Apophis, Ursnif, and Zeus, with key-stealing functionality and it's inevitable that legitimate code-signing keys will end up in the hands of malware authors. The most serious case of this occurred in mid-2010 when malware signed with a key belonging to the major semiconductor manufacturer Realtek started to appear [Rootkit.TmpHider, discussion thread, 12 July 2010, http://www.wilderssecurity.com/showthread.php?p=1712134.][Signed Malware Used Valid Realtek Certificate, Lucian Constantin, 16 July 2010, http://news.softpedia.com/news/Signed-Malware-Used-Valid-Realtek- Certificate-147942.shtml.]. Although PKI dogma states that a certificate belonging to such a key should be immediately revoked, the fact that vast numbers of Realtek drivers had already been signed by it and could now no longer be installed without unsigned-driver warnings or, in the case of 64-bit Windows, used at all, would no doubt have given both Realtek and the issuing CA cause for concern. After several days the certificate was revoked [VeriSign working to mitigate Stuxnet digital signature theft, Steve Ragan, 21 July 2010, http://www.thetechherald.com/article.php/201029/5921/VeriSign-working-to- mitigate-Stuxnet-digital-signature-theft.], although the CA had to wait until the story started to appear in news reports before they became aware of the need for the revocation. The decision to revoke the certificate was probably influenced by a combination of the fact that the majority of users will simply click through a driver install warning and that the hit-and-miss nature of revocation checking meant that many systems would keep on using the certificate regardless (if the certificate had only been used to sign 32-bit code so that the worst that could happen was a warning dialog on install for users to click past then this would have made the decision to revoke even easier). In any case since antivirus vendors had added the malware signature to their scanners as soon as it was discovered, the revocation likely had little actual effect in protecting users from harm. A few days later a new version of the malware appeared, this time signed with a key from another semiconductor manufacturer, JMicron [Win32/Stuxnet Signed Binaries, Pierre-Marc Bureau, 19 July 2010, http://blog.eset.com/2010/07/19/win32stuxnet-signed-binaries.][Another Signed Stuxnet Binary, Sean Sullivan, 20 July 2010, http://www.f-secure.com/weblog/archives/1993.html.][New Stuxnet-Related Malware Signed Using Certificate from JMicron, Lucian Constantin, 20 July 2010, http://news.softpedia.com/news/New-Stuxnet-Related-Malware-Signed-Using- Certificate-from-JMicron-148213.shtml.]. Making the debacle even more entertaining was the fact that one of the principal systems targeted by the malware is a Siemens SCADA (industrial control) system that uses a hardcoded password 2WSXcder that can't be changed because doing so causes the system to stop working [Siemens warns users: Don't change passwords after worm attack, Robert McMillan, 20 July 2010, http://www.infoworld.com/d/security-central/siemens-warns-users-dont-change- passwords-after-worm-attack-915.] and that had been circulating on the Internet for years, including being posted to a Siemens online forum in Russia [SCADA System.s Hard-Coded Password Circulated Online for Years, Kim Zetter, 19 July 2010, http://www.wired.com/threatlevel/2010/07/siemens-scada/.] and online lists of default passwords [default password list, http://www.defaultpassword.com/?action=dplchar=s.] (the reason for this poor level of security is that SCADA systems rate availability above everything else, so that anything that affects, or potentially affects, security is strongly avoided. In addition SCADA systems often use thoroughly out-of-date hardware and software that no-one wants to change for fear of breaking things and for which there's no way to
