Re: Free Rootkit with Every New Intel Machine
[EMAIL PROTECTED] writes: my understanding from a person active in the NEA working group (IETF) is that TPMs these days come along for free because they're included on-die in at least one of said chips. Check again. A few months ago I was chatting with someone who works for a large US computer hardware distributor and he located one single motherboard (an Intel one, based on an old, possibly discontinued chipset) in their entire inventory that contained a TPM (they also had all the ex-IBM/Lenovo laptops, and a handful of HP laptops, that were reported as having TPMs). He also said that there were a handful of others (e.g. a few Dell laptops, which they don't carry) with TPMs. I've seen all sorts of *claims* of TPM support, but try going out and buying a PC with one (aside from IBM/Lenovo and the handful of others) - you have to look really, *really* hard to find anything, and if you do decide you specifically want a TPM-enabled MB or laptop you're severely restricting your options (unless it's a Lenovo). Unless something truly miraculous happens, TPMs are destined to end their lives as optional theft-discouragement gadgets for laptops (assuming they're running Windows XP, or possibly Vista if you can find the drivers). They've certainly failed to make any impression on the desktop market. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
Actually I worked on a project recently that had this scenario. Paramedic team picks up heart attack/stroke/serious accident patient. The paramedic tending the patient is using a laptop to record EKG or other electronic medical process. Even with the siren on they get in a serious accident that puts the paramedic in a coma due to a concussion. The laptop with the data is broken. At the hospital they yank the hard drive and using an adapter cable mount it on another computer. However, since medical data is considered personal and private data the hard drive is encrypted. The patient, especially if a stroke victim, needs to have his condition understood immediately. Yes, they can do the same tests again, but that does not give them a baseline to compare to: Is the patient getting worse, staying the same, or maybe even improving? With a stroke victim there is a very short window for doing some types of treatment. How do you recover the data? Two solutions were considered, one was secret sharing and the other was StrongAuth's commercial version of the open source StrongKey. The StrongAuth approach was better than the secret sharing but both were way ahead of the next possible choice. The primary reason that the StrongAuth approach would work better is that the medical data would be stored an a folder/partition that every person with the same level of access rights or higher could access the data with their own authentication via a stored certificate. This would mean there would be many people's certificate stored on the drive, but being relatively small this would not pose a problem. The secret sharing was next best because anyone at the hospital could call a central paging system that would page all security people with the number to login to. If enough shares were created - we were thinking 99+ for a major medical system - then the minimum needed - we were thinking three - to recover the key would be available 24/7/366 to generate the needed key to allow access. Both would work, but in this scenario, the local certificate would be faster by several minutes. If StrongAuth did not exist, then the secret sharing approach would be the only approach that could be made to work fast enough. Granted this seems like a corner case, but, trust me, this scenario happens several times a year in the USA. What with medical diagnosis and treatment being pushed closer to the scene of the emergency this is likely to become more common. Except for time critical events, secret sharing is the easiest to deploy and use in a robust way but there are very few, none that I could find, implementations of it that would have enough shares to cover vacations, out of range, and other vagaries of human existence. BTW, on the net is a demo of secret sharing: http://point-at-infinity.org//demo.html Allen Peter Gutmann wrote: Charles Jackson [EMAIL PROTECTED] writes: Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? It's available as part of other products (e.g. nCipher do it for keying their HSMs), but I don't know of any product that just does... secret sharing. What would be the user interface for such an application? What would be the target audience? (I mean a real target audience, not some hypothesised scenario). (This is actually a serious question. I talked with some crypto guys a few years ago about doing a standard for secret sharing, but to do that we had to come up with some general usage model for it rather than just one particular application-specific solution, and couldn't). Besides that, user demand for it was practically nonexistent... no, it was completely nonexistent, apart from a few highly specialised custom uses we couldn't even find someone to use as a guinea pig for testing, and the existing specialised users already had specialised solutions of their own for handling it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: question re practical use of secret sharing
James A. Donald: Is anyone aware of a commercial product that implements secret sharing? If so, can I get a pointer to some product literature? Peter Gutmann It's available as part of other products (e.g. nCipher do it for keying their HSMs), but I don't know of any product that just does... secret sharing. What would be the user interface for such an application? What would be the target audience? (I mean a real target audience, not some hypothesised scenario). (This is actually a serious question. I talked with some crypto guys a few years ago about doing a standard for secret sharing, but to do that we had to come up with some general usage model for it rather than just one particular application-specific solution, and couldn't). Besides that, user demand for it was practically nonexistent... no, it was completely nonexistent, apart from a few highly specialised custom uses we couldn't even find someone to use as a guinea pig for testing, and the existing specialised users already had specialised solutions of their own for handling it. There is no market, zero, for stand alone crypto of any kind. Cryptographic solutions should be embedded invisibly in products that do tasks for the user. The purpose of cryptography is to stop such products from invisibly doing tasks for an adversary. Since the attack is generally invisible, one cannot expect the user to use a visible addon product to protect against the attack. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A secure Internet requires a secure network protocol
Lynne or Anne, At 10:30 AM 6/22/2007 -0600, Anne Lynn Wheeler wrote: A secure Internet requires a secure network protocol http://www.infoworld.com/article/07/06/22/25OPsecadvise_1.html Actually I think we need a shadow Internet that is used only for security purposes (and is fully encrypted). It is sort of like the old SS7 signaling infrastructure of the phone network. It doesn't need the same bandwidth, maybe 1/1000 or 1/10,000 as much. It would use strictly cryptographic protocols for identity authentication and key management, etc.. one of the things seen in various of the SSL (authentication) vulnerabilities SSL seems to be hanging by a thread, mainly the name to public key mapping depends on how thorough the checking is done in to SSL vs application layers inside of the web browser. If this is hosed then unrestricted MITM is in the cards sometime in the near future. - Alex -- Alex Alten [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Quantum Cryptography
On Jun 22, 2007, at 10:44 AM, Ali, Saqib wrote: ...whereas the key distribution systems we have aren't affected by eavesdropping unless the attacker has the ability to perform 2^128 or more operations, which he doesn't. Paul: Here you are assuming that key exchange has already taken place. But key exchange is the toughest part. That is where Quantum Key Distribution QKD comes in the picture. Once the keys are exchanged using QKD, you have to rely on conventional cryptography to do bulk encryption using symmetric crypto. Using Quantum Crypto to do bulk encryption doesn't make any sense. It is only useful in key distribution. Let me create an aphorism to sum up what Paul, Perry, and others have said in detail before I address your comment: If Quantum Cryptography does what is claims, then it is strengthening the strongest link in the chain of security. Now to your comment. If you do a 3000 bit Diffie-Hellman exchange, you have a key exchange with 2^128 security, to the best of our knowledge, assuming this and that, blah, blah, blah. If you don't like 3000 bit integers, go to elliptic curve. I have in some of my talks, renamed Quantum Cryptography to Quantum Secrecy. If the QC people would stop calling it cryptography, a good deal of the hostility you find among us crypto people would evaporate. Let me give an analogy. I will posit Quantum Message Teleportation. Using QMT, Alice can write her message on a piece of paper, close her eyes, and it will disappear from her hand and appear in Bob's hand. This is cool. This is useful. It is amazing. It is also not cryptography. It also has all the problems that Perry points out in QC, like a lack of authentication and so on. Like QC, adding cryptography to it makes it even more useful. The QC people should change their song to QS, and stop bashing the mathematicians with arguments we can show are somewhere between incomplete and fallacious. Then they might find us drift over to supporting them because while Quantum Secrecy is not practical, it is very cool. Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Blackberries insecure?
[Perry -- I have no connection to Nokia whatsoever and am thrilled with the phone in question, but the message below sounds like an advertisement so please reject from the list if inappropriate.] [Moderator's note: this is off topic, but there were a couple of what is that phone messages to the list so clearly enough readers want to know where to get a phone that runs real ssl and ssh. No followups, please -- the list has been off topic enough lately already. --Perry] James A. Donald wrote: What is your phone's model number? Nokia E61i, an update of the E61: http://europe.nokia.com/A4344018 http://www.nokiausa.com/phones/E61i It's not available directly from service providers in the states who only sell the E62, which is a crippled E61. It has wifi, Bluetooth, takes additional microSD storage, exposes its drive (and SD card) as a standard USB hard drive, has a decent music player and built-in zooming web browser, runs Acrobat reader and Opera, can sync with Google calendar with a third party program, runs putty as an ssh client, supports viewing Office documents and has all the other features you'd expect from a business phone (e.g. timed profiles and phone ACLs -- instead of turning off or muting your phone at night, you can, for instance, specify that only certain people can call you.) -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why self describing data formats:
James A. Donald: In the case of XML, yes there is a parsing engine, and if the structure of the DTD reflects the structure of the algorithm, then indeed it makes things much easier. But usually the committee have not thought about the algorithm, or have unresolved disagreements about what the algorithm should be, leaving the engineer with problems that are at best extremely difficult to solve, and are at worst impossible to solve. Ideally the DTD should be developed in parallel with the program that processes the XML. In that case, you get the parsing engine doing a lot of work for free, so the engineers do not have to reinvent the wheel. But if the DTD is written first by one group, and the program second, by another group, the second group is usually hosed good. Will Morton: The situation is improved slightly with XML schemas, as one can use frameworks like XMLBeans (http://xmlbeans.apache.org/) to get the protocol much closer to the code. This can help a bit, but doesn't change the fundamentals. You're still right in that if you have one group developing the code and another the protocol, you're probably screwed, but isn't this just as true (perhaps moreso) if you're rolling your own protocol structure instead of using XML? With XML, alarmingly great flexibility in the protocol is easy and less work for the people designing the protocol - the protocol may be inordinately flexible because of laziness, carelessness, unresolved disagreement, or papered over disagreement, resulting in tag soup. With a protocol that is not self describing, the committee devising the protocol have to actually agree on what the protocol actually is. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A secure Internet requires a secure network protocol
Alex Alten wrote: SSL seems to be hanging by a thread, mainly the name to public key mapping depends on how thorough the checking is done in to SSL vs application layers inside of the web browser. If this is hosed then unrestricted MITM is in the cards sometime in the near future. re: http://www.garlic.com/~lynn/aadsm27.htm#29 A secure Internet requires a secure network protocol i.e. we were called in to consult with this small client/server startup that wanted to do payments on their server. they had this technology they called SSL ... and we had to end-to-end process audits ... including walk-thru of some of these new business entities that were calling themselves certification authorities. http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 the fundamental SSL design point was that the user knows the relationship between a website and a URL, the user entered that URL, and SSL would authenticate that the website that the user *thot* they were talking to (from entering the URL), was in fact, the website they were actually talking to. these days, most users have no cognition about relationship between websites and URLs, they click on something in email and/or webpages. In this scenario, the attacker is providing the URL and then the only thing that SSL is providing is authenticating who the attacker is claiming to be (via the URL that the attacker provides). the original SSL design point had implicit assumptions that users knew the relationship between the website they thot they were talking to and URLs (and then SSL authenticated the relationship between those known URLs and the website). For the most part those assumptions are no longer valid ... which then breaks the security model and all bets are off. With the potential attacker frequently providing both the URL and the website, then the only thing SSL is providing is authenticating the website that the attacker claims to be (via the URL) is the website that they are (breaking original basic assumption about SSL). This totally invalidates the assumption that SSL is proving that the website that the user *thot* they were talking to (via directly entering the URL) was, in fact, the website that they were talking to (aka the user has no idea what website they are talking to ... because they no longer have the knowledge about the relationship between websites they think they are talking to and the URLs for those websites). The (*URL*) name to key mapping isn't the problem ... that is the mechanics that SSL provided. The problem was that SSL security had implicit assumption that the user knew the mapping between the website they think they talk to and the URL for that website. In the current environment, that assumption is no longer valid, So the basic, most common PKI infrastructures provide a trusted public key repository (typically manufactured into browsers before they ship). Users are indoctrinated that they can trust those public keys ... for the purposes of digitally signing digital certificates. These digital certificates provide the binding between URL (actually the domain names part of URL) and website public keys. It is imperative that the user (knowledge) then provide the binding the website they think they are talking to and the URL. That is the part that is missing in today's environment (and what large numbers of attackers can leverage to slip thru the cracks). The missing piece is trusted binding between who the user's think they are talking to and the URL (or at least domain name). This could be accomplished by a separate trusted repository ... names that the end-user relates to and trusted binding between those names and URLs. Attacker provided URLs that are clicked on ... then can be cross-checked with things in that new trusted table (analogous to the way that the browser table of certification authority public keys are trusted). Then the issue is that if there is a trusted table mapping names to URLs (or at least domain names) ... and a separate table of trusted public keys ... the whole thing could be collapsed into a single table ... totally eliminating the level of indirection provided by (redundant and superfluous) PKI and certification authorities ... just add the public key to the trusted table of names domain names (aka URLs). The issue isn't so much that SSL is broken ... it is the implicit dependency on users knowing the relationship between the website they think they were talking to and the URL for those websites. Creating a user trusted table of website/urls (analogous to the browser trusted table of certification authority public keys), can make PKIs and certification authorities redundant and superfluous ... since in whatever trusted process is used to maintain the trusted table of website/urls ... can also directly include the public key for those website/urls. this is similar, but different to some of the domain name
Re: Why self describing data formats:
On Mon, Jun 11, 2007 at 11:28:37AM -0400, Richard Salz wrote: Many protocols use some form of self describing data format, for example ASN.1, XML, S expressions, and bencoding. I'm not sure what you're getting at. All XML and S expressions really get you is that you know how to skip past something you don't understand. This is also true for many (XER, DER, BER) but not all (PER) encodings for ASN.1. If only it were so easy. As we discovered in the IETF KRB WG you can't expect that just because the protocol uses a TLV encoding (DER) you can just add items to sequences (structures) or choices (discriminated unions) willy nilly: code generated by a compiler might choke because formally the protocol didn't allow extensibility and the compiler did the Right Thing. Extensibility of this sort requires that one be explicit about it in the original spec. Are you saying why publish a schema? I doubt it: you can have schemas without self-describing encodings (again, PER, XDR, are examples of non-self-describing encodings for ASN.1 and XDR, respectively). Schemas can be good while self-describing encodings can be bad... Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Free Rootkit with Every New Intel Machine
Peter Gutmann wrote: I've seen all sorts of *claims* of TPM support, but try going out and buying a PC with one Of the 25 business laptop models that HP offers on its site right now, only 5 don't have a TPM installed. -- Ivan Krstić [EMAIL PROTECTED] | GPG: 0x147C722D - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
