Identity Based Encryption
Hello, I have had a look at Identity Based Encryption but I have not been able to find out whether there are any protecting patents. It appears that the breakthrough happend just two years ago with the work of Beneh and Franklin [1] and there exist an open source implementation of their scheme (no GPL though) from the same Applied Crypto Group at Stanford http://crypto.stanford.edu/ibe/ Not sure whether the Voltage Security software, which was discussed on this list back in July, is actually based on this very same implementation (I think it is the same people). Does anybody know more about how free it is to develop another IBE implementation? I know that HP also have their own implementation of IBE, which is also not freely available. And there is another IBE schema developed by Cocks [2] of which I haven't come across any implementation yet Ciao Al [1] SIAM J. of Computing, Vol. 32, No. 3, pp. 586-615, 2003. Extended abstract in proceedings of Crypto '2001, Lecture Notes in Computer Science, Vol. 2139, Springer-Verlag, pp. 213-229, 2001. [2] C. Cocks, An identity based encryption scheme based on quadratic residues, Eighth IMA International Conference on Cryptography and Coding, Dec. 2001, Royal Agricultural College, Cirencester, UK. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
On Sun, Dec 21, 2003 at 08:55:16PM -0800, Carl Ellison wrote: IBM has started rolling out machines that have a TPM installed. [snip ...] Then again, TPMs cost money and I don't know any private individuals who are willing to pay extra for a machine with one. Given that, it is unlikely that TPMs will actually become a popular feature. Personally, I own a laptop (T30) with the TPM chip, and I paid extra for the chip, but that is because I am a researcher interested in seeing what I can get the chip to do. I think that it is possible that they will sell a lot of TPM chips. IBM is currently calling it the IBM Security Subsystem 2.0 or something like that, which sounds a lot less threatening and more useful than trusted platform module. It depends a lot on the marketing strategy. If they can make it sound useful, that will take them far. Some TPM-machines will be owned by people who decide to do what I suggested: install a personal firewall that prevents remote attestation. With wider dissemination of your reasoning, that number might be higher than it would be otherwise. Agreed. The first thing I did when writing code was to figure out how to turn it off. THen I figured out how to enable most of the functionality while disabling the built-in attestation key. Meanwhile, there will be hackers who accept the challenge of defeating the TPM. There will be TPM private keys loose in the world, operated by software that has no intention of telling the truth to remote challengers. And this will be simplier than most people think. From what I understand about the current TPM designs, the TPM chip is NOT designed to be tamper-resistant. The IBM researchers told me that it is possible to read the secrets from the TPM chip with a standard bus reader. I've been meaning to wander over to the Computer Engineering department and borrow one of those to verify this claim. Based on this, it shouldn't be hard for a set of people to extract their keys from their TPM chips and spread them around the internet, emulating a real TPM. This I see as a major stumbling block for DRM systems based on TCPA. TCPA works very well against purely-software threats, but as far as protecting against computer owners and determined attackers, I'm not so sure. At this point, a design decision by the TCPA (TCG) folks comes into play. There are ways to design remote attestation that preserve privacy and there are ways that allow linkage of transactions by the same TPM. Either of these outcomes will kill the TCG, IMHO. I agree. This is why to make the TPM a success, specifically for something like DRM, the companies advocating it will have to convince the users that it is a good thing. This is the same problem they have now. They have to make the users *want* to use the trusted DRM features and *not* want to subvert them. They can do this by making the DRM features mostly unseen and providing cheap and effective ways for people to get the media that they want in the formats that they want. If they try to fight their own users, there will be enough ways of getting around TCPA for the users to fight back. You postulated that someday, when the TPM is ubiquitous, some content providers will demand remote attestation. I claim it will never become ubiquitous, because of people making my choice - and because it takes a long time to replace the installed base - and because the economic model for TPM deployment is seriously flawed. Well, there are a couple things that could change this. If other, non-DRM uses of the TPM chip become popular (say for example that everyone wants to use it to encrypt their hard drive), then that could speed deployment of the chip, since that functionality is also bundled with the remote attestation functionality. I know that then creates a market for a chip that does what is needed without the remote attestation functionality, but it then becomes business, not technology, that determines which people buy. If various service or content providers elect not to allow me service unless I do remote attestation, I then have 2 choices: use the friendly web service that will lie for me - or decline the content or service. Correct. However, this is where copyright and other government-granted monopolies come into play. If I want a specific piece of copyrighted material (say, a song), I have to either deal with the copyright owner (RIAA) on their terms (remote attestation), not get the song, or break the law. None of those three alternatives sound very good. The best chance is education of the masses, so everyone chooses one of the latter two and makes it economically infeasible for the RIAA to maintain their draconian terms. Then we have a useful piece of hardware in our computers (TCPA), subsidised largely by people like the RIAA, but who can't use it for economic reasons. That would be the ideal outcome. There are many
Re: example: secure computing kernel needed
William Arbaugh writes: If that is the case, then strong authentication provides the same degree of control over your computer. With remote attestation, the distant end determines if they wish to communicate with you based on the fingerprint of your configuration. With strong authentication, the distant end determines if they wish to communicate with you based on your identity. I'm a little confused about why you consider these similar. They seem very different to me, particularly in the context of mass-market transactions, where a service provider is likely to want to deal with the general public. While it's true that service providers could try to use some demand some sort of PKI credential as a way of getting the true name of those they deal with, the particular things they can do with a true name are much more limited than the things they could do with proof of someone's software configuration. Also, in the future, the cost of demanding a true name could be much higher than the cost of demanding a proof of software identity. To give a trivial example, I've signed this paragraph using a PGP clear signature made by my key 0167ca38. You'll note that the Version header claims to be PGP 17.0, but in fact I don't have a copy of PGP 17.0. I simply modified that header with my text editor. You can tell that this paragraph was written by me, but not what software I used to write it. As a result, you can't usefully expect to take any action based on my choice of software -- but you can take some action based on whether you trust me (or the key 0167ca38). You can adopt a policy that you will only read signed mail -- or only mail signed by a key that Phil Zimmermann has signed, or a key that Bruce Lehman has signed -- but you can't adopt a policy that you will only read mail written by mutt users. In the present environment, it's somewhat difficult to use technical means to increase or diminish others' incentive to use particular software (at least if there are programmers actively working to preserve interoperability). Sure, attestation for platform identity and integrity has some things in common with authentication of human identity. (They both use public-key cryptography, they can both use a PKI, they both attempt to prove things to a challenger based on establishing that some entity has access to a relevant secret key.) But it also has important differences. One of those differences has to do with whether trust is reposed in people or in devices! I think your suggestion is tantamount to saying that an electrocardiogram and a seismograph have the same medical utility because they are both devices for measuring and recording waveforms. I just don't see remote attestation as providing control over your computer provided the user/owner has control over when and if remote attestation is used. Further, I can think of several instances where remote attestation is a good thing. For example, a privacy P2P file sharing network. You wouldn't want to share your files with an RIAA modified version of the program that's designed to break the anonymity of the network. This application is described in some detail at http://www.eecs.harvard.edu/~stuart/papers/eis03.pdf I haven't seen a more detailed analysis of how attestation would benefit particular designs for anonymous communication networks against particular attacks. But it's definitely true that there are some applications of attestation to third parties that many computer owners might want. (The two that first come to mind are distributed computing projects like [EMAIL PROTECTED] and network games like Quake, although I have a certain caution about the latter which I will describe when the video game software interoperability litigation I'm working on is over.) It's interesting to note that in this case you benefit because you received an attestation, not because you gave one (although the network is so structured that giving an attestation is arranged to be the price of receiving one: Give me your name, horse-master, and I shall give you mine!). The other thing that end-users might like is if _non-peer-to-peer_ services they interacted with could prove properties about themselves -- that is, end-users might like to receive rather than to give attestations. An anonymous remailer could give an attestation to prove that it is really running the official Mixmaster and the official Exim and not a modified Mixmaster or modified Exim that try to break anonymity. Apple could give an attestation proving that it didn't have the ability to alter or to access the contents of your data while it was stored by its Internet hard drive service. One interesting question is how to characterize on-line services where users would be asked for attestation (typically to their detriment, by way of taking away their choice of software) as opposed to on-line services where users would be able to ask for attestation (typically to their
Re: Non-repudiation (was RE: The PAIN mnemonic)
Amir Herzberg wrote: Ben, Carl and others, At 18:23 21/12/2003, Carl Ellison wrote: and it included non-repudiation which is an unachievable, nonsense concept. Any alternative definition or concept to cover what protocol designers usually refer to as non-repudiation specifications? For example non-repudiation of origin, i.e. the ability of recipient to convince a third party that a message was sent (to him) by a particular sender (at certain time)? Or - do you think this is not an important requirement? Or what? I would second this call for some definition! FWIW, I understand there are two meanings: some form of legal inability to deny responsibility for an event, and cryptographically strong and repeatable evidence that a certain piece of data was in the presence of a private key at some point. Carl and Ben have rubbished non-repudiation without defining what they mean, making it rather difficult to respond. Now, presumably, they mean the first, in that it is a rather hard problem to take the cryptographic property of public keys and then bootstrap that into some form of property that reliably stands in court. But, whilst challenging, it is possible to achieve legal non-repudiability, depending on your careful use of assumptions. Whether that is a sensible thing or a nice depends on the circumstances ... (e.g., the game that banks play with pin codes). So, as a point of clarification, are we saying that non-repudiability is ONLY the first of the above meanings? And if so, what do we call the second? Or, what is the definition here? From where I sit, it is better to term these as legal non-repudiability or cryptographic non-repudiability so as to reduce confusion. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
At 02:01 PM 12/23/2003 -0500, Rich Salz wrote: If so, then I believe that we need a federated identity and management infrastructure. The difference is that the third-party PKI enrollment model still doesn't make sense, and organizations will take over their own identity issues, as with SAML and Liberty. Once you do that, adding publicKey as just another attribute is no big deal. With any luck, the new year will bring the analogy SOAP::other middleware as SAML::x.509 :) the one detailed presentation that I've so far seen of a SAML based product looked like it had exactly the same message flows description that I sat thru in a Kerberos project audit in the '80s. I asked the guy making the presentation about the similarity to Kerberos message flows and he said something to the effect of ah yes, kerberos. random kerberos refs: http://www.garlic.com/~lynn/subpubkey.html#kerberos -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Non-repudiation (was RE: The PAIN mnemonic)
At 11:18 AM 12/23/2003 +0200, Amir Herzberg wrote: Any alternative definition or concept to cover what protocol designers usually refer to as non-repudiation specifications? For example non-repudiation of origin, i.e. the ability of recipient to convince a third party that a message was sent (to him) by a particular sender (at certain time)? there is some reference in old posting in pkix thread: http://www.garlic.com/~lynn/aadsm11.htm#14 Meaning of Non-repudation possibly more than you want to know ... but merged security taxonomy and glossary ... sources at: http://www.garlic.com/~lynn/index.html#glosnote has definitions for: non-repudiation non-repudiation exchange non-repudiation information non-repudiation of creation non-repudiation of delivery non-repudiation of knowledge non-repudiation of origin non-repudiation of receipt non-repudiation of sending non-repudiation of submission non-repudiation of transport non-repudiation policy non-repudiation service non-repudiation token plus: NRD token NRO token NRS token NRT token -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
2) certificates were fundamentally designed to address a trust issue in offline environments where a modicum of static, stale data was better than nothing How many years have you been saying this, now? :) How do those modern online environments achieve end-to-end content integrity and privacy? My guess is that they don't; their use of private value-add networks made it unnecessary. If my guess is/was correct, than as more valuable transactions (or regulated data) flow over the commodity Internet, then those things will become important. Make sense? Am I right? If so, then I believe that we need a federated identity and management infrastructure. The difference is that the third-party PKI enrollment model still doesn't make sense, and organizations will take over their own identity issues, as with SAML and Liberty. Once you do that, adding publicKey as just another attribute is no big deal. With any luck, the new year will bring the analogy SOAP::other middleware as SAML::x.509 :) /r$ -- Rich Salz, Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
