Re: Why is RMAC resistant to birthday attacks?
On Mon, 21 Oct 2002, Aram Perez wrote: [EMAIL PROTECTED] wrote: While you are correct in the general case, I have worked on a system where Alice could only generate MACs and Bob could only verify MACs. The hardware was designed so that Alice could not verify MACs and Bob could not generate MACs even though they shared the same key (that was only known to the hardware). This is interesting, but it does not help me to understand what threat model is addressed RMAC, or more generally how do birthday attacks play out against (shared secret) keyed MAC algorithms. The details of the RMAC algorithm itselft are not at issue here, I want to understand the problem so I can use the solution under the right conditions. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
On Tue, 22 Oct 2002, Ed Gerck wrote: Short answer: Because the MAC tag is doubled in size. Longer answer: The birthday paradox says that if the MAC tag has t bits, only 2^(t/2) queries to the MAC oracle are likely needed in order to discover two messages with the same tag, i.e., a collision, from which forgeries could easily be constructed. This is a point I don't think I quite get. Suppose that I have a MAC oracle and I bounce 2^32 messages off of it. With a 64-bit MAC, the odds are about even that two of those messages will come back with the same MAC. But why does that buy me the ability to easily make a forgery? Does it mean I can then create a bogus message, which the oracle has never seen, and generate a MAC that checks for it? If so how? In protocol terms, let's say Alice is a digital notary. Documents come in, and Alice attests to their existence on a particular date by adding a datestamp, affixing a keyed MAC, and sending them back. Now Bob sends Alice 2^32 messages (and Alice's key-management software totally doesn't notice that the key has been worn to a nub and prompt her to revoke it). Reviewing his files, Bob finds that he has a January 21 document and a September 30 document which have the same MAC. What does Bob do now? How does this get Bob the ability to create something Alice didn't sign, but which has a valid MAC from Alice's key? Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Palladium -- trivially weak in hw but secure in software?? (Re: palladium presentation - anyone going?)
Adam Back says: Providing almost no hardware defenses while going to extra-ordinary efforts to provide top notch software defenses doesn't make sense if the machine owner is a threat. So maybe the Palladium folks really mean it when they say the purpose of Palladium is not to enable DRM? I doubt it, though. Even a paper-thin shred of hardware protection is enough to prevent 99% of the people from circumventing DRM technology. Joe Sixpack isn't going to install a mod chip, and his local computer store can't do it for him for fear of prosecution for circumventing copyright protection. If the appliance enforces DRM when you buy it, that's good enough to guarantee revenue to the copyright holders. In the US, at least. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
On Tue, Oct 22, 2002 at 11:09:41AM -0700, bear wrote: Now Bob sends Alice 2^32 messages (and Alice's key-management software totally doesn't notice that the key has been worn to a nub and prompt her to revoke it). Reviewing his files, Bob finds that he has a January 21 document and a September 30 document which have the same MAC. What does Bob do now? How does this get Bob the ability to create something Alice didn't sign, but which has a valid MAC from Alice's key? Call the Jan 21 document x, and the Sept 30 document y. Now Bob knows MAC_Alice(x | z) = MAC_Alice(y | z) for all z, because the internal states of the MAC after processing x and y are the same and therefore will remain equal given identical suffixes. So he can get a MAC on x | z and it's also a valid MAC for y | z, which Alice didn't sign. This applies for CBC-MAC, DMAC, HMAC, and any another MAC that is not randomized or maintains state (for example a counter) from message to message. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
bear wrote: On Tue, 22 Oct 2002, Ed Gerck wrote: Short answer: Because the MAC tag is doubled in size. Longer answer: The birthday paradox says that if the MAC tag has t bits, only 2^(t/2) queries to the MAC oracle are likely needed in order to discover two messages with the same tag, i.e., a collision, from which forgeries could easily be constructed. This is a point I don't think I quite get. Suppose that I have a MAC oracle and I bounce 2^32 messages off of it. With a 64-bit MAC, the odds are about even that two of those messages will come back with the same MAC. But why does that buy me the ability to easily make a forgery? ;-) please note that you already have one forgery... BTW, it is important to look at the size of the internal chaining variable. If it is 128-bit, this means that attacks with a 2^128 burden would likely work. However, if only a subset of the MAC tag is used OR if the message to be hashed has a fixed length defined by the issuer, this is not relevant. Only one of these conditions are needed. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
On Tue, 22 Oct 2002, Ed Gerck wrote: Short answer: Because the MAC tag is doubled in size. I know, but this is not my question. Longer answer: The birthday paradox says that if the MAC tag has t bits, only 2^(t/2) queries to the MAC oracle are likely needed in order to discover two messages with the same tag, i.e., a collision, from which forgeries could easily be constructed. So the threat model assumes that there is a MAC oracle. What is a practical realization of such an oracle? Does Eve simply wait for (or entice) Alice to send enough (intercepted) messages to Bob? Are there any other birthday attack scenarios for keyed MAC? In many applications the collection sufficiently many messages between Alice and Bob is simply out of the question. In such cases if Eve cannot mount the attack independently and cannot collect 2^(n/2) messages from Alice to Bob, presumably RMAC does not offer an advantage over any other keyed MAC. I am not confused by the RMAC algorithm or so the associated work factor estimates, I want to understand the assumptions (threat models) behind the work factor estimates. Does the above look right? -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
Ed Gerck [EMAIL PROTECTED] It does to (as you can read in the paper). BTW, the easily applies to the case WITHOUT salt Well, to be really pedantic the paper never says that it is easy only that it has a work factor of the square root of the number of possible MAC strings without salt, and that adding the salt multiplies that by the square root of the possible number of salt values. That attack scenario certainly doesn't look easy to me :-). And as long as I'm being pedantic I'll point out my own mistake in my last message of using 'k' as the variable for block size (MAC length) instead of 'b' as in the paper. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
[EMAIL PROTECTED] wrote: On Tue, 22 Oct 2002, Ed Gerck wrote: Short answer: Because the MAC tag is doubled in size. I know, but this is not my question. ;-) your question was Why is RMAC resistant to birthday attacks? Longer answer: The birthday paradox says that if the MAC tag has t bits, only 2^(t/2) queries to the MAC oracle are likely needed in order to discover two messages with the same tag, i.e., a collision, from which forgeries could easily be constructed. So the threat model assumes that there is a MAC oracle. What is a practical realization of such an oracle? Does Eve simply wait for (or entice) Alice to send enough (intercepted) messages to Bob? Eve may just watch traffic that comes into her company's servers, knowing the back-end plain text messages. No need to watch external networks. Eve may also be, for example, one of those third-party monitoring services that monitor traffic inside enterprise's networks for the purpose of assuring security. Are there any other birthday attack scenarios for keyed MAC? A birthday attack requires 2^(t/2) values, which looks surprising low -- hence the name paradox (btw, this attack provides the mathematical model behind the game of finding people with same birthday in a party, which works for a surprisingly low number of people). If you can get 2^(t/2) values, the attack works. In many applications the collection sufficiently many messages between Alice and Bob is simply out of the question. In such cases if Eve cannot mount the attack independently and cannot collect 2^(n/2) messages from Alice to Bob, presumably RMAC does not offer an advantage over any other keyed MAC. In an Internet message, datagrams can be inserted, dropped, duplicated, tampered with or delivered out of order at the network layer (and often at the link layer). TCP implements a reliable transport mechanism and copes with the datagram unreliability at the lower layers. However, TCP is unable to cope with a fraudulent datagram that is crafted to pass TCP's protocol checks and is inserted into the datagram stream. That datagram will be accepted by TCP and passed on to higher layers. A cryptographic system operating below TCP is needed to avoid this attack and filter out the deviant datagrams -- and that's where you would use a MAC, if you want to protect each datagram. It's not difficult, thus, to have more than 2^32 MACs in one message or in a series of messages. This is a scenario where it is not so difficult for an attacker to forge an acceptable MAC for a datagram that was not sent in a given sequence, possibly tampering with the upper-layer message and also making it more vulnerable to denial-of-service attacks. Note that having a MAC above TCP does not prevent this attack, even though it can detect it (and thus lead to a denial-of-service). I am not confused by the RMAC algorithm or so the associated work factor estimates, I want to understand the assumptions (threat models) behind the work factor estimates. Does the above look right? If birthday attack is a concern, RMAC is helpful. If not, then not. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
On Tue, Oct 22, 2002 at 12:31:47PM -0700, Ed Gerck wrote: My earlier comment to bear applies here as well -- this attack can be avoided if only a subset of the MAC tag is used I can't seem to find your earlier comment. It probably hasn't gone through the mailing list yet. I don't see how the attack is avoided if only a substring of the MAC tag is used. (I assume you mean substring above instead of subset.) The attacker just needs to find messages x and y such that the truncated MAC tags of x|0, x|1, ..., x|n, matches those of y|0, y|1, ..., y|n, and this will tell him that there is an internal collision between x and y. n only has to be large enough so that the total length of the truncated MAC tags is greater than the size of the internal state of the MAC. OR if the message to be hashed has a fixed length defined by the issuer. Only one of these conditions are needed. No I don't think that works either. The attacker can try to find messages x and y such that MAC(x|0^n) = MAC(y|0^n) (where 0^n denotes enough zeros to pad the messages up to the fixed length). Then there is a good chance that the internal collision occured before the 0's and so MAC(x|z) = MAC(y|z) for all z of length n. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
[EMAIL PROTECTED] I want to understand the assumptions (threat models) behind the work factor estimates. Does the above look right? I just realized something about the salt in the RMAC algorithm, although it may have been obvious to everyone else: RMAC is equivalent to a HMAC hash-based MAC algorithm, but using a block cipher. The paper states that it is for use instead of HMAC iin circumstances where for some reason it is easier to use a block cipher than a cryptographic hash. The security of HMAC against attacks based on collisions is measured as a function of the bit length of the hash. Using a block cipher in CBC mode makes it in effect a b bit hash, where b is the block length of the cipher. In many cases the block length of a cipher being 64 or 128 bits will be too small by itself. Hence the need to add r bits from the salt and the need to write up explicitly how RMAC handles collision based attacks and how the salt affects that. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
Wei Dai wrote: On Tue, Oct 22, 2002 at 12:31:47PM -0700, Ed Gerck wrote: My earlier comment to bear applies here as well -- this attack can be avoided if only a subset of the MAC tag is used I can't seem to find your earlier comment. It probably hasn't gone through the mailing list yet. I don't see how the attack is avoided if only a substring of the MAC tag is used. (I assume you mean substring above instead of subset.) Yes, subset -- not a string with less N characters at the end. For example, you can calculate the P subset as MAC mod P, for P smaller than 2^(bits in the MAC tag). The attacker just needs to find messages x and y such that the truncated MAC tags of x|0, x|1, ..., x|n, matches those of y|0, y|1, ..., y|n, and this will tell him that there is an internal collision between x and y. No. The attacker gets A and B, and sees that A = B. This does not mean that a=b in A = a mod P and B = b mod P. The internal states are possibly different even though the values seen by the attacker are the same. n only has to be large enough so that the total length of the truncated MAC tags is greater than the size of the internal state of the MAC. OR if the message to be hashed has a fixed length defined by the issuer. Only one of these conditions are needed. No I don't think that works either. The attacker can try to find messages x and y such that MAC(x|0^n) = MAC(y|0^n) (where 0^n denotes enough zeros to pad the messages up to the fixed length). Then there is a good chance that the internal collision occured before the 0's and so MAC(x|z) = MAC(y|z) for all z of length n. Why do you think there is a good chance? Note that all messages for which you can get a MAC have some fixed message length M. The attacker cannot leverage a MAC value to calculate the state of a M+1 length message -- exactly because this is prevented by making all messages have length M. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
comparing RMAC to AES+CBC-MAC or XCBC (Re: Why is RMAC resistant to birthday attacks?)
But the salt doesn't increase the MAC length. It just frustrates attempts to collect message+MAC pairs to find a collision. Think of it like a salt on unix passwords. You can still brute force one particular target in the same time, but the salt reduces your scope for pre-computation. There is still probability 1/2^m of finding a collision given two random messages, whether the salt has size 0 or 64. Note that the salt is optional. They list parameter sets I through V. Parameter sets II through V are considered safe for general use. Parameter set II has salt size 0. Parameter set I is considered only safe for applications where only a limited number of messages could be sent. This is more a function of the small MAC size (32 bits) I think than the fact that the salt size is 0 for parameter set I. I would have thought that unless the keys can essentially never change (for example burnt into hardware) the salt option is of limited practical use. The choice of parameter sets is a bit odd. For example there are no 0 size salts for MAC outputs over 64 bits, while there is for the smaller MAC outputs, and yet you would think the smaller MAC outputs are more in need of the salt as finding a collision is more realistically achievable. Collecting 2^64 messages (for parameter set V) seems already quite theoretical for many applications without adding a 128 bit salt. Yet collecting 2^32 messages (parameter set II) seems much more plausible and yet there is no salt defined at that parameter set. Given the definition of the parameter sets I suspect people will interpret the standard as that they must use one of the listed parameter sets and can't use their own. At least most implementations will tend to do that. Would it not be simpler to just do away with the salt and parameter sets and describe the collision problem and note that minimally K2 should be changed (however the application may decide to arrange this) frequently enough to avoid a non-neglible risk of collisions being obtainable to attacker. If the salt is removed / ignored, RMAC is essentially the same as CBC-MAC but just defined for use with AES (rather than just DES), so providing more security due to larger block size (and key size). The one difference which is an incremental improvement over raw CBC-MAC is that the final CBC-MAC a-like output is encrypted with the 2nd key K3. (K3 defined as K2 xor salt, K2 an independent key). However for example Rogaway and Black's XCBC is simpler, more efficient (not requiring a key schedule for each salt-change) and equally deals with variable length messages). http://csrc.nist.gov/encryption/modes/proposedmodes/xcbc-mac/xcbc-mac-spec.pdf The protection against collisions is of limited practical value, and I think better left out of the standard. Adam On Tue, Oct 22, 2002 at 01:52:18PM -0700, Sidney Markowitz wrote: [EMAIL PROTECTED] I want to understand the assumptions (threat models) behind the work factor estimates. Does the above look right? I just realized something about the salt in the RMAC algorithm, although it may have been obvious to everyone else: RMAC is equivalent to a HMAC hash-based MAC algorithm, but using a block cipher. The paper states that it is for use instead of HMAC iin circumstances where for some reason it is easier to use a block cipher than a cryptographic hash. The security of HMAC against attacks based on collisions is measured as a function of the bit length of the hash. Using a block cipher in CBC mode makes it in effect a b bit hash, where b is the block length of the cipher. In many cases the block length of a cipher being 64 or 128 bits will be too small by itself. Hence the need to add r bits from the salt and the need to write up explicitly how RMAC handles collision based attacks and how the salt affects that. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
Sidney Markowitz wrote: [EMAIL PROTECTED] I want to understand the assumptions (threat models) behind the work factor estimates. Does the above look right? I just realized something about the salt in the RMAC algorithm, although it may have been obvious to everyone else: RMAC is equivalent to a HMAC hash-based MAC algorithm, but using a block cipher. No -- these are all independent things. One can build an RMAC wih SHA-1. An RMAC does not have to use an HMAC scheme. One can also have an HMAC hash-based MAC algorithm using a block cipher, that is not an RMAC. The paper states that it is for use instead of HMAC iin circumstances where for some reason it is easier to use a block cipher than a cryptographic hash. That's is not the reason it was devised. The reason is to prevent a birthday attack for 2^(t/2) tries on a MAC using a t-bit key. Needless to say, it also makes harder to try a brute force attack. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
Ed Gerck [EMAIL PROTECTED] said: No -- these are all independent things. One can build an RMAC wih SHA-1. An RMAC does not have to use an HMAC scheme. One can also have an HMAC hash-based MAC algorithm using a block cipher, that is not an RMAC. Some quotes from the paper: This paper defines an authentication mode of operation, called RMAC, for a symmetric key block cipher algorithm The definition of RMAC in the table of defnintions: The name of the authentication mode that is specified in this Recommendation In particular, RMAC is an algorithm for generating a message authentication code (MAC) from the data to be authenticated and from an associated value called a salt, using a block cipher and two secret keys [...] Fips Pub 198 specified a different MAC algorithm, called HMAC, that is also appropriate for protection of sensitive data. Because HMAC is constructed from a hash function rather than a block cipher algorithm, RMAC may be preferable for application environments in which an approved block cipher is more convenient to implement than an approved hash function. The paper states that it is for use instead of HMAC iin circumstances where for some reason it is easier to use a block cipher than a cryptographic hash. That's is not the reason it was devised. The reason is to prevent a birthday attack for 2^(t/2) tries on a MAC using a t-bit key. Needless to say, it also makes harder to try a brute force attack. RMAC was devised for the reason I stated, as it says in the last quote from the paper above. The salt is there to make the cost of the extension forgery attack more expensive because the birthday surprise shows that just the number of bits in the cipher block may not make it expensive enough without a salt. The key size is not relevant to the birthday attack (actually extension forgery attack) as shown in the table where the work factor expressed as a function of the block length and the salt length, not the key size. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
At 03:05 PM 10/22/2002 -0400, Wei Dai wrote: Call the Jan 21 document x, and the Sept 30 document y. Now Bob knows MAC_Alice(x | z) = MAC_Alice(y | z) for all z, because the internal states of the MAC after processing x and y are the same and therefore will remain equal given identical suffixes. So he can get a MAC on x | z and it's also a valid MAC for y | z, which Alice didn't sign. This applies for CBC-MAC, DMAC, HMAC, and any another MAC that is not randomized or maintains state (for example a counter) from message to message. A nit... this isn't *quite* true for HMAC; the collision could have been in the outer hash function evaluation, not the inner. I haven't yet looked at RMAC and don't know what DMAC is, so I can't comment on them. Still, the attack gives a 50% chance of forging an HMAC, so it's a valid attack. Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
Sidney Markowitz wrote: Ed Gerck [EMAIL PROTECTED] said: That's is not the reason it was devised. The reason is to prevent a birthday attack for 2^(t/2) tries on a MAC using a t-bit key. Needless to say, it also makes harder to try a brute force attack. RMAC was devised for the reason I stated, as it says in the last quote from the paper above. The salt is there to make the cost of the extension forgery attack more expensive because the birthday surprise shows that just the number of bits in the cipher block may not make it expensive enough without a salt. The key size is not relevant to the birthday attack (actually extension forgery attack) as shown in the table where the work factor expressed as a function of the block length and the salt length, not the key size. A minor nit, but sometimes looking into why things were devised is helpful. What I explained can be found in http://csrc.nist.gov/encryption/modes/workshop2/report.pdf and especially useful is the segment: The RMAC algorithm was a refinement of the DMAC algorithm in which a random bit string was exclusive-ORed into the second key and then appended to the resulting MAC to form the tag. The birthday paradox in principle was no longer relevant, for, say, the AES with 128 bit keys, because the tag would be doubled to 256 bits. Joux presented his underlying security model and the properties that he had proven for RMAC: the number of queries that bounded the chance of a forgery was relatively close to the number of 128 bit keys. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why is RMAC resistant to birthday attacks?
Ed Gerck [EMAIL PROTECTED] wrote: A minor nit, but sometimes looking into why things were devised is helpful. What I explained can be found in http://csrc.nist.gov/encryption/modes/workshop2/report.pdf Thank you, that was really helpful in seeing the motivation for the work that led to the NIST draft paper. The way I read it now, he includes a justification for block cipher based MACs in general, then presents his RMAC, which he devised to deal with the effect of the birthday surprise on the work factor of the forged extension attack on other block cipher based MACS. -- sidney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Palladium -- trivially weak in hw but secure in software?? (Re: palladium presentation - anyone going?)
Remote attestation does indeed require Palladium to be secure against the local user. However my point is while they seem to have done a good job of providing software security for the remote attestation function, it seems at this point that hardware security is laughable. So they disclaim in the talk announce that Palladium is not intended to be secure against hardware attacks: | Palladium is not designed to provide defenses against | hardware-based attacks that originate from someone in control of the | local machine. so one can't criticise the implementation of their threat model -- it indeed isn't secure against hardware based attacks. But I'm questioning the validity of the threat model as a realistic and sensible balance of practical security defenses. Providing almost no hardware defenses while going to extra-ordinary efforts to provide top notch software defenses doesn't make sense if the machine owner is a threat. The remote attestation function clearly is defined from the view that the owner is a threat. Without specifics and some knowledge of hardware hacking we can't quantify, but I suspect that hacking it would be pretty easy. Perhaps no soldering, $50 equipment and simple instructions anyone could follow. more inline below... On Mon, Oct 21, 2002 at 09:36:09PM -0400, Arnold G. Reinhold wrote: [about improving palladium hw security...] Memory expansion could be dealt with by finding a way to give Palladium preferred access to the first block of physical memory that is soldered on the mother board. I think standard memory could be used. I can think of simple processor modifications that could fix this problem with hardware tamper resistance assurance to the level of having to tamper with .13 micron processor. The processor is something that could be epoxyied inside a cartridge for example (with the cartridge design processor + L2 cache housings as used by some Intel pentium class processors), though probably having to tamper with a modern processor is plenty hard enough to match software security given software complexity issues. Adam -- http://www.cypherspace.net/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Palladium -- trivially weak in hw but secure in software?? (Re: palladium presentation - anyone going?)
On Tue, Oct 22, 2002 at 04:52:16PM +0100, Adam Back wrote: So they disclaim in the talk announce that Palladium is not intended to be secure against hardware attacks: | Palladium is not designed to provide defenses against | hardware-based attacks that originate from someone in control of the | local machine. so one can't criticise the implementation of their threat model -- it indeed isn't secure against hardware based attacks. But I'm questioning the validity of the threat model as a realistic and sensible balance of practical security defenses. Providing almost no hardware defenses while going to extra-ordinary efforts to provide top notch software defenses doesn't make sense if the machine owner is a threat. This depends. I would say this is an interesting threat model. It makes the attacks non-redistributable. Software-based attacks are redistributable. Once I write a program that hacks a computer, I can give that program to anyone to use. I can even give it to everyone, and then anyone could use it. The expertise necessary can be abstracted away into a program even my mother could use. Hardware-based attacks cannot be redistributed. If I figure out how to hack my system, I can post instructions on the web but it still requires techinical competence on your end if you want to hack your system too. While this doesn't help a whole lot for a DRM goal (once you get the non-DRM version of the media data, you can redistribute it all you want), it can be very useful for security. It can help to eliminate the 'script kiddie' style of attackers. Rick - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Palladium -- trivially weak in hw but secure in software??(Re: palladium presentation - anyone going?)
On Tue, 22 Oct 2002, Rick Wash wrote: Hardware-based attacks cannot be redistributed. If I figure out how to hack my system, I can post instructions on the web but it still requires techinical competence on your end if you want to hack your system too. While this doesn't help a whole lot for a DRM goal (once you get the non-DRM version of the media data, you can redistribute it all you want), it can be very useful for security. It can help to eliminate the 'script kiddie' style of attackers. Not really. It depends on what they are exploiting. Does every piece of code need to be validated all the time? Once a program is running, does something running in its code space get revalidated or soes it just run? I don't see how paladium stops buffer overflows or heap exploits or format bugs or any of the standard exploits that are in use today. (Not without crippling the entire system for bot the user and the programmer.) It seems to change little for script kiddies if the machines are going to communicate with other systems. (Unless the DRM holders will control who and how you can connect as well. And they just might do that as well...) The perveyors of this also claim it will stop spam and e-mail viruses. They only way it can do that is by making paladium based systems incompatable with every non-DRM machine on the planet. (So much for getting e-mail from your relatives!) The only problem this hardware seems to solve is shackling the user into what data they can see and use. If Microsoft follows their standard coding practices, the script kiddie problem will not go away with this technology. It will probably increase. And it will be illegal to effectivly stop them. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Palladium -- trivially weak in hw but secure in software??(Re: palladium presentation - anyone going?)
At 4:52 PM +0100 10/22/02, Adam Back wrote: Remote attestation does indeed require Palladium to be secure against the local user. However my point is while they seem to have done a good job of providing software security for the remote attestation function, it seems at this point that hardware security is laughable. I think the most important phrase above is at this point. Palladium is still being designed. I'd argue that the software/firmware portion is the trickiest to get right. It seems rational for Microsoft to let that design mature, then analyze the remaining hardware threats and turn the hardware engineers loose to try to plug them. Palladium has to be viewed in the larger context of a negotiation between Microsoft and Hollywood (I include here all the content owners: movie studios, recording industry, book publishers, etc. ). Hollywood would prefer a completely closed PC architecture, where consumers' use of the computer could be tightly monitored and controlled. They perceive general purpose computing as we know and love it to be a mortal threat to their continued existence. Keeping the content of DVDs and future media locked up is not enough in their eyes. They want all material displayed to be checked for watermarks and blocked or degraded if the PC owner hasn't paid for the content. Microsoft wants to preserve general purpose computing because it realizes that in a closed architecture, the OS would become a mere commodity component and the consumer electronics giants would eventually displace Microsoft. On the other hand, Microsoft needs Hollywood provide the kind of content that will drive PC sales and upgrades. The base line PC platform of today or even two years ago is powerful enough for most consumers and businesses. People are keeping their PCs longer and not upgrading them as often. Most everyone who wants a PC (at least in North America) already has one. Microsoft needs something new to drive sales. I expect Microsoft and Hollywood to haggle over the final specs for Palladium PCs and no doubt additional hardware protection measures will be included. The actual spec may well be kept secret, with NDA access only. Hollywood will hold two strong card at the table: its content and the threat of legislation. I'm sure Senator Hollings is watching developments closely. The big question in my mind is how to get PC consumers a place at the bargaining table. It seems to me that PC consumers have three tools: votes, wallets and technology. The Internet is well suited to political organizing. Remember the amount of mail generated by the modem tax hoax? Consumer boycotts are another powerful threat, given how powerful and upgradable existing computer already are. Technology can provide an alternative way to gain the benefits that will be touted for controlled computing. Anti-virus and anti-DDS techniques come to mind. Also, since I expect an eventual push to ban non-Palladium computers from the Internet, alternative networking technology will be important. The Palladium story is just beginning. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Palladium -- trivially weak in hw but secure in software?? (Re: palladium presentation - anyone going?)
Software-based attacks are redistributable. Once I write a program that hacks a computer, I can give that program to anyone to use. I can even give it to everyone, and then anyone could use it. The expertise necessary can be abstracted away into a program even my mother could use. Hardware-based attacks cannot be redistributed. If I figure out how to hack my system, I can post instructions on the web but it still requires technical competence on your end if you want to hack your system too. While this doesn't help a whole lot for a DRM goal (once you get the non-DRM version of the media data, you can redistribute it all you want). I think this assumption may be incorrect. In order for content providers to win the DRM fight it seems like they need to address two issues. First, put up a big enough barrier for most users that circumventing access controls is infeasible, or simply not worth it. Second, put up a big enough barrier for most users that gaining access to copies of media with the access controls removed is either infeasible, or simply not worth it. I believe tamper resistant hardware solves the first problem, even if, as Adam conjectures, all that is required to access media protected by Palladium is a $50 kit (which remember, you can't obtain legally) and some hardware hacking. This seems to rule out well over %99 of the media consuming public. The problem of obstructing the distribution of media is really a different topic. I think that solving this problem is easier than most folks think. Again, you don't have to totally stop it P2P, or that kid in the shopping mall selling copied CD's. All you have to do is put up big enough technical and legal barriers that the general public would rather just pay for the media. While it may be the case that Palladium is not a serious barrier to the average CS graduate student, Cypherpunk, or even the home user who has a modicum of hardware clue, I don't think this will kill it as an effective technology for supporting DRM, assuming that the software cannot be broken. --Tal - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
