Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
| David Wagner writes: | | To see why, let's go back to the beginning, and look at the threat | model. If multiple people are doing shared development on a central | machine, that machine must have an owner -- let's call him Linus. Now | ask yourself: Do those developers trust Linus? | | If the developers don't trust Linus, they're screwed. It doesn't how | much attestation you throw at the problem, Linus can always violate their | security model. As always, you've got to trust root (the system | administrator); nothing new here. | | Consequently, it seems to me we only need to consider a threat model | where the developers trust Linus. (Linus need not be infallible, but the | developers should believe Linus won't intentionally try to violate their | security goals.) In this case, owner-directed attestation suffices. | Do you see why? Linus's machine will produce an attestation, signed | by Linus's key, of what software is running. Since the developers trust | Linus, they can then verify this attestation. Note that the developers | don't need to trust each other, but they do need to trust the owner/admin | of the shared box. So, it seems to me we can get by without third-party | attestation. | | You could conceivably have a PC where the developers don't trust | Linus, but instead trust the PC manufacturer. The PC manufacturer | could have made it extremely expensive for Linus to tamper with the PC | in order to violate [the developers'] security model. (It isn't | logically impossible, it's just extremely expensive. Perhaps it costs | millions of dollars, or something.) Precisely - though see below. | There are computers like that today. At least, there are devices that can | run software, that are highly tamper-resistant, and that can do attestations. Smart cards are intended to work this way, too. | (Now there is an important question about what the cost to do a hardware | attack against those devices would be.) It seems to me to be a good thing | that the ordinary PC is not such a device. (Ryan Lackey, in a talk | about security for colocated machines, described using devices like | these for colocation where it's not appropriate or desirable to rely on | the physical security of the colocated machine. Of course, strictly | speaking, all security always relies on physical security.) This kind of thing goes *way* back. In the '70's, there was a company - I think the name was BASIC 4 - that sold a machine with two privileged levels. The OS ran at level 1 (user code at unprivileged level 2, of course). There were some things - like, probably, accounting - that ran at level 0. Even with physical access to the machine, it was supposed to be difficult to do anything to level 0 - unless you had a (physical) key to use in the lock on the front panel. The machine was intended as a replacement for the then- prevalent time-sharing model: An application developer would buy machines from the manufacturer, load them with application environments, and sell application services. Users of the machines could use the applications with fast local acceess, even do development - but could not modify the basic configuration. I know the company vanished well before networks got fast enough, and PC's cheap enough, the the business model stopped making any sense; but I know nothing of the details. | I don't know how the key management works in these devices. If the | keys used to sign attestations are loaded by (or known to) the device | owner, it wouldn't help with the case where the device owner is | untrusted. If the keys are loaded by the manufacturer, it might | support a model where the owner is untrusted and the manufacturer is | trusted. There's no more reason that the manufacturer has to be trusted than that the manufacturer of a safe has to be trusted (at least in the sense that neither needs to know the keys/combination on any particular machine/safe). If machines like this are to be built, they should require some special physical override to allow the keys to be configured. A key lock is still good technology for this purpose: It's a very well-understood technology, and its simplicity is a big advantage. A combination lock might be easier to integrate securely, for the same basic reason that combination locks became the standard for bank vaults: No need for an open passageway from the outside to the inside. (In the bank vault case, this passageway was a great way to get nitroglycerin inside the locking mechanism.) In either case, you could (like a bank) use a form of secret sharing, so that only a trusted group of people - with multiple keys, or multiple parts of the combination - could access the key setup mode. Given this, there is no reason why a machine fresh from the manufacturer need have any embedded keys. Will machines like this be built? Probably not, except for special purposes. The TCPA machines will likely require you (and the people who want to
Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Jerrold Leichter wrote: All of this is fine as long as there is a one-to-one association between machines and owners of those machines. Consider the example I gave earlier: A shared machine containing the standard distribution of the trusted computing software. All the members of the group that maintain the software will want to have the machine attest, to them, that it is properly configured and operating as intended. I think you may be giving up too quickly. It looks to me like this situation can be handled by owner-directed attestation (e.g., Owner Override, or Owner Gets Key). Do you agree? To see why, let's go back to the beginning, and look at the threat model. If multiple people are doing shared development on a central machine, that machine must have an owner -- let's call him Linus. Now ask yourself: Do those developers trust Linus? If the developers don't trust Linus, they're screwed. It doesn't how much attestation you throw at the problem, Linus can always violate their security model. As always, you've got to trust root (the system administrator); nothing new here. Consequently, it seems to me we only need to consider a threat model where the developers trust Linus. (Linus need not be infallible, but the developers should believe Linus won't intentionally try to violate their security goals.) In this case, owner-directed attestation suffices. Do you see why? Linus's machine will produce an attestation, signed by Linus's key, of what software is running. Since the developers trust Linus, they can then verify this attestation. Note that the developers don't need to trust each other, but they do need to trust the owner/admin of the shared box. So, it seems to me we can get by without third-party attestation. This scenario sounds pretty typical to me. Most machines have a single owner. Most machines have a system administrator (who must be trusted). I don't think I'm making unrealistic assumptions. You're trying to make the argument that feature X (here, remote attestation for multiple mutually-suspicious parties) has no significant uses. Historically, arguments like this are losers. Yes, this is a fair point. I suppose I would say I'm arguing that feature X (third-party attestation) seems to have few significant uses. It has some uses, but it looks like they are in the minority; for the most part, it seems that feature X is unnecessary. At the same time, many people are worried that feature X comes with significant costs. At least, this is how it looks to me. Maybe I've got something wrong. If these two points are both accurate, this is an interesting observation. If they're inaccurate, I'd be very interested to hear where they fail. - 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)
David Wagner writes: So it seems that third-party-directed remote attestation is really where the controversy is. Owner-directed remote attestation doesn't have these policy tradeoffs. Finally, I'll come back to the topic you raised by noting that your example application is one that could be supported with owner-directed remote attestation. You don't need third-party-directed remote attestation to support your desired use of remote attestation. So, TCPA or Palladium could easily fall back to only owner-directed attestation (not third-party-attestation), and you'd still be able to verify the software running on your own servers without incurring new risks of DRM, software lock-in, or whatever. I should mention that Seth Schoen's paper on Trusted Computing anticipates many of these points and is well worth reading. His notion of owner override basically converts third-party-directed attestation into owner-directed attestation, and thereby avoids the policy risks that so many have brought up. If you haven't already read his paper, I highly recommend it. http://www.eff.org/Infra/trusted_computing/20031001_tc.php Thanks for the kind words. Nikita Borisov has proposed an alternative to Owner Override which Ka-Ping Yee has called Owner Gets Key, and which is probably the same as what you're discussing. Most TC vendors have entered into this with some awareness of the risks. For example, the TCPA whitepaper that John Gilmore mentioned here earlier specifically contemplates punishing people for using disapproved software, without considering exactly why it is that people would want to put themselves into a position where they could be punished for doing that (given that they can't now!). (In deference to Unlimited Freedom's observations, it is not logically impossible that people would ever want to put themselves into that position; the TCPA whitepaper just didn't consider why they would.) As a result, I have not had any TC vendor express much interest in Owner Override or Owner Gets Key. Some of them correctly pointed out that there are interesting user interface problems associated with making this usable yet resistant to social engineering attacks. There might be paternalistic reasons for not wanting to give end-users the attestation keys, if you simply don't trust that they will use them safely. (But there's probably no technical way to have our cake and eat it too: if you want to do paternalistic security, you can probably then abuse it; if you want to give the owner total control, you can't prevent the owner from falling victim to social engineering.) Still, the lack of a totally obvious secure UI hasn't stopped research from taking place in related areas. For example, Microsoft is reportedly still trying to figure out how to make clear to people whether the source of a particular UI element is the program they think it is, and how to handle the installation of NGSCB trusted computing agents. Secure UI is full of thorny problems. I've recently been concerned about one problem with the Owner Override or Owner Gets Key approaches. This is the question of whether they are particularly vulnerable to a man-in-the-middle attack. Suppose that I own a computer with the TCG TPM FOO and you are a server operator, and you and I trust each other and believe that we have aligned interests. (One example is the case where you are a bank and we both want to be sure that I am using a pristine, unaltered computing environment in order to access my account. Neither of us will benefit if I can be tricked into making bogus transactions.) An attacker Mallory owns a computer with the TCG TPM BAR. We assume that Mallory has already compromised my computer (because our ability to detect when Mallory does that is the whole reason we're using attestation in the first place). Mallory replaces my web browser (or financial software) with a web browser that he has modified to send queries to him instead of to you, and to contain a root CA certificate that makes it trust a root CA that Mallory controls. (Alternatively, he's just made the new web browser ignore the results of SSL certificate validation entirely, though that might be easier to detect.) Now when I go to your web site, my connection is redirected to Mallory's computer, which proxies it and initiates a connection to you. You ask for an attestation as a condition of accessing your service. Since I have no particular reason to lie to you (I believe that your reason for requesting the attestation is aligned with my interest), I direct my computer to give you an attestation reflecting the actual state of FOO's PCR values. This attestation is generated and reflects a signature by foo on a set of PCR values that show the results of Mallory's tampering. But Mallory does _not_ pass this attestation along to you. Instead, Mallory uses Owner Override or Owner Gets Key to generate a new attestation reflecting the original set of PCR
Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
| Rick Wash wrote: | There are many legitimate uses of remote attestation that I would like to | see. For example, as a sysadmin, I'd love to be able to verify that my | servers are running the appropriate software before I trust them to access | my files for me. Remote attestation is a good technical way of doing that. | | This is a good example, because it brings out that there are really | two different variants of remote attestation. Up to now, I've been | lumping them together, but I shouldn't have been. In particular, I'm | thinking of owner-directed remote attestation vs. third-party-directed | remote attestation. The difference is who wants to receive assurance of | what software is running on a computer; the former mechanism allows to | convince the owner of that computer, while the latter mechanism allows | to convince third parties | | Finally, I'll come back to the topic you raised by noting that your | example application is one that could be supported with owner-directed | remote attestation. You don't need third-party-directed remote | attestation to support your desired use of remote attestation. So, TCPA | or Palladium could easily fall back to only owner-directed attestation | (not third-party-attestation), and you'd still be able to verify the | software running on your own servers without incurring new risks of DRM, | software lock-in, or whatever All of this is fine as long as there is a one-to-one association between machines and owners of those machines. Consider the example I gave earlier: A shared machine containing the standard distribution of the trusted computing software. All the members of the group that maintain the software will want to have the machine attest, to them, that it is properly configured and operating as intended. We can call the group the owner of the machine, and create a single key pair that all of them know. But this is brittle - shared secrets always are. Any member of the group could then modify the machine and, using his access to the private key, fake the all clear indication. Each participant should have his own key pair, since attestation using a particular key pair only indicates security with respect to those who don't know the private key of the pair - and a member of a development team for the secure kernel *should* mistrust his fellow team members! So, again, there are simple instances where it will prove useful to be able to maintain multiple sets of independent key pairs. Now, in the shared distribution machine case, on one level team members should be mutually suspicious, but on another they *do* consider themselves joint owners of the machine - so it doesn't bother them that there are key pairs to which they don't have access. After all, those key pairs are assigned to *other* owners of the machine! But exactly the same mechanism could be used to assign a key pair to Virgin Records - who we *don't* want to consider an owner of the machine. As long as, by owner, you mean a single person, or a group of people who completely trust each other (with respect to the security problem we are trying to solve); and as long as each machine only has only one owner; then, yes, one key pair will do. But as soon as owner can encompass mutually suspicious parties, you need to have mutual independent key pairs - and then how you use them, and to whom you grant them, becomes a matter of choice and policy, not technical possibility. BTW, even with a single owner, multiple independent key pairs may be useful. Suppose I have reason to suspect that my private key has been leaked. What can I do? If there is only one key pair around, I have to rebuild my machine from scratch. But if I had the forsight to generate *two* key pairs, one of which I use regularly - and the other of which I sealed away in a safe - then I can go to the safe, get out my backup key pair, and re-certify my machine. In fact, it would probably be prudent for me to generate a whole bunch of such backup key pairs, just in case. You're trying to make the argument that feature X (here, remote attestation for multiple mutually-suspicious parties) has no significant uses. Historically, arguments like this are losers. People come up with uses for all kinds of surprising things. In this case, it's not even very hard. An argument that feature X has uses, but also imposes significant and non- obvious costs, is another thing entirely. Elucidating the costs is valuable. But ultimately individuals will make their own analysis of the cost/benefit ratio, and their calculations will be different from yours. Carl Ellison, I think, argued that TCPA will probably never have large penetration because the dominant purchasing factor for consumers is always initial cost, and the extra hardware will ensure that TCPA-capable machines will always be more expensive. Maybe he's right. Even if he isn't, as long as people believe that they have control over the costs associated with
Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
On Tue, 23 Dec 2003, Seth David Schoen wrote: When attestation is used, it likely will be passed in a service like HTTP, but in a documented way (for example, using a protocol based on XML-RPC). There isn't really any security benefit obtained by hiding the content of the attestation _from the party providing it_! It's not the parties who are interested in security alone we're worried about. There is an advantage in profiling and market research, so I expect anyone able to effectively subvert the protocols to attempt to hide the content of remote attestataion. Bear - 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)
Antonomasia writes: From: Carl Ellison [EMAIL PROTECTED] Some TPM-machines will be owned by people who decide to do what I suggested: install a personal firewall that prevents remote attestation. How confident are you this will be possible ? Why do you think the remote attestation traffic won't be passed in a widespread service like HTTP - or even be steganographic ? The main answer is that the TPM will let you disable attestation, so you don't even have to use a firewall (although if you have a LAN, you could have a border firewall that prevented anybody on the LAN from using attestation within protocols that the firewall was sufficiently familiar with). When attestation is used, it likely will be passed in a service like HTTP, but in a documented way (for example, using a protocol based on XML-RPC). There isn't really any security benefit obtained by hiding the content of the attestation _from the party providing it_! Certainly attestation can be used as part of a key exchange so that subsequent communications between local software and a third party are hidden from the computer owner, but because the attestation must happen before that key exchange is concluded, you can still examine and destroy the attestation fields. One problem is that a client could use HTTPS to establish a session key for a session within which an attestation would be presented. That might disable your ability to use the border firewall to block the attestation, but you can still disable it in the TPM on that machine if you control the machine. The steganographic thing is implausible because the TPM is a passive device which can't control other components in order to get them to signal information. -- Seth David Schoen [EMAIL PROTECTED] | Very frankly, I am opposed to people http://www.loyalty.org/~schoen/ | being programmed by others. http://vitanuova.loyalty.org/ | -- Fred Rogers (1928-2003), |464 U.S. 417, 445 (1984) - 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: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
At 03:03 PM 12/21/2003 -0800, Seth David Schoen wrote: Some people may have read things like this and mistakenly thought that this would not be an opt-in process. (There is some language about how the user's platform takes various actions and then responds to challenges, and perhaps people reasoned that it was responding autonomously, rather than under its user's direction.) my analogy ... at least in online scenario has been to wild, wild west before there were traffic conventions, traffic signs, lane markers, traffic lights, standards for vehicles ... misc. traffic rules about operating an unsafe vehicle and driving recklessly, various minimums about traffic regulations, and things like insurance requirements to cover the cost of accidents. infected machines that do distributed DOS attacks ... might be considered analogous to large overloaded trucks w/o operational breaks (given rise to truck inspection and weighing stations). many ISPs are already monitoring, accounting and controlling various kinds of activity with respect to amount of traffic, simultaneous log-ins, etc. If there are sufficient online incidents ... then there could be very easy to declare machines that become infected and are used as part of various unacceptable behavior to have then declared unsafe vehicles and some sort of insurace be required to cover the costs of associated with unsafe and reckless driving on the internet. Direct costs to individuals may go up ... but the unsafe and reckless activities currently going on represent enormous infrastructure costs. Somewhat analogy to higher insurance premiums for less safe vehicles, government minimums for crash tests, bumper conventions, seat belts, air bags, etc. part of the issue is that some number of the platforms never had original design point of significant interaction on a totally open and free internet (long ago and far away, vehicles that didn't have bumpers, crash tests, seat belts, air bags, safety glass, etc). Earlier in the original version of this thread ... I made reference to some number of systems from 30 or more years ago ... that were designed to handle such environments and had basic security designed in from the start ... were found to be not subject to majority of the things that are happening to lots of the current internet connected platforms. http://www.garlic.com/~lynn/aadsm16.htm#8 example: secure computing kernel needed misc. past analogies to unsafe and reckless driving on the internet: http://www.garlic.com/~lynn/aadsm14.htm#14 blackhole spam = mail unreliability (Re: A Trial Balloon to Ban Email?) http://www.garlic.com/~lynn/aadsm14.htm#15 blackhole spam = mail unreliability (Re: A Trial Balloon to Ban Email?) http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2002p.html#27 Secure you PC or get kicked off the net? http://www.garlic.com/~lynn/2003i.html#17 Spam Bomb http://www.garlic.com/~lynn/2003m.html#21 Drivers License required for surfing? -- 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: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
From: Carl Ellison [EMAIL PROTECTED] Some TPM-machines will be owned by people who decide to do what I suggested: install a personal firewall that prevents remote attestation. How confident are you this will be possible ? Why do you think the remote attestation traffic won't be passed in a widespread service like HTTP - or even be steganographic ? -- ## # Antonomasia ant notatla.org.uk # # See http://www.notatla.org.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)
Carl Ellison wrote: We see here a difference between your and my sides of the Atlantic. Here in the US, almost no one has a smart card. Of those cards you carry, how many are capable of doing public key operations? A simple memory smartcard doesn't count for what we were talking about. I don't know. If you can tell me how to find out, I'd be happy to investigate. I have quite a few that are no longer needed, so destructive investigation is possible :-) BTW, I forgot the two smartcards that are used by my Sky satellite TV stuff. There are other problems with doing TCPA-like operations with a smartcard, but I didn't go into those. The biggest one to chew on is that I, the computer owner, need verification that my software is in good shape. My agent in my computer (presumably the smartcard) needs a way to examine the software state of my computer without relying on any of the software in my computer (which might have been corrupted, if the computer's S/W has been corrupted). This implies to me that my agent chip needs a H/W path for examining all the S/W of my computer. That's something the TPM gives us that a smartcard doesn't (when that smartcard goes through a normal device driver to access its machine). I'm not arguing with this - just the economic argument about number of smartcards. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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 [EMAIL PROTECTED]
RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Seth, that was a very good and interesting reply. Thank you. IBM has started rolling out machines that have a TPM installed. If other companies do that too (and there might be others that do already - since I don't follow this closely) then gradually the installed base of TPM-equipped machines will grow. It might take 10 years - or even more - before every machine out there has a TPM. However, that day may well come. 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. 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. 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. There might even be one or more web services out there with a pool of such keys, offering to do an attestation for you telling whatever lie you want to tell. With such a service in operation, it is doubtful that a service or content provider would put much faith in remote attestation - and that, too, might kill the effort. 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. If the former is chosen, then the web service needs very few keys. If the privacy protection is perfect, then the web service needs only 1 key. If the privacy violation is very strong, then the web service won't work, but the TCG folks will have set themselves up for a massive political campaign around its violation of user privacy. Either of these outcomes will kill the TCG, IMHO. This is the reason that, when I worked for a hardware company active in the TCPA(TCG), I argued strongly against supporting remote attestation. I saw no way that it could succeed. Meanwhile, I am no longer in that company. I have myself to look out for. If I get a machine with a TPM, I will make sure I have the firewall installed. I will use the TPM for my own purposes and let the rest of the world think that I have an old machine with no TPM. 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. 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. The scare scenario you paint is one in which I am the lone voice of concern floating in a sea of people who will happily give away their privacy and allow some service or content provider to demand this technology on my end. In such a society, I would stand out and be subject to discrimination. This is not a technical problem. This is a political problem. If that is a real danger, then we need to educate those people. RIAA and MPAA have been hoping for some technological quick fix to let them avoid facing the hard problem of dealing with people who don't think the way they would like people to think. It seems to me that you and John Gilmore and others are doing exactly the same thing - hoping for technological censorship to succeed so that you can avoid facing the hard problem of dealing with people who don't think the way they should (in this case, the people who happily give away their privacy and accept remote attestation in return for dancing pigs). I don't have the power to stop this technology if folks decide to field it. I have only my own reason and skills. - Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://theworld.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ -Original Message- From: Seth David Schoen [mailto:[EMAIL PROTECTED] On Behalf Of Seth David Schoen Sent: Sunday, December 21, 2003 3:03 PM To: Carl Ellison Cc: 'Stefan Lucks'; [EMAIL PROTECTED] Subject: Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed) - 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)
Stefan Lucks [EMAIL PROTECTED] writes: Currently, I have three smart cards in my wallet, which I did not want to own and which I did never pay for. I never used any of them. Conversation from a few years ago, about multifunction smart cards: - Multifunction smart cards are great, because they'll reduce the number of [smart] cards we'll have to carry around. - I'm carrying zero smart cards, so it's working already! Peter. - 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)
Carl Ellison wrote: It is an advantage for a TCPA-equipped platform, IMHO. Smart cards cost money. Therefore, I am likely to have at most 1. If I glance quickly through my wallet, I find 7 smartcards (all credit cards). Plus the one in my phone makes 8. So, run that at most 1 argument past me again? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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 [EMAIL PROTECTED]
RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
We see here a difference between your and my sides of the Atlantic. Here in the US, almost no one has a smart card. Of those cards you carry, how many are capable of doing public key operations? A simple memory smartcard doesn't count for what we were talking about. There are other problems with doing TCPA-like operations with a smartcard, but I didn't go into those. The biggest one to chew on is that I, the computer owner, need verification that my software is in good shape. My agent in my computer (presumably the smartcard) needs a way to examine the software state of my computer without relying on any of the software in my computer (which might have been corrupted, if the computer's S/W has been corrupted). This implies to me that my agent chip needs a H/W path for examining all the S/W of my computer. That's something the TPM gives us that a smartcard doesn't (when that smartcard goes through a normal device driver to access its machine). - Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://theworld.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ -Original Message- From: Ben Laurie [mailto:[EMAIL PROTECTED] Sent: Friday, December 19, 2003 2:42 AM To: Carl Ellison Cc: 'Stefan Lucks'; [EMAIL PROTECTED] Subject: Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed) Carl Ellison wrote: It is an advantage for a TCPA-equipped platform, IMHO. Smart cards cost money. Therefore, I am likely to have at most 1. If I glance quickly through my wallet, I find 7 smartcards (all credit cards). Plus the one in my phone makes 8. So, run that at most 1 argument past me again? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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 [EMAIL PROTECTED]
RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
Stefan, I replied to much of this earlier, so I'll skip those parts. - Carl +--+ |Carl M. Ellison [EMAIL PROTECTED] http://theworld.com/~cme | |PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Lucks Sent: Tuesday, December 16, 2003 1:02 AM To: Carl Ellison Cc: [EMAIL PROTECTED] Subject: RE: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed) On Mon, 15 Dec 2003, Carl Ellison wrote: The point is that Your system is not supposed to prevent You from doing anything I want you not to do! TCPA is supposed to lock You out of some parts of Your system. This has nothing to do with the TCPA / TPM hardware. This is a political argument about the unclean origins of TCPA (as an attempt to woo Hollywood). I, meanwhile, never did buy the remote attestation argument for high price content. It doesn't work. So, I looked at this as an engineer. OK, I've got this hardware. If remote attestation is worthless, then I can and should block that (e.g., with a personal firewall). Now, if I do that, do I have anything of value left? My answer was that I did - as long as I could attest about the state of the software to myself, the machine owner. This required putting the origins of the project out of my head while I thought about the engineering. That took effort, but paid off (to me). [...] If it were my machine, I would never do remote attestation. With that one choice, I get to reap the personal advantages of the TPM while disabling its behaviors that you find objectionable (serving the outside master). I am not sure, whether I fully understand you. If you mean that TCPA comes with the option to run a secure kernel where you (as the owner and physical holder of the machine running) have full control over what the system is doing and isn't doing -- ok, that is a nice thing. On the other hand, we would not need a monster such as TCPA for this. What we need is some agent of mine - a chip - that: 1) has access to the machine guts, so it can verify S/W state 2) has a cryptographic channel to me, so it can report that result to me and 3) has its own S/W in a place where no attacker could get to it, even if that attacker had complete control over the OS. The TCPA/TPM can be used that way. Meanwhile, the TPM has no channel to the outside world, so it is not capable of doing remote attestation by itself. You need to volunteer to allow such communications to go through. If you don't like them, then block them. Problem solved. This reminds me of the abortion debate bumper sticker. If you're against abortion, don't have one. - Carl - 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 Mon, 15 Dec 2003 19:02:06 -0500 (EST) Jerrold Leichter [EMAIL PROTECTED] wrote: However, this advantage is there only because there are so few smart cards, and so few smart card enabled applications, around. It is not really true that there are so few smartcards. Almost every mobile phone contains one (the SIM module is a smartcard). Also the situation in Europe is quite different from the USA. Electronic purses on smart cards are pretty common here, especially in France and the Netherlands, where most adults have at least one. But it is true that there are only very few smart card enabled applications. I have worked on several projects for multifunctional use of these smart cards and almost all of them were complete failures. Ernst Lippe - 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)
At 10:51 AM 12/16/2003 +0100, Stefan Lucks wrote: I agree with you: A good compromise between security and convenience is an issue, when you are changing between different smart cards. E.g., I could imagine using the smart card *once* when logging into my bank account, and then only needing it, perhaps, to authorise a money transfer. This is a difficult user interface issue, but something we should be able to solve. One problem of TCPA is the opposite user interface issue -- the user has lost control over what is going on. (And I believe that this originates much of the resistance against TCPA.) In sci.crtypt, there has been a thread discussing does OTP (one-time-pad) and how does integrity and authentication play and somewhat subtread about does authentication of a message involve checking the integrity of the contents and/or checking the origin of message. A security taxonomy, PAIN: * privacy (aka thinks like encryption) * authentication (origin) * integrity (contents) * non-repudiation http://www.garlic.com/~lynn/2003p.html#4 Does OTP need authentication? http://www.garlic.com/~lynn/2003p.html#6 Does OTP need authentication? http://www.garlic.com/~lynn/2003p.html#17 Does OTP need authentication? One of the issues is that privacy, authentication, and integrity are totally different business processes and that the same technology, lets say involving keys might be involved in all three, aka digital signatures ( public/private keys) can be used to simultaneously provide for authentication (of sender) and integrity )of message contents). Both privacy (encryption) and authentication (say digital signatures) can involve keys that need protecting; privacy because key access needs to be controlled to prevent unauthorized access to data, authentication because unauthorized access to keys could lead to impersonation. In the authentication case, involving public/private keys the business requirement has sometimes led to guidelines that the private key is absolutely protected and things like key escrow is not allowed because it could contributed to impersonation. In the privacy csse, involving public/private keys ... the business requirement can lead to guidelines that require mandated escrow of private key(s) because of business continuity issues. This can create ambiguity where the same technology can be used for both authentication and privacy, but because the business processes are different, there can be mandated requirement that the same keys are never used for both authentication and privacy ... and it is mandated that authentication keys are never escrowed and that privacy keys are always escrowed. TCPA chip can also be used to protect private keys used in authentication either authentication of the hardware component as its own entity say like a router in a large network, or possibly implied authentication of a person that owns or possesses the hardware component. An authentication taxonomy is 3-factor authentication: * something you have * something you know * something you are A hardware token (possibly in chipcard form factor) can be designed to generate a unique public/private key pair inside the token and that the private key never leaves the chip. Any digital signature that can be verified by the corresponding public key can be used to imply something you have authentication (i.e. the digital signature is assumed to have originated from a specific hardware token). A hardware token can also be designed to only operate in specific way when the correct PIN/password has been entered in which case the digital signature can imply two-factor authentication, both something you have and something you know. From a business process standpoint it would be perfectly consistent to mandate that there is never key escrow for keys involved in authentication business process while at the same time mandating key escrow for keys involved in privacy. At issue in business continuity are business requirements for things like no single point of failure, offsite storage of backups, etc. The threat model is 1) data in business files can be one of its most valuable assets, 2) it can't afford to have unauthorized access to the data, 3) it can't afford to loose access to data, 4) encryption is used to help prevent unauthorized access to the data, 5) if the encryption keys are protected by a TCPA chip, are the encryption keys recoverable if the TCPA chip fails? -- 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: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
At 07:02 PM 12/15/2003 -0500, Jerrold Leichter wrote: However, this advantage is there only because there are so few smart cards, and so few smart card enabled applications, around. A software only, networked smart card would solve the chicken and egg problem. One such solution is Tamper resistant method and apparatus, [Ellison], USPTO 6,073,237 (Do a patent number search at http://www.uspto.gov/patft/index.html) Carl invented this as an alternative to Smartcards back in the SET development days. Pat Pat Farrell [EMAIL PROTECTED] http://www.pfarrell.com - 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 Mon, 15 Dec 2003, Jerrold Leichter wrote: | This is quite an advantage of smart cards. However, this advantage is there only because there are so few smart cards, and so few smart card enabled applications, around. Strangely enough, Carl Ellison assumed that you would have at most one smart card, anyway. I'd rather think you are right, here. Really secure mail *should* use its own smart card. When I do banking, do I have to remove my mail smart card? Encryption of files on my PC should be based on a smart card. Do I have to pull that one out? Does that mean I can't look at my own records while I'm talking to my bank? If I can only have one smart card in my PC at a time, does that mean I can *never* cut and paste between my own records and my on-line bank statement? To access my files and my employer's email system, do I have to have to trust a single smart card to hold both sets of secrets? I agree with you: A good compromise between security and convenience is an issue, when you are changing between different smart cards. E.g., I could imagine using the smart card *once* when logging into my bank account, and then only needing it, perhaps, to authorise a money transfer. This is a difficult user interface issue, but something we should be able to solve. One problem of TCPA is the opposite user interface issue -- the user has lost control over what is going on. (And I believe that this originates much of the resistance against TCPA.) Ultimately, to be useful a trusted kernel has to be multi-purpose, for exactly the same reason we want a general-purpose PC, not a whole bunch of fixed- function appliances. Whether this multi-purpose kernel will be inside the PC, or a separate unit I can unplug and take with me, is a separate issue. Give the current model for PC's, a separate key is probably a better approach. Agreed! However, there are already experiments with PC in my pocket designs: A small box with the CPU, memory, and disk, which can be connect to a small screen to replace a palmtop, or into a unit with a big screen, a keyboard, etc., to become my desktop. Since that small box would have all my data, it might make sense for it to have the trusted kernel. (Of course, I probably want *some* part to be separate to render the box useless is stolen.) Agreed again! | There is nothing wrong with the idea of a trusted kernel, but trusted | means that some entity is supposed to trust the kernel (what else?). If | two entities, who do not completely trust each other, are supposed to both | trust such a kernel, something very very fishy is going on. Why? If I'm going to use a time-shared machine, I have to trust that the OS will keep me protected from other users of the machine. All the other users have the same demands. The owner of the machine has similar demands. Actually, all users have to trust the owner (or rather the sysadmin). The key words are have to trust! As you wrote somewhere below: Part of the issue with TCPA is that the providers of the kernel that we are all supposed to trust blindly are also going to be among those who will use it heavily. Given who those producers are, that level of trust is unjustifiable. I entirely agree with you! | More than ten years ago, Chaum and Pedersen [...] |+---+ +-+ +---+ || Outside World | - | Your PC | - | TCPA-Observer | |+---+ +-+ +---+ | | TCPA mixes Your PC and the observer into one trusted kernel and is | thus open to abuse. I remember looking at this paper when it first appeared, but the details have long faded. It's an alternative mechanism for creating trust: Instead of trusting an open, independently-produced, verified implementation, it uses cryptography to construct walls around a proprietary, non-open implementation that you have no reason to trust. Please re-read the paper! First, it is not a mechanism for *creating* trust. It is rather a trust-avoidance mechanism! You are not trusting the observer at all, and you don't need to. The outsider is not trusting you or your PC at all, and she donesn't need to. Second, how on earth did you get the impression that Chaum/Pedersen is about proprietary non open implenentations? Nothing stops people from producing independent and verified implementations. As a matter of fact, since people can concentrate on writing independent and verified implementations for the sofware on Your PC, providing an independently produced and verified implementation woud be much much simpler than ever providing such an implementation for the TCPA hardware. Independent implementations of the observer's soft- and hardware are simpler than in the case of TCPA as well, but this is a minor issue. You don't need to trust the observer, so you don't care about independent and verified implementations. With a Chaum/Pedersen style scheme, the
Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)
| Which brings up the interesting question: Just why are the reactions to | TCPA so strong? Is it because MS - who no one wants to trust - is | involved? Is it just the pervasiveness: Not everyone has a smart card, | but if TCPA wins out, everyone will have this lump inside of their | machine. | | There are two differences between TCPA-hardware and a smart card. | | The first difference is obvious. You can plug in and later remove a smart | card at your will, at the point of your choice. Thus, for homebanking with | bank X, you may use a smart card, for homebaning with bank Y you | disconnect the smart card for X and use another one, and before online | gambling you make sure that none of your banking smart cards is connected | to your PC. With TCPA, you have much less control over the kind of stuff | you are using. | | This is quite an advantage of smart cards. However, this advantage is there only because there are so few smart cards, and so few smart card enabled applications, around. Really secure mail *should* use its own smart card. When I do banking, do I have to remove my mail smart card? Encryption of files on my PC should be based on a smart card. Do I have to pull that one out? Does that mean I can't look at my own records while I'm talking to my bank? If I can only have one smart card in my PC at a time, does that mean I can *never* cut and paste between my own records and my on-line bank statement? To access my files and my employer's email system, do I have to have to trust a single smart card to hold both sets of secrets? I just don't see this whole direction of evolution as being viable. Oh, we'll pass through that stage - and we'll see products that let you connect multiple smart cards at once, each guaranteed secure from the others. But that kind of add-on is unlikely to really *be* secure. Ultimately, to be useful a trusted kernel has to be multi-purpose, for exactly the same reason we want a general-purpose PC, not a whole bunch of fixed- function appliances. Whether this multi-purpose kernel will be inside the PC, or a separate unit I can unplug and take with me, is a separate issue. Give the current model for PC's, a separate key is probably a better approach. However, there are already experiments with PC in my pocket designs: A small box with the CPU, memory, and disk, which can be connect to a small screen to replace a palmtop, or into a unit with a big screen, a keyboard, etc., to become my desktop. Since that small box would have all my data, it might make sense for it to have the trusted kernel. (Of course, I probably want *some* part to be separate to render the box useless is stolen.) | The second point is perhaps less obvious, but may be more important. | Usually, *your* PC hard- and software is supposed to to protect *your* | assets and satisfy *your* security requirements. The trusted hardware | add-on in TCPA is supposed to protect an *outsider's* assets and satisfy | the *outsider's* security needs -- from you. | | A TCPA-enhanced PC is thus the servant of two masters -- your servant | and the outsider's. Since your hardware connects to the outsider directly, | you can never be sure whether it works *against* you by giving the | outsider more information about you than it should (from your point if | view). | | There is nothing wrong with the idea of a trusted kernel, but trusted | means that some entity is supposed to trust the kernel (what else?). If | two entities, who do not completely trust each other, are supposed to both | trust such a kernel, something very very fishy is going on. Why? If I'm going to use a time-shared machine, I have to trust that the OS will keep me protected from other users of the machine. All the other users have the same demands. The owner of the machine has similar demands. The same goes for any shared resource. A trusted kernel should provide some isolation guarantees among contexts. These guarantees should be independent of the detailed nature of the contexts. I think we understand pretty well what the *form* of these guarantees should be. We do have problems actually implementing such guarantees in a trustworthy fashion, however. Part of the issue with TCPA is that the providers of the kernel that we are all supposed to trust blindly are also going to be among those who will use it heavily. Given who those producers are, that level of trust is unjustifiable. However, suppose that TCPA (or something like it) were implemented entirely by independent third parties, using open techniques, and that they managed to produce both a set of definitions of isolation, and an implementation, that were widely seen to correctly specify, embody, and enforce strict protection. How many of the criticisms of TCPA would that mute? Some: Given open standards, a Linux TCPA-based computing platform could be produced. Microsoft's access the the trusted kernel would be exactly the same as everyone else's; there would be no
