Re: Cryptogram: Palladium Only for DRM
Hi Nomen I am sending to crypto only as I am not on any of the other aliases you sent to. Feel free to fwd. How about hacked instead of broken? Broken implies that a machine doesn't work; hacked implies it has been changed somehow but that it still works. Let's say that a hacked Pd machine is a machine whose root keys have been discovered through any means outside of the security model for that machine. So a machine designed to give up its keys or to take keys in from an outisde source isn't hacked. A machine whose security model includes protecting the keys from everything, but whose keys have become known, is a hacked machine. I can certainly imagine situations where Pd will be on a hacked machine and won't know it. Once the machine has been hacked, a user (or process, or piece of SW, or whatever) can unlock all secrets which use the local keys as root keys. So the symmetric keys used to protect a given piece of data would be compromised, and all data which uses the same symmetric key can now be unlocked. Rather than having to hand someone data, you could hand them keys (presuming they have the data already). The less global a secret, the less vulnerable it is to key hand-offs, but if more than one existence of something is protected by the same key, that key represents an easily distributed attack. Even in cases where a given piece of data is secured with a unique key or keys, once you have hacked those keys (or more likely the root keys used to gen those keys) you can decrypt the data itself. If all data in the world only existed in Pd virtual vaults and was encrypted using different unique keys, the data itself is still it's own secret. You can still extract everything in Pd via a HW attack. Now rather than hand off the keys, you hand off the data. How is this BORE resistant? The Pd security model is BORE resistant for a unique secret protected by a unique key on a given machine. Your hack on your machine won't let you learn the secrets on my machine; to me that's BORE resistant. Any use of Pd to protect global secrets reduces the BORE resistance for the information protected by those secrets. Only the Pd nexus (sorry, new name for the nub, er I mean TOR, er I mean secure kernel, ...) knows each applications secrets, and it protects those secrets from everything else absolutely. The nexus won't analyze data and decide if it should or shouldn't be there; no Pd DRL's. (A DRM scheme on top of Pd could enforce DRL's for content within its own vault, of course, but it can't cross the vault boundary to try to enforce a DRL in someone else's vault.) The goal is to protect data for whomever is asking for protection, and to keep that data secure for that application. (I must note that we are basing our design on existing US law. Should the law change and require different behaviors, or should other countries require different behaviors, we will need to find a way to comply.) Palladium systems won't seek out and destroy anything, either locally or remotely. Additionally the nexus has no understanding of what legitmate or illicit means, so Pd really couldn't do this if it wanted to (it doesn't). Data will be protected by Pd (in memory; on disk). Only applications with the right hash (or those named by the original hashee) can access any given piece of data. P - Original Message - From: Nomen Nescio [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 5:10 PM Subject: Re: Cryptogram: Palladium Only for DRM Peter Biddle writes: Pd is designed to fail well - failures in SW design shouldn't result in compromised secrets, and compromised secrets shouldn't result in a BORE attack. Could you say something about the sense in which Palladium achieves BORE (break once run everywhere) resistance? It seems that although Palladium is supposed to be able to provide content security (among other things), a broken Palladium implementation would allow extracting the content from the virtual vault where it is kept sealed. In that case the now-decrypted content can indeed run everywhere. This seems to present an inconsistency between the claimed strength of the system and the description of its security behavior. This discrepancy may be why Palladium critics like Ross Anderson charge that Microsoft intends to implement document revocation lists which would let Palladium systems seek out and destroy illicitly shared documents and even programs. Some have claimed that Microsoft is talking out of both sides of its mouth, promising the content industry that it will be protected against BORE attacks, while assuring the security/privacy community that the system is limited in its capabilities. If you could clear up this discrepancy that would be helpful. Thanks... - The Cryptography Mailing List
Re: Cryptogram: Palladium Only for DRM
Peter N. Biddle wrote: [...] You can still extract everything in Pd via a HW attack. [...] How is this BORE resistant? The Pd security model is BORE resistant for a unique secret protected by a unique key on a given machine. Your hack on your machine won't let you learn the secrets on my machine; to me that's BORE resistant. [...] Yes, but... For me, BORE (Break Once Run Everywhere) depends on the application. You can't analyze Palladium in isolation, without looking at the app, too. It doesn't make sense to say Palladium isn't susceptible to BORE attacks, if the applications themselves are subject to BORE attacks. For example, if a record company builds an app that stores a MP3 of the latest Britney Spears song in a Palladium vault, then this app will be susceptible to BORE attacks. Extracting that MP3 from any one machine suffices to spread it around the world. It won't comfort the record company much to note that the attacker didn't learn the Palladium crypto keys living on other machines; the damage has already been done. Palladium doesn't make DRM resistant to BORE attacks. It can't. In short, there are some applications that Palladium can't make BORE-resistant. Some apps (e.g., DRM) are simply fundamentally fragile. Maybe a more interesting question is: For which apps does Palladium provide resistance against BORE attacks that is not available by other means? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptogram: Palladium Only for DRM
Peter: The question of what is trust might fill this listserver for months. But, if we want to address some of the issues that Pd (and, to some extent, PKI) forces on us then we must be clear what we mean when we talk about trust in a communication system -- what is a trusted certificate, a trusted computer? Trusted for what? What happens when I connect two computers that are trusted on matters of X -- are they trusted together on matters of X, less or more? What do we mean by trustworthy? I can send you some of my papers on this but the conclusion I arrived is that in terms of a communication process, trust has nothing to do with feelings or emotions. Trust is qualified reliance on information, based on factors independent of that information. In short, trust needs multiple, independent channels to be communicated. Trust cannot be induced by self-assertions -- like, trust me! or trust Pd! More precisely, Trust is that which is essential to a communication channel but cannot be transferred using that channel. Please see the topic Trust Points by myself in Digital Certificates: Applied Internet Security by Jalal Feghhi, Jalil Feghhi and Peter Williams, Addison-Wesley, ISBN 0-20-130980-7, pages 194-195, 1998. That said, the option of being *able* to define your own signatures on what you decide to trust does not preclude you from deciding to rely on someone else's signature. BTW, this has been used for some time with a hardened version of Netscape, where the browser does not use *any* root CA cert unless you sign it first. Thanks for your nice comment ;-) Ed Gerck Peter wrote: I disagree with your first sentence (I believe that Pd must be trustworthy for *the user*), but I like much of the rest of the first paragraph. I am not sure what value my mother would find in defining her own signatures. She doesn't know what they are, and would thus have no idea on who or what to trust without some help. What my mother might trust is some third party (for example she might trust Consumer's Union). We assumed we needed a structure which lets users delegate trust to people who understand it and who are investing in branding their take on the trustworthiness of a given thing (think UL label, Good Housekeepking Seal of Approval, etc.). I totally agree that some small segment of users will have an active interest in managing the trust on their machines directly (like, maybe, us) but any architecture that you want to be used by normal PC users needs to also let users delegate this managment to others who can manage it for users (just like we might decide to use others to manage our retirement funds, defend us in a court of law, or operate on our kidneys). To delegate trust, you need to start out trusting something to do that delegation. That's part of what Pd is addressing - Pd needs to be trustworthy enough so that when a user sets policy (eg don't run any SW in Pd which isn't signed by the EFF or don't run any SW which isn't debuggable), it is enforced. P - Original Message - From: Ed Gerck [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, September 17, 2002 2:51 PM Subject: Re: Cryptogram: Palladium Only for DRM It may be useful to start off with the observation that Palladium will not be the answer for a platform that *the user* can trust. However, Palladium should raise awareness on the issue of what a user can trust, and what not. Since a controling element has to lie outside the controled system, the solution for a trustworthy system is indeed an independent module with processing capability -- but which module the user should be able to control.. This may be a good, timely opening for a solution in terms of a write code approach, where an open source trustworthy (as opposed to trusted) secure execution module TSEM (e.g., based on a JVM with permission and access management) could be developed and -- possibly -- burned on a chip set for a low cost system. The TSEM would require user-defined signatures to define what is trustworthy to *the user*, which would set a higher bar for security when compared with someone else defining what is trustworthy to the user. The TSEM could be made tamper-evident, too. Note: This would not be in competition with NCipher's SEE, because NCipher's product is for the high-end market and involves commercial warranties, but NCipher's SEE module is IMO a good example. Comments? Ed Gerck - 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: Cryptogram: Palladium Only for DRM
Your last comment is still valid though: Palladium etc. will be more compelling if it demonstrably preserved the control by the owner of a device (e.g., by allowing the owner to initialize the root keys used by it, as pointed out by William Arbaugh). There is nothing in Pd which assumes that the keys weren't put there by a crazy hobbit named Mel who waves a magic wand on every system and then tattoos the keys on the users chest. Pd doesn't really know how the keys got there (how would it?). Pd wants a HW cert which it can show to others, who can then go to the signing authority for that cert and decide for themselves whether or not they trust that HW. Note that others can represent SW, remote users, local users, whatever... Some organizations will certainly want to gen their own keys. Some users will want to do this as well. The cost / benefit anaylsis involved in the way the keys got into the machine, how they are managed, and how they are preserved is up to a given market segment (where each segment happens to consist of thousands or millions of users). I believe that the chips in most Pd PC's will offer some relatively low bar for HW tamper resistance, will self-gen keys, and will manage those keys such that no one gets to know the private key and only third parties named by the user will ever see the public key. I think that this serves the widest set of needs. There may also be chips which squirt the keys out based on some event and there will almost certainly be ones which take keys squirted in from a remote source. Pd will run. Think about the graphics business - one vendor sells a decent percentage of silicon but there are other vendors who have been very succesful building products which sell into different segments based on different feature sets, and the same should hold true here. It is up to the makers of chips and users to decide how they want to assert the trustworthiness of a given system, and it is up to application writers to decide how they want to operate on that machine based on the certs they are given by Pd. re: smart cards - I agree, as a user I want the added protections I will get from a combination of a smart card and biometrics on top of Pd. I ultimately also want a mechanism I can use to ask an anonymous machine if I can trust it, and a combined smart-card / bioemtirc device doing an authentication with a Pd machine should let me do that. P - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 17, 2002 10:54 AM Subject: Re: Cryptogram: Palladium Only for DRM David Wagner wrote: I wasn't thinking of pure software solutions. I was thinking of a combination of existing hardware + new software: use the MMU to provide separate address spaces, and use a secure VM or OS kernel to limit what those processes can do. As far as I can see, this can provide just as much protection against viruses for your bank account as Palladium can. I agree with this in general. One exception that comes to mind is theft protection. If my machine has some secrets (e.g., to access my bank account) and a thief gets hold of the device physically (so that he can access the storage directly without the control of the OS), then MMU+software isn't enough. It seems some sort of smartcard (or support from a server) would be needed. The same applies to any data on my machine that should be integrity-protected (e.g., the root key with which I authenticate my bank). In general, with software and existing hardware working together, I suspect we can already do everything Palladium can do, except for the DRM and related applications founded on taking control away from the owner of the machine. Maybe I'm missing something. Still, it seems to me that Palladium would much more compelling if it left out the tamper-resistant chip and gave up on the semi-coercive DRM-like applications. I think tamper-resistant hardware could (if it worked) offer protection to the owner of the machine against anyone else who would have physical access to the machine. In other words, Owner is not the same as the current user. Your last comment is still valid though: Palladium etc. will be more compelling if it demonstrably preserved the control by the owner of a device (e.g., by allowing the owner to initialize the root keys used by it, as pointed out by William Arbaugh). Regards, - Asokan - 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: Cryptogram: Palladium Only for DRM
Hi Pete - I'm confused. Are you suggesting that I should enjoy these freedoms on SW which I don't have legal rights to? If not, then I don't see how any of these freedoms are affected by Pd. If you are suggesting that *all* SW should be made free, well that has nothing to do with Pd, does it? P - Original Message - From: Pete Chown [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 17, 2002 4:16 AM Subject: Re: Cryptogram: Palladium Only for DRM AARG!Anonymous wrote: In addition, I have argued that trusted computing in general will work very well with open source software. It may even be possible to allow the user to build the executable himself using a standard compilation environment. This says it all. It may even be possible for you to keep a small subset of the freedoms you enjoy today. Have you seen Richard Stallman's introduction to free software? I'd be interested to know what you think of each of the freedoms and whether you think they are available under Palladium/TCPA: http://www.gnu.org/philosophy/free-sw.html (Some of the freedoms are unaffected, of course.) -- Pete - 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: Cryptogram: Palladium Only for DRM
On Wed, 18 Sep 2002, Peter wrote: Hi Pete - I'm confused. Are you suggesting that I should enjoy these freedoms on SW which I don't have legal rights to? In emergencies, yes. Remember the people trying to deal with and organize the WTC rescue efforts, whose software kept rebelling because of inappropriately-enforced license issues? Care to even estimate the liability for lives lost due to that? You want to create a system where they'd have *NO* way to override copyright in a real emergency, *NO* way to save lives? No. That's cut and dried, because Copyright is never an emergency. Copyright infraction never costs lives. I for one don't give a flaming shit whether someone has the legal rights to equipment he has to use in an emergency to save lives. When putting automatic enforcement in place means that lives will be lost, it is a Bad Idea. A company that did it might (and IMO should) be held liable in court. Furthermore, if you think that Pd will only be used for legal purposes by the software vendors and manufacturers who control it, I strongly suggest you revise your trust model I have seen no indication anywhere that these people are any more trustworthy than those whose actions you decry. The only difference is that the scale of abuses which can be perpetrated by them is staggeringly large compared to the minor abuse of someone copying a song or running a program out of license. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
Relevence to the Pd debate is that banks may in future insist on remote attestation of users' software (however practically possible that is) so that they can attempt to dump yet more liability on their users (Ladies and gentlemen of the jury, Mr Doe's claim that he did not authorise this transfer to a Caribbean account is obviously fraudulent as his Fritz chip proved to us that his system had not been compromised...) Banks typically aren't that sophisticated. Demand for this capability probably will not materialize in time to save Pd, although there are probably people working for banks who will claim that they want it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptogram: Palladium Only for DRM
It takes a lot for me to get cranky around here, but I'm afraid Aarg! has done it. AARG!Anonymous [EMAIL PROTECTED] writes: Perry Metzger writes: Why not simply design the OS so it is not a likely victim for viruses? This is a general security problem, not one special to banking operations. That's a great idea. I don't know why nobody thought of that before. You conveniently cut what I said selectively, sarcastically replying to only pieces of it. You completely ignored much of the substance, such as the fact that in a correctly operating OS, MMUs+file permissions do more or less stop processes from seeing each others data if the OS functions correctly. So, to summarize, you ignored most of what I said, but managed to be incredibly rude. I've noticed you doing the same to lots of others. Here's a strong suggestion for the future, Anonymous. Never anger the moderator of a moderated mailing list. You can be the agent provocateur all day long, but you can't be snide and unresponsive. I'm going to ask that you go back and respond to my message without being insulting and without being selective about what sections you quote. If you want another copy, well, I don't know how to send it to you -- I can only hope you saved it. Until then, I'm not forwarding your mail. If you want to play your game here, you're going to have to do it politely and reasonably. Sorry for doing this in public but I have no other way of communicating with you. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptogram: Palladium Only for DRM
Niels Ferguson [EMAIL PROTECTED] writes: At 16:04 16/09/02 -0700, AARG! Anonymous wrote: Nothing done purely in software will be as effective as what can be done when you have secure hardware as the foundation. I discuss this in more detail below. But I am not suggesting to do it purely in software. Read the Intel manuals for their CPUs. There are loads of CPU features for process separation, securing the operating system, etc. The hardware is all there! There was a rather nice paper at Usenix Security 2000 on this [pause] available from http://www.usenix.org/publications/library/proceedings/sec2000/robin.html Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptogram: Palladium Only for DRM
AARG!Anonymous wrote: David Wagner writes: Standard process separation, sandboxes, jails, virtual machines, or other forms of restricted execution environments would suffice to solve this problem. Nothing done purely in software will be as effective as what can be done when you have secure hardware as the foundation. I wasn't thinking of pure software solutions. I was thinking of a combination of existing hardware + new software: use the MMU to provide separate address spaces, and use a secure VM or OS kernel to limit what those processes can do. As far as I can see, this can provide just as much protection against viruses for your bank account as Palladium can. In general, with software and existing hardware working together, I suspect we can already do everything Palladium can do, except for the DRM and related applications founded on taking control away from the owner of the machine. Maybe I'm missing something. Still, it seems to me that Palladium would much more compelling if it left out the tamper-resistant chip and gave up on the semi-coercive DRM-like applications. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptogram: Palladium Only for DRM
At 16:00 17/09/02 +1200, Peter Gutmann wrote: But I am not suggesting to do it purely in software. Read the Intel manuals for their CPUs. There are loads of CPU features for process separation, securing the operating system, etc. The hardware is all there! There was a rather nice paper at Usenix Security 2000 on this [pause] available from http://www.usenix.org/publications/library/proceedings/sec2000/robin.html Thanks, Peter, for a nice reference. That paper points out that the Pentium doesn't make it easy to create a virtual machine that is perfectly transparent, i.e. that the OS inside the VM cannot detect the VM at all. I don't think that is the current concern, as the OS and secure kernel are being developed by the same company. I'm sure the secure kernel is significantly easier to develop if you can make some small changes to the OS code, but even without this VMware shows that it can be done without any help of the OS. Niels == Niels Ferguson, [EMAIL PROTECTED], phone: +31 20 463 0977 PGP: 3EC2 3304 9B6E 27D9 72E7 E545 C1E0 5D7E - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptogram: Palladium Only for DRM
At 11:02 PM -0700 9/16/02, David Wagner wrote: AARG!Anonymous wrote: David Wagner writes: Standard process separation, sandboxes, jails, virtual machines, or other forms of restricted execution environments would suffice to solve this problem. Nothing done purely in software will be as effective as what can be done when you have secure hardware as the foundation. I wasn't thinking of pure software solutions. I was thinking of a combination of existing hardware + new software: use the MMU to provide separate address spaces, and use a secure VM or OS kernel to limit what those processes can do. As far as I can see, this can provide just as much protection against viruses for your bank account as Palladium can. The KeyKOS work http://www.cis.upenn.edu/%7EKeyKOS/ shows an approach to using existing hardware protection (in the case of KeyKOS, the protection available in the IBM 370 hardware) to building a system that is very resistant to Trojan horses and Virii. A very closely related open source OS is Eros http://www.eros-os.org/. Use of these technologies is illustrated by A Security Analysis of the Combex DarpaBrowser Architecure by David Wagner Dean Tribble http://www.combex.com/papers/darpa-review/index.html and a presentation at the O'Reilly Emerging Technology Conference, The E Development Platform: Exploiting Virus-Ridden Software http://conferences.oreillynet.com/cs/et2002/view/e_sess/2223. Cheers - Bil - Bill Frantz | The principal effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave. [EMAIL PROTECTED] | fair use. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptogram: Palladium Only for DRM
David Wagner wrote: I wasn't thinking of pure software solutions. I was thinking of a combination of existing hardware + new software: use the MMU to provide separate address spaces, and use a secure VM or OS kernel to limit what those processes can do. As far as I can see, this can provide just as much protection against viruses for your bank account as Palladium can. I agree with this in general. One exception that comes to mind is theft protection. If my machine has some secrets (e.g., to access my bank account) and a thief gets hold of the device physically (so that he can access the storage directly without the control of the OS), then MMU+software isn't enough. It seems some sort of smartcard (or support from a server) would be needed. The same applies to any data on my machine that should be integrity-protected (e.g., the root key with which I authenticate my bank). In general, with software and existing hardware working together, I suspect we can already do everything Palladium can do, except for the DRM and related applications founded on taking control away from the owner of the machine. Maybe I'm missing something. Still, it seems to me that Palladium would much more compelling if it left out the tamper-resistant chip and gave up on the semi-coercive DRM-like applications. I think tamper-resistant hardware could (if it worked) offer protection to the owner of the machine against anyone else who would have physical access to the machine. In other words, Owner is not the same as the current user. Your last comment is still valid though: Palladium etc. will be more compelling if it demonstrably preserved the control by the owner of a device (e.g., by allowing the owner to initialize the root keys used by it, as pointed out by William Arbaugh). Regards, - Asokan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Cryptogram: Palladium Only for DRM
Niels Ferguson[SMTP:[EMAIL PROTECTED]] wrote: Well, I'm tired of this. AARG, or whoever is hiding behind this pseudonym, is obviously not reading the responses that I send, as he keeps asking questions I already answered. I'm not going to waste more of my time responding to this. This is my last post in this thread. Have Fun! Niels Of course, this is just what AARG wants - he has never actually been interested in trying to persuade you. He just wants to wear down the people who are able to effectively dispute his claims to the point where they shut up, abandon the field of battle, and leave his position trimphant by default. He doesn't care about the truth, or whether you have shown him to be false. He just wants to win. Peter Trei - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Cryptogram: Palladium Only for DRM
It may be useful to start off with the observation that Palladium will not be the answer for a platform that *the user* can trust. However, Palladium should raise awareness on the issue of what a user can trust, and what not. Since a controling element has to lie outside the controled system, the solution for a trustworthy system is indeed an independent module with processing capability -- but which module the user should be able to control.. This may be a good, timely opening for a solution in terms of a write code approach, where an open source trustworthy (as opposed to trusted) secure execution module TSEM (e.g., based on a JVM with permission and access management) could be developed and -- possibly -- burned on a chip set for a low cost system. The TSEM would require user-defined signatures to define what is trustworthy to *the user*, which would set a higher bar for security when compared with someone else defining what is trustworthy to the user. The TSEM could be made tamper-evident, too. Note: This would not be in competition with NCipher's SEE, because NCipher's product is for the high-end market and involves commercial warranties, but NCipher's SEE module is IMO a good example. Comments? Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
At 01:07 PM 9/17/2002 -0700, [EMAIL PROTECTED] wrote: As far as I know, banks assume that a certain percentage of their transactions will be bad and build that cost into their business model. Credit and ATM cards and numbers are as far from secure as could be, far less secure than somebody doing online transactions from a Wintel machine on an unencrypted connection, let alone an encrypted one. Until somebody takes full advantage of the current system and steals a few trillion dollars in one day, the problems are easier to deal with than a solution. Until that happens, there's no reason for banks to go through the pain of dealing with or requiring Pd. -Jon Simon note that EU finread standard attempted to address some of this. an external (secure, finread) token acceptor device with secure display and secure pin entry. The hardware token is used to sign the (financial) transaction PIN code is entered into the finread device and goes directly to the hardware token (w/o passing thru the PC). Critical pieces of the transactions passes thru the finread device on the way to the (signing hardware token) and is displayed on the secure display ... which then requires the PIN to be entered to confirm the transaction. There is the issue of 3-factor authentication * something you have (hardware token) * something you know (pin) * something you are (biometrics in addition to /or in place of PIN) besides the straight-forward use of signatures to authenticate the source of the transaction ... there is the nominal legal requirement associated with physical signatures ... i.e. did you intend to sign what you signed aka is what you see what you signed ... and do you confirm that you actually want the hardware token to sign what you see. A lot of digital signature seems to address the technology part of authentication ... and then sometimes (just because the term signature is used as part of the description of the technical procedure) that all technical implementations of the process referred to as digital signature is legally equivalent to physical signatures (even when no aspects of intention have been satisfied). random past finread intention posts: http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key http://www.garlic.com/~lynn/aadsm11.htm#4 AW: Digital signatures as proof http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#6 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#7 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#9 Meaning of Non-repudiation http://www.garlic.com/~lynn/aadsm11.htm#13 Words, Books, and Key Usage http://www.garlic.com/~lynn/aadsm11.htm#23 Proxy PKI. Was: IBM alternative to PKI? http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA) http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA) http://www.garlic.com/~lynn/2000.html#0 2000 = millennium? http://www.garlic.com/~lynn/2000.html#94 Those who do not learn from history... http://www.garlic.com/~lynn/2000f.html#79 Cryptogram Newsletter is off the wall? http://www.garlic.com/~lynn/2001f.html#39 Ancient computer humor - DEC WARS http://www.garlic.com/~lynn/2001g.html#57 Q: Internet banking http://www.garlic.com/~lynn/2001g.html#60 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001h.html#51 future of e-commerce http://www.garlic.com/~lynn/2001i.html#25 Net banking, is it safe??? http://www.garlic.com/~lynn/2001i.html#26 No Trusted Viewer possible? http://www.garlic.com/~lynn/2001j.html#7 No Trusted Viewer possible? http://www.garlic.com/~lynn/2001j.html#46 Big black helicopters http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really secure? http://www.garlic.com/~lynn/2001k.html#43 Why is UNIX semi-immune to viral infection? http://www.garlic.com/~lynn/2001m.html#6 Smart Card vs. Magnetic Strip Market http://www.garlic.com/~lynn/2001m.html#9 Smart Card vs. Magnetic Strip Market http://www.garlic.com/~lynn/2001n.html#70 CM-5 Thinking Machines, Supercomputers http://www.garlic.com/~lynn/2002c.html#10 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002c.html#21 Opinion on smartcard security requested http://www.garlic.com/~lynn/2002f.html#46 Security Issues of using Internet Banking http://www.garlic.com/~lynn/2002f.html#55 Security Issues of using Internet Banking http://www.garlic.com/~lynn/2002g.html#69 Digital signature http://www.garlic.com/~lynn/2002h.html#13 Biometric authentication for intranet websites? http://www.garlic.com/~lynn/2002l.html#24 Two
Re: Cryptogram: Palladium Only for DRM
At 06:02 AM 9/17/2002 +, David Wagner wrote: I wasn't thinking of pure software solutions. I was thinking of a combination of existing hardware + new software: use the MMU to provide separate address spaces, and use a secure VM or OS kernel to limit what those processes can do. As far as I can see, this can provide just as much protection against viruses for your bank account as Palladium can. In general, with software and existing hardware working together, I suspect we can already do everything Palladium can do, except for the DRM and related applications founded on taking control away from the owner of the machine. Maybe I'm missing something. Still, it seems to me that Palladium would much more compelling if it left out the tamper-resistant chip and gave up on the semi-coercive DRM-like applications. couple refs to multics study http://www.garlic.com/~lynn/2002m.html#8 Backdoor in AES ? http://www.garlic.com/~lynn/2002m.html#10 Backdoor in AES ? -- Anne Lynn Wheeler [EMAIL PROTECTED], http://www.garlic.com/~lynn/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
At 1:07 PM -0700 on 9/17/02, [EMAIL PROTECTED] wrote: As far as I know, banks assume that a certain percentage of their transactions will be bad and build that cost into their business model. Credit and ATM cards and numbers are as far from secure as could be, far less secure than somebody doing online transactions from a Wintel machine on an unencrypted connection, let alone an encrypted one. Until somebody takes full advantage of the current system and steals a few trillion dollars in one day, the problems are easier to deal with than a solution. Until that happens, there's no reason for banks to go through the pain of dealing with or requiring Pd. I wouldn't go that far. While Pd. -- and a certain long-term ejaculative (look it up...) denizen of my kill-file -- is pretty much a disingenuous shuck, greed is an amazing thing. The lowest cost producer of anything, transactions, say, will not only make more money than its competitors, but they will also *survive* longer than anyone else. To quote, um, Stalin, quantity has a quality all its own. So, if strong financial cryptography gives us the lowest *risk-adjusted* cost per transaction by some very large amount, the market will adopt it just as quickly as if confronted with a threat that only strong cryptography can remedy. As software (in the http://www.nobel.se/economics/laureates/1992/ Gary Becker sense, things that can be more or less perfectly copied) and wetware (valuable opinion, for lack of a better word) become more important compared to hardware (stuff, discovered, extracted, or built), the more valuable strong, secure, (geodesic :-)) networks and (bearer :-)) financial cryptography becomes. Cheers, RAH -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
