Re: consulting question.... (DRM)
On May 29, 2009, at 8:48 AM, Peter Gutmann wrote: Jerry Leichter leich...@lrw.com writes: For the most part, software like this aims to keep reasonably honest people honest. Yes, they can probably hire someone to hack around the licensing software. (There's generally not much motivation for J Random User to break this stuff, since it protects business software with a specialized audience.) But is it (a) worth the cost; (b) worth the risk - if you get caught, there's clear evidence that you broke things deliberately. I think a far more important consideration for license-management software isn't how secure is it but how obnoxious is it for legitimate users? I know a number of people who have either themselves broken or downloaded tools to break FlexLM and similar schemes, and in every single case they were legitimate users who were prevented from using their legally purchased product by the license-mismanagement tools, or who after spending hours or even days fighting with the license-mismanagement software found it easier to break the protection than to try and figure out what contortions were required to keep the license- checking code happy I agree 100%. The most important thing to keep in mind when doing license management software is that it has *NO* value to the *customer*. The guys who sell this stuff will always claim that it helps the customer keep track of licenses or some such rot - but it's complete nonsense. In fact, license management code has *negative* customer value. That doesn't mean it doesn't have a legitimate role - the cash registers in the supermarket add a negative value to all the sold, but the supermarket wouldn't be there without them. But unless you understand, deep down, that this is something that you're imposing on your customer and that therefore it needs to be as close to invisible and fail-safe as possible; and you act *effectively* on that basis - you're just going to encourage circumvention or a search for alternatives to your software. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: white-box crypto Was: consulting question....
James Muir wrote: Alexander Klimov wrote: On Tue, 26 May 2009, James Muir wrote: There is some academic work on how to protect crypto in software from reverse engineering. Look-up white-box cryptography. Disclosure: the company I work for does white-box crypto. Could you explain what is the point of white-box cryptography (even if it were possible)? The introduction to the following paper (from SAC 2002) gives a very good overview of white-box crypto: http://www.scs.carleton.ca/%7Epaulv/papers/whiteaes.lncs.ps The aim of white-box cryptography is to implement cryptographic primitives in such a way that they remain /secure/ against software analysis. The 'white-box' refers to the fact that the adversary has full access to the software implementation and control over its execution environment. Its prior objective would obviously be the protection of secret keys that are embedded in key instantiated implementations of encryption schemes. But often it goes beyond that objective. In some practical settings it will indeed turn out that the resulting white-box implementation behaves as a public-key primitive, as you point out, but for other applications, that might be overshooting the objective. The paper that James mentioned introduced the subject of white-box cryptography into academia. In the mean time, the subject received more interest, and has been studied further on. For more information (introduction and subsequent research), I'm happy to point you to my PhD dissertation of March this year, entitled white-box cryptography. https://www.cosic.esat.kuleuven.be/publications/thesis-152.pdf I also wrote a (rather theoretical) paper to settle a concrete definition of white-box cryptography, which you can find on e-print: http://eprint.iacr.org/2008/273. If I understand correctly, the only plausible result is to be able to use the secret key cryptography as if it were the public-key one, for example, to have a program that can do (very slow, btw) AES encryption, but be unable to deduce the key (unable to decrypt). If this is the case, then why not use normal public-key crypto (baksheesh aside)? You're right -- a white-box implementation of a symmetric cipher essentially creates an asymmetric cipher. Despite this, there are still situations where you might want a whitebox AES implementation running on a client. Consider a server that sends out updates to several hundred clients (each client has its own key). The clients are subject to whitebox attacks but the server is not. Rather than force the server to do several hundred public-key operations when it needs to push out an update, we might be able to save the server some work if use a symmetric cipher. -James Consider a DRM application that contains a key-instantiated decryption algorithm and some authentication scheme. In that case you want to prevent the extraction of the secret key, otherwise an adversary could easily circumvent the authentication scheme. Deploying a public-key cipher wouldn't help achieving this objective, since it is a matter of how you implement the decryption operation and entangle it with the authentication scheme. Another example might be a mobile agent system, where a signing key would need to be embedded in the software such that the agent can sign contracts. Brecht http://whiteboxcrypto.com -- Brecht Wyseur Katholieke Universiteit Leuven tel. +32 16 32 17 21 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 69 Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, BELGIUMoffice 01.53 brecht.wys...@esat.kuleuven.be http://homes.esat.kuleuven.be/~bwyseur P=NP if (P=0 or N=1) GPG Pub key: https://homes.esat.kuleuven.be/~bwyseur/pubkey GPG Fingerprint: 890C 7C0B F1D9 597E F205 87C8 B716 D7D3 20F8 353F - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question.... (DRM)
John Gilmore wrote: ... PPS: On a consulting job one time, I helped my customer patch out the license check for some expensive Unix circuit simulation software they were running. They had bought a faster, newer machine and wanted to run it there instead of on the machine they'd bought the node-locked license for. The faster their simulation ran, the easier my job was. Actually, I think we patched the Unix kernel or C library that the program depended upon, rather than patch the program; it was easier. Kernel. Instead of calling the subroutine that would retrieve the 32-bit hostid from the PROM, you just did a load immediate with the right number. The instructions were the same length, so everything worked fine :) Not that I know of any places that actually did this, of course :) /ji - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question.... (DRM)
Their product inserts program code into existing applications to make those applications monitor and report their own usage and enforce the terms of their own licenses, for example disabling themselves if the central database indicates that their licensee's subscription has expired or if they've been used for more hours/keystrokes/clicks/users/machines/whatever in the current month than licensed for. The idea is that software developers could use their product instead of spending time and programming effort developing their own license- enforcement mechanisms... Many people have had the same idea before. The software license manager field is pretty full of little companies (and divisions of big ones). Your prospect might be able to find a niche in there somewhere, if they study their competition to see what's missing and how they can build up an edge. But customers tend to hate software that comes managed with license managers, so it takes an exceptional company to fight the uphill sales battle to impose them. (And having a company switch from License Manager A to License Manager B requires reissuing licenses to every customer, an extraordinary customer- support hassle.) Only in markets where the customer has no effective choice (of a competing DRM-free product) does it tend to work. My last startup, Cygnus, sold un-license-managed compilers, competiting with some entrenched companies that sold license-managed compilers. We kept seeing how our own automated overnight software builds would fail using our competitors' compilers because the license manager would screw up -- or merely because the local net or Internet was down. Or it would hang overnight awaiting an available license, and doing no work in the meantime. Our compiler always ran when you asked it to. We got tens of thousands of people to switch to our (free) GNU C and C++ compilers, and enough of them paid us for support and development that our company kept growing. Our best selling point against Sun's compilers, for example, was that ours didn't use any license manager. Once you bought or downloaded it, it was yours. It would run forever, on as many machines as you liked, and you were encouraged to share it with as many friends as you could. It was simple for us to invade their niche when they had deliberately forsworn a feature set like that. John Gilmore PS: Our trade-show giveaway button one year was License Managers Suck; it was very popular. PPS: On a consulting job one time, I helped my customer patch out the license check for some expensive Unix circuit simulation software they were running. They had bought a faster, newer machine and wanted to run it there instead of on the machine they'd bought the node-locked license for. The faster their simulation ran, the easier my job was. Actually, I think we patched the Unix kernel or C library that the program depended upon, rather than patch the program; it was easier. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: white-box crypto Was: consulting question....
Alexander Klimov wrote: On Tue, 26 May 2009, James Muir wrote: There is some academic work on how to protect crypto in software from reverse engineering. Look-up white-box cryptography. Disclosure: the company I work for does white-box crypto. Could you explain what is the point of white-box cryptography (even if it were possible)? The introduction to the following paper (from SAC 2002) gives a very good overview of white-box crypto: http://www.scs.carleton.ca/%7Epaulv/papers/whiteaes.lncs.ps If I understand correctly, the only plausible result is to be able to use the secret key cryptography as if it were the public-key one, for example, to have a program that can do (very slow, btw) AES encryption, but be unable to deduce the key (unable to decrypt). If this is the case, then why not use normal public-key crypto (baksheesh aside)? You're right -- a white-box implementation of a symmetric cipher essentially creates an asymmetric cipher. Despite this, there are still situations where you might want a whitebox AES implementation running on a client. Consider a server that sends out updates to several hundred clients (each client has its own key). The clients are subject to whitebox attacks but the server is not. Rather than force the server to do several hundred public-key operations when it needs to push out an update, we might be able to save the server some work if use a symmetric cipher. -James signature.asc Description: OpenPGP digital signature
white-box crypto Was: consulting question....
2009/5/27 Alexander Klimov alser...@inbox.ru mailto:alser...@inbox.ru: On Tue, 26 May 2009, James Muir wrote: There is some academic work on how to protect crypto in software from reverse engineering. Look-up white-box cryptography. Disclosure: the company I work for does white-box crypto. Could you explain what is the point of white-box cryptography (even if it were possible)? White-box crypto is about implementing cryptographic primitives in such a way that they remain /secure/ against software analysis. The 'white-box' refers to the fact that the adversary has full access to the software implementation and control over its execution environment. The prior objective would obviously be the protection of secret keys in key instantiated implementations of encryption schemes, but often it goes beyond that. In some practical settings you would want the resulting white-box implementations to behave as a public-key primitive, as you mention below. You can find formal definitions of white-box cryptography in a paper I recently wrote: http://eprint.iacr.org/2008/273 http://eprint.iacr.org/2008/273. More information on white-box crypto you can find in my PhD dissertation of March this year. https://www.cosic.esat.kuleuven.be/publications/thesis-152.pdf https://www.cosic.esat.kuleuven.be/publications/thesis-152.pdf If I understand correctly, the only plausible result is to be able to use the secret key cryptography as if it were the public-key one, for example, to have a program that can do (very slow, btw) AES encryption, but be unable to deduce the key (unable to decrypt). If this is the case, then why not use normal public-key crypto (baksheesh aside)? Consider a DRM application that contains a key-instantiated decryption algorithm and some authentication scheme. In that case you want to prevent the extraction of the secret key, otherwise an adversary could easily circumvent the authentication scheme. Deploying a public-key cipher wouldn't help achieving this objective, since it is a matter of how you implement the decryption operation and entangle it with the authentication scheme. Another example might be a mobile agent system, where a signing key would need to be embedded in the software such that the agent can sign contracts. Regards, Brecht http://whiteboxcrypto.com -- Brecht Wyseur Katholieke Universiteit Leuven tel. +32 16 32 17 21 Dept. Electrical Engineering-ESAT / COSIC fax. +32 16 32 19 69 Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, BELGIUMoffice 01.53 brecht.wys...@esat.kuleuven.be http://homes.esat.kuleuven.be/~bwyseur P=NP if (P=0 or N=1) GPG Pub key: https://homes.esat.kuleuven.be/~bwyseur/pubkey GPG Fingerprint: 890C 7C0B F1D9 597E F205 87C8 B716 D7D3 20F8 353F - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question.... (DRM)
Jerry Leichter leich...@lrw.com writes: For the most part, software like this aims to keep reasonably honest people honest. Yes, they can probably hire someone to hack around the licensing software. (There's generally not much motivation for J Random User to break this stuff, since it protects business software with a specialized audience.) But is it (a) worth the cost; (b) worth the risk - if you get caught, there's clear evidence that you broke things deliberately. I think a far more important consideration for license-management software isn't how secure is it but how obnoxious is it for legitimate users? I know a number of people who have either themselves broken or downloaded tools to break FlexLM and similar schemes, and in every single case they were legitimate users who were prevented from using their legally purchased product by the license-mismanagement tools, or who after spending hours or even days fighting with the license-mismanagement software found it easier to break the protection than to try and figure out what contortions were required to keep the license-checking code happy. I've experienced this myself with a software tool I use, there are some (as I found out after several hours of searching support forums) well-known problems with it that the vendor doesn't seem interested in fixing, and that you can eventually resolve either with some registry hacks and other low-level changes or by downloading haxor tools that'll achieve the same result with a few minutes work (just for the record, I took the multi-hour route). So if your license-management software is sufficiently obnoxious that it turns legitimate users into DMCA-violators, you have a problem. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question....
Ray Dillinger wrote: Does anyone feel that I have said anything untrue? Can anyone point me at good information uses I can use to help prove the case to a bunch of skeptics who are considering throwing away their hard-earned money on a scheme that, in light of security experience, seems foolish? Security is relative -- you need to evaluate it against a threat model and consider what goals you are trying to achieve. A software solution may succeed in deterring attackers from developing a way to strip the DRM from a $0.99 mp3; if the mp3 only costs $0.99, then may be it isn't worth the trouble of reverse engineering the software. There is some academic work on how to protect crypto in software from reverse engineering. Look-up white-box cryptography. Disclosure: the company I work for does white-box crypto. -James signature.asc Description: OpenPGP digital signature
Re: consulting question....
If you've already explained to them that what they are trying to do is both impossible and pointless, and they still want your consulting services, take as much of their money as you can and don't feel bad about it! Maybe you can get some more people on this list hired, too :) /ji - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question.... (DRM)
On Tue, 2009-05-26 at 18:49 -0700, John Gilmore wrote: It's a little hard to help without knowing more about the situation. I.e. is this a software company? Hardware? Music? Movies? Documents? E-Books? It's a software company. Is it trying to prevent access to something, or the copying of something? What's the something? What's the threat model? Why is the company trying to do that? Trying to restrain customers? Its customers would be other software companies that want to produce monitored applications. Their product inserts program code into existing applications to make those applications monitor and report their own usage and enforce the terms of their own licenses, for example disabling themselves if the central database indicates that their licensee's subscription has expired or if they've been used for more hours/keystrokes/clicks/users/machines/whatever in the current month than licensed for. The idea is that software developers could use their product instead of spending time and programming effort developing their own license- enforcement mechanisms, using it to directly transform on the executables as the last stage of the build process. The threat model is that the users and sysadmins of the machines where the monitored applications are running have a financial motive to prevent those applications from reporting their usage. What country or countries does the company operate in? What jurisdictions hold its main customer bases? They are in the US. Their potential customers are international. And their customers' potential clients (the end users of the monitored applications) are of course everywhere. Why should we bother? Isn't it a great idea for DRM fanatics to throw away their money? More, more, please! Bankrupt yourselves and drive your customers away. Please! You're taking a very polarized view. These aren't DRM fanatics; they're business people doing due diligence on a new project, and likely never to produce any DRM stuff at all if I can successfully convince them that they are unlikely to profit from it. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question.... (DRM)
John Gilmore wrote: It's only the DRM fanatics whose installed bases of customers are mentally locked-in despite the crappy user experience (like the brainwashed hordes of Apple users, or the Microsoft victims) who are troublesome. In such cases, the community should I assume the Apple reference here is aimed at iTunes. You do know that iTunes Music Store no longer uses any DRM right ? -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
white-box crypto Was: consulting question....
On Tue, 26 May 2009, James Muir wrote: There is some academic work on how to protect crypto in software from reverse engineering. Look-up white-box cryptography. Disclosure: the company I work for does white-box crypto. Could you explain what is the point of white-box cryptography (even if it were possible)? If I understand correctly, the only plausible result is to be able to use the secret key cryptography as if it were the public-key one, for example, to have a program that can do (very slow, btw) AES encryption, but be unable to deduce the key (unable to decrypt). If this is the case, then why not use normal public-key crypto (baksheesh aside)? -- Regards, ASK - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question.... (DRM)
The introduction of the acronym DRM has drawn all the hysteria it always does. The description you've posted much more closely matches license (or sometimse entitlement) management software than DRM. There are many companies active in this field. Many are small, but Microsoft sells some solution and there are moderately large companies around. Some of these have been around for many years. Traditionally, license management software looked at local files or databases rather than out on the Internet. However, I'm sure Internet options exist. The better software of this sort is challenging to crack. Certainly, none of it is *impossible* to crack - though the best dongle-based systems are probably extremely difficult (but also unacceptable for most kinds of software). For the most part, software like this aims to keep reasonably honest people honest. Yes, they can probably hire someone to hack around the licensing software. (There's generally not much motivation for J Random User to break this stuff, since it protects business software with a specialized audience.) But is it (a) worth the cost; (b) worth the risk - if you get caught, there's clear evidence that you broke things deliberately. Probably the greatest use for such software is not in preventing unlicensed users from running it at all but in enforcing contractual limits - e.g., you can only use this to manage up to X machines. Every company that has sold software with that kind of contract will likely find that, unless the software enforces the limitation, its customers will exceed it - often unknowingly, often by large factors. I'd suggest that you, and the company you're consulting to, spend some time understanding the market. What kind of software vendors are you selling to? B2B is a very different marketplace from consumer. Within B2B, high touch sales are very different from mass market. If you go international, a great deal depends on where you think you're going to sell. If you are ultimately depending on contractual enforcement, with the licensing software just an encouragement to good behavior, you're fine in the US and Western Europe, but you're not going to have a happy time in, say, Russia and China. A Google search on license management software turns up many hits, including an overview article that may be useful: http://software.forbes.com/license-management-software (One thing to be aware of is that this phrase is a bit ambiguous, covering both software a vendor puts in to its code to manage licenses, and software sold to large end users to help them keep track of what licenses they are using. The listing in the article covers both, but is still incomplete - it misses one of the long-established companies, Acresso Software - a new name - that sells the FLEXnet license enforcement software, a business it's been in for at least 10 years or so.) -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question.... (DRM)
On Wed, May 27, 2009 at 2:01 AM, Darren J Moffat darren.mof...@sun.com wrote: John Gilmore wrote: It's only the DRM fanatics whose installed bases of customers are mentally locked-in despite the crappy user experience (like the brainwashed hordes of Apple users, or the Microsoft victims) who are troublesome. In such cases, the community should I assume the Apple reference here is aimed at iTunes. You do know that iTunes Music Store no longer uses any DRM right ? For the music, that's true, but not for the other items sold there (movies, TV shows, and especially not iPhone apps, as any iPhone developer who's jumped through those DRM hoops will tell you). n - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question....
On 1243421494 seconds since the Beginning of the UNIX epoch Marcus Brinkmann wrote: However, it also sounds like they are shifting the burden of proof. Shouldn't they convince you (whoever they make the DRM for) that their system is working? Have we really reached a situation where non-experts believe that DRM works until proven otherwise? That seems an extraordinary marketing success of the sellers of DRM technology, because it stands against a mountain of evidence in the history of computing. I have noticed in my years as a security practitioner, that in my experience non-security people seem to assume that a system is perfectly secure until it is demonstrated that it is not with an example of an exploit. Until an exploit is generated, any discussion of insecurity is filed in their minds as ``academic'', ``theoretical'' or ``not real world''. This of course makes it quite difficult to cause various issues to be fixed in practice as it is generally more time consuming to construct and explain an exploit than to simply fix the bug that has been discovered. The next refrain that one is likely to hear even after demonstrating that a security issue exists is ``How many people know how to do that?'' I've actually heard that in some rather amusing circumstances such as ``Well, how many people actually know how to read or edit XML?'' It is a tricky conversation to explain to people that XML is not in fact an encryption mechanism---especially if they have seen any machine produced XML recently. Of course, this is one of the more amusing examples but others abound. I'm interested in asking people what rhetorical techniques they use to overcome such difficulties in practice? -- Roland Dowdeswell http://Imrryr.ORG/~elric/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question.... (DRM)
This is getting a bit far afield from cryptography, but proper threat analysis is still relevant. On May 27, 2009, at 4:07 AM, Ray Dillinger wrote: On Tue, 2009-05-26 at 18:49 -0700, John Gilmore wrote: It's a little hard to help without knowing more about the situation. I.e. is this a software company? Hardware? Music? Movies? Documents? E-Books? It's a software company. Is it trying to prevent access to something, or the copying of something? What's the something? What's the threat model? Why is the company trying to do that? Trying to restrain customers? Its customers would be other software companies that want to produce monitored applications. Their product inserts program code into existing applications to make those applications monitor and report their own usage and enforce the terms of their own licenses, for example disabling themselves if the central database indicates that their licensee's subscription has expired or if they've been used for more hours/keystrokes/clicks/users/machines/whatever in the current month than licensed for. The idea is that software developers could use their product instead of spending time and programming effort developing their own license- enforcement mechanisms, using it to directly transform on the executables as the last stage of the build process. The threat model is that the users and sysadmins of the machines where the monitored applications are running have a financial motive to prevent those applications from reporting their usage. If this is really their threat model, it's ill-considered. First, no reputable company in their right mind would play games with software licensing in an attempt to save a few dollars. In fact, most companies bend over backwards with internal audits and other mechanisms to ensure they are in compliance. The risk is far too great to do otherwise -- both to reputation and to the bottom line. They may counter that they are attempting to nudge into compliance reputable companies that are simply not large enough or savvy enough to ensure their own compliance. In this case, something far less complex than what is traditionally implied by DRM can be used. Thus, the users you are now considering are members of _disreputable_ companies. Since DRM is easily circumvented, and the company is disreputable, you have a reasonable expectation that your DRM will be ineffective. Second, sysadmins have no financial motive, unless they are also the owners. It is irrelevant to the sysadmin whether the business pays an appropriate amount for licenses. His salary is still his salary. Finally, large institutions (let's take financial firms as this is my area of expertise) will not install software that has hard expirations or other restrictive licensing mechanisms. The reason is simple. These mechanisms cause outages -- sometimes because of snafus in the renewal of licenses, sometimes because of poor code quality in the enforcement mechanism. At my firm, any such scheme is an immediate non-starter. -wps - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question....
On Wed, 2009-05-27 at 10:31 -0400, Roland Dowdeswell wrote: I have noticed in my years as a security practitioner, that in my experience non-security people seem to assume that a system is perfectly secure until it is demonstrated that it is not with an example of an exploit. Until an exploit is generated, any discussion of insecurity is filed in their minds as ``academic'', ``theoretical'' or ``not real world''. This matches my experience as well. Have any exploits of this particular scheme been found in the wild? is always one of the first three questions, and the answer is one of the best predictors of whether the questioner actually does anything. For best results one must be able to say something like, Yes, six times in the last year and start naming companies, products, dates, and independent sources that can be used to verify the incidents. To really make the point one should also be able to cite financial costs and losses incurred. Because companies don't like talking about cracks and exploits involving their own products, nor support third parties who attempt systematic documentation of same, it is frequently very hard to produce sufficient evidence to convince and deter new reinventors of the same technology. This failure to track and document exploits and cracks is a cultural failure that, IMO, is currently one of the biggest nontechnical obstacles to software security. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
consulting question....
At a dinner party recently, I found myself discussing the difficulties of DRM (and software that is intended to implement it) with a rather intense and inquisitive woman who was very knowledgeable about what such software is supposed to do, but simultaneously very innocent of the broad experience of such things that security people have had. She was eager to learn, and asked me to summarize what I said to her in an email. So I did And it turns out that she is an executive in a small company which is now considering the development of a DRM product. I just got email from her boss (the CEO) offering to hire me, for a day or two anyway, as a consultant. If I understand correctly, my job as consultant will be to make a case to their board about what hurdles of technology and credibility that small company will find in its path if it pursues this course. So now I need to go from Dinner party conversation mode to consultant mode and that means I need to be able to cite specific examples and if possible, research for the generalities I explained over dinner. I'll be combing Schneier's blog and using Google to fill in details of examples I've already cited to get ready for this, but any help that folks could throw me to help illustrate and demonstrate my points (the paragraphs below) will be much appreciated. I explained to her that the typical experience of monitored or protected software (software modified for DRM enforcement) is that some guy in a randomly selected nation far outside the jurisdiction of your laws, using widely available tools like debuggers and hex editors, makes a cracked copy and distributes it widely, and that current efforts in the field seem more focused on legislation and international prosecutions than on software technology. Software- only solutions, aside from those involving a Trusted Computing Module (which their proposed project does not - She seemed unaware of both the Trusted Computing Platform and the controversy over it) are no longer considered credible. I cited the example of DeCSS, whose crack of players for DRM'd movies used techniques generally applicable to any form of DRM'd software. I explained that in the worst case, such software works by making unacceptable compromises of security or autonomy on the machines where it is installed, citing the infamous and widespread Sony Rootkit, (and IMO also the TCM system, but I didn't go into that messa worms at dinner) and that these compromises usually become public and do serious damage to both the credibility of DRM systems generally and the cash flow of the companies that perpetrate them (ISTR Sony wound up losing something over 6 million in the US judgement alone on that one, and spent considerably more than that on legal fees in the US and several other nations). Finally, I explained the cheap attacks available to a sysadmin who does not want his DRM'd software reporting its usage statistics; for example having a firewall that filters outgoing packets. Does anyone feel that I have said anything untrue? Can anyone point me at good information uses I can use to help prove the case to a bunch of skeptics who are considering throwing away their hard-earned money on a scheme that, in light of security experience, seems foolish? Ray Dillinger - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: consulting question.... (DRM)
It's a little hard to help without knowing more about the situation. I.e. is this a software company? Hardware? Music? Movies? Documents? E-Books? Is it trying to prevent access to something, or the copying of something? What's the something? What's the threat model? Why is the company trying to do that? Trying to restrain customers? Competitors? Trying to build a cartel? Being forced to do it by a cartel? Is their product embedded? Online? Hardware? Software? Battery powered? Is it on a phone network? On the Internet? On no network? What country or countries does the company operate in? What jurisdictions hold its main customer bases? How much hassle will its customers take before they switch suppliers? What kind of industry standards must the company adhere to? What other equipment or data formats do they have/want to interoperate with? Most DRM is probably never cracked, because the product it's in never gets popular enough that anyone talented wants to crack it. If they only sell a thousand units, will they be happy? Or do they hope/plan/need to sell millions of units? Most DRM exists to build a cartel -- to make an artificial monopoly -- not to prevent *customers* from copying things, but to prevent *competitors* from being able to build compatible or interoperable equipment. This is largely because US reverse-engineering law makes such a cartel unenforceable in court, unless you use DRM to make it. Can anyone point me at good information uses I can use to help prove the case to a bunch of skeptics who are considering throwing away their hard-earned money on a scheme that, in light of security experience, seems foolish? Why should we bother? Isn't it a great idea for DRM fanatics to throw away their money? More, more, please! Bankrupt yourselves and drive your customers away. Please! It's only the DRM fanatics whose installed bases of customers are mentally locked-in despite the crappy user experience (like the brainwashed hordes of Apple users, or the Microsoft victims) who are troublesome. In such cases, the community should intervene on behalf of the users -- not to prevent the company from wasting its time and money. John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
