Hagai Bar-El

List,
This was just published yesterday:
http://www.engadget.com/2006/08/25/fairuse4wm-strips-windows-media-drm/
Actually, I am not even sure why I am sending this out. After all,
this should not come by a surprise to anyone.
A DRM system that relies on obscurity of code and on software-based
key hiding on an open platform can never be truly resistant to attacks.
Okay, I shall not say "never" because there is no proof for that.
However, history shows that such software-based protection has never
(snip)

Hagai, List,
Is it *impossible* to hide a secret key in program code?

Many apps rely on this. :(

On 8/26/06, Hagai Bar-El wrote:

List,
This was just published yesterday:
http://www.engadget.com/2006/08/25/fairuse4wm-strips-windows-media-drm/
Actually, I am not even sure why I am sending this out. After all,
this should not come by a surprise to anyone.

A DRM system that relies on obscurity of code and on software-based
key hiding on an open platform can never be truly resistant to attacks.

Okay, I shall not say "never" because there is no proof for that.
However, history shows that such software-based protection has never
been done properly before; not just in the context of DRM but also in
the context of a close cousin --- software piracy prevention.

Even with software systems, it will always be orders of magnitude
more difficult to rip off content that was never legally obtained by
the circumvented device, but the problem is bad enough even without
this capability.

Hagai, List,
Is it *impossible* to hide a secret key in program code? Many apps
rely on this. :(

Okay, I shall not say "never" because there is no proof for that.
However, history shows that such software-based protection has never
been done properly before; not just in the context of DRM but also in
the context of a close cousin --- software piracy prevention.

Well, as long as the CPU runs the software, and the
owner of the machine controls the CPU, and the software
has to extract the secret key, then I'd say that is
proof enough?

Even with software systems, it will always be orders of magnitude
more difficult to rip off content that was never legally obtained by
the circumvented device, but the problem is bad enough even without
this capability.

It all depends on what you are trying to achieve. If
you are trying to achieve "never cracked" then that's
impossible. Futile even.
However, if you are trying to do business, then it is
ok to have some exceptions.
The essence of the business model is to create a barrier
that is sufficient to create the revenue stream. If you
think of a song track, all we have to do is to raise the
barrier to the next alternative price plus some delta,
and people will buy instead. So assume that the cost of
(snip)

It is a rational proof, but what it proves is that the software code
cannot be hidden. It does not prove anything about the ability to use
this information (all instructions going through the processor) to
recover the key. It is easy to write code that will make it fairly
hard to trace the key generation process, although this will always
be possible in theory (and in all cases we've seen so far -- is
eventually done in practice). There is no proof that there is no way
(snip)

Software can be made very complex when this is its purpose (and also
when this is not), and reverse-engineering, such as
reverse-compilation, is always more complex than coding.

History shows that hiding keys in code never succeeded in the
long-run, and it can be proven that _complete_ obfuscation cannot
occur, but nothing proves that obfuscation is not possible to the
_practical_ extent.

...There is no proof that there is no way to make this
reverse-engineering process _practically_ too complex to carry out,
especially when the code makes use of functions running on external
components.

Software can be made very complex when this is its purpose (and also
when this is not), and reverse-engineering, such as reverse-compilation,
is always more complex than coding.
History shows that hiding keys in code never succeeded in the long-run,
and it can be proven that _complete_ obfuscation cannot occur, but
nothing proves that obfuscation is not possible to the _practical_ extent.

I think we're mixing two types of compromise here, but one leads to the
other. I will elaborate:

However, I still do not feel comfortable with the applicability of your
model to some attacks on DRM, although I agree with the statement in
general.
Indeed, if the attack costs more than the price of the content (or
equals) then no circumvention is worth it. However, a circumvention
activity that results in unprotected content (such as this one) adds
another factor which is the fact that the cost of circumvention is not
paid by most consumers.

Of course, getting a file over a P2P network has its own X+Y+Z cost, but
apparently today this cost is less than the spoken $1; otherwise DRM
would not have been necessary in the first place...

Financial Cryptography Update: Universal Music throws in the towel, price of music drops to $0.00 >
August 30, 2006 >
Universal Music has announced it is moving its catalogue to a "free > with adverts" model.

... experience has
shown that for every day a skilled programmer spends obscuring the decryption
and authentication process, it delays the time taken by a cracker to analyse and
bypass the protection by about one hour.....

At one point, dongles for software were common; their use was discontinued due
to the USG directing that no such software would be purchased in future, but

until then a dongle chain of ten or more devices (which may or may not conflict)
being propped up behind a designer's pc on books to prevent the printer port
being pulled loose from the system board was not rare, and getting them all to
work without pulling them apart and putting them back in a different order was
an art rather than a science.

The essence of the business model is to create a barrier
that is sufficient to create the revenue stream. If you
think of a song track, all we have to do is to raise the
barrier to the next alternative price plus some delta,
and people will buy instead. So assume that the cost of
a track is 99cents. Therefore the barrier should be $1
per track.

If X + Y + Z are greater than $1 for a significant group
of people, you will generate a revenue stream.

The attack in question is one that allows the ripping of content that
was purchased, not of any content, so the $1 model does not apply.
The opponent in our case has to pay this $1 anyway and the
circumvention utility will only let him obtain an unrestricted copy
in return for this $1.

Indeed, if the attack costs more than the price of the content (or
equals) then no circumvention is worth it.

When one guy uses the circumvention device, paying X+Y+Z for whatever
reason, he spills a free piece of content that is circulated by the
same means used to circulate pirated content today.

Dave Howe wrote:

... experience has shown that for every day a skilled programmer spends
obscuring the decryption and authentication process, it delays the time
taken by a cracker to analyse and bypass the protection by about one
hour.....

Nice metric! Is there a reference or research or quote on that?

At one point, dongles for software were common; their use was discontinued
due to the USG directing that no such software would be purchased in
future, but

Yowsa! I didn't know that. What was their reason?

until then a dongle chain of ten or more devices (which may or may not
conflict) being propped up behind a designer's pc on books to prevent the
printer port being pulled loose from the system board was not rare, and
getting them all to work without pulling them apart and putting them back
in a different order was an art rather than a science.

LOL... so the DRM system called the dongle *raised* the costs of the software
for both bone fide users as well as for others. Has to be taken into account.

Hagai Bar-El wrote:

> ...There is no proof that there is no way to make this
> reverse-engineering process _practically_ too complex to carry out,
> especially when the code makes use of functions running on external
> components.


Hagai, "proof" and "practically" don't go well together in
the same sentence!  "Practically" is an economic question.

> Software can be made very complex when this is its purpose (and also
> when this is not), and reverse-engineering, such as reverse-compilation,
> is always more complex than coding.
>

> History shows that hiding keys in code never succeeded in the long-run,
> and it can be proven that _complete_ obfuscation cannot occur, but
> nothing proves that obfuscation is not possible to the _practical_ extent.

History shows that obfuscation can create a barrier.

It is up to the details as to whether it is enough of
a barrier.  Using obfuscation *alone* doesn't seem to
work.  Using obfuscation along with legal and contract
provisions, and selling to a business community might
work.


(But, I think we are agreeing?!)

> However, I still do not feel comfortable with the applicability of your
> model to some attacks on DRM, although I agree with the statement in
> general.

>

> Indeed, if the attack costs more than the price of the content (or
> equals) then no circumvention is worth it. However, a circumvention
> activity that results in unprotected content (such as this one) adds
> another factor which is the fact that the cost of circumvention is not
> paid by most consumers.


It's probably best to assume that the content is
available for $0 somewhere.  We can after all buy a
CD and rip that.  The question then becomes, what is
the cost for the ordinary user to get the content?

That's what iPod succeeded in doing -- lowering that
cost, while keeping the cost of the $0 rip at some
cost above what was delivered to iPod customers.
It, famously, works for Apple's iPod, creating
significant revenue streams.  The goal is *not* 100%
protection, but a revenue stream.

Hi,
At 31/08/06 12:57, Ian G wrote:

Hagai Bar-El wrote:

...There is no proof that there is no way to make this
reverse-engineering process _practically_ too complex to carry out,
especially when the code makes use of functions running on external
components.

Hagai, "proof" and "practically" don't go well together in
the same sentence! "Practically" is an economic question.

Why not? As long as practicality can be quantified, a proof can be
formed based on this quantification. You do not prove impossibility, in
this case, but that succeeding is at least as hard as doing X, where X
is your impracticality threshold.

Whereas there is a proof that hiding code in software ultimately is
impossible, there is no proof that hiding cannot be done in a way that
will require at least X amount of effort.

(But, I think we are agreeing?!)

We are...

However, I still do not feel comfortable with the applicability of your
model to some attacks on DRM, although I agree with the statement in
general.
Indeed, if the attack costs more than the price of the content (or
equals) then no circumvention is worth it. However, a circumvention
activity that results in unprotected content (such as this one) adds
another factor which is the fact that the cost of circumvention is not
paid by most consumers.

It's probably best to assume that the content is
available for $0 somewhere. We can after all buy a
CD and rip that. The question then becomes, what is
the cost for the ordinary user to get the content?

Okay, we're making some progress. ;)
In the typical DRM world - you will not be able to rip a song off a CD.
The DRM proponents do not admit that the content will be available for
$0 somewhere, as naive as it may be to believe so.

If you assume that the content is available for $0 somewhere even after
we have DRM in place then what you're actually saying is that DRM made
no difference. The situation today is that the "bad guys" have built an
effective network that makes "available for $0 somewhere" = "available
for 0$ everywhere" for some cost of download + searching + handling
fakes, etc. per title per location. This infrastructure was achieved and
is here to stay.
(snip)

You may say that content duplication costs (download + searching +
handling fakes, etc.), and this is true, but apparently today this cost
is bearable and is lower than the cost of the title, otherwise we do not
need DRM at all!

That's what iPod succeeded in doing -- lowering that
cost, while keeping the cost of the $0 rip at some
cost above what was delivered to iPod customers.
It, famously, works for Apple's iPod, creating
significant revenue streams. The goal is *not* 100%
protection, but a revenue stream.

iPod sells convenience. How much money are they making in comparison to
the size of the industry?

They have their loyal customers, but most
people just get pirated stolen copies of their MP3's over the P2P
networks and upload them on their cheap MP3 players...
iPod sells to people who are willing to pay for extra convenience. I may
be one, but they are not the majority.

...And, looking at the future, P2P clients will get easier to use - not
harder, making the delta in convenience diminish.

Hagai, "proof" and "practically" don't go well together in the same
sentence! "Practically" is an economic question.

Why not? As long as practicality can be quantified, a proof can be formed
based on this quantification. You do not prove impossibility, in this case,
but that succeeding is at least as hard as doing X, where X is your
impracticality threshold.

Whereas there is a proof that hiding code in software ultimately is
impossible, there is no proof that hiding cannot be done in a way that will
require at least X amount of effort.

Okay, we're making some progress. ;) In the typical DRM world - you will not
be able to rip a song off a CD. The DRM proponents do not admit that the
content will be available for $0 somewhere, as naive as it may be to believe
so.

If you assume that the content is available for $0 somewhere even after we
have DRM in place then what you're actually saying is that DRM made no
difference. The situation today is that the "bad guys" have built an
effective network that makes "available for $0 somewhere" = "available for 0$
everywhere" for some cost of download + searching + handling fakes, etc. per
title per location. This infrastructure was achieved and is here to stay.

You may say that content duplication costs (download + searching + handling
fakes, etc.), and this is true, but apparently today this cost is bearable
and is lower than the cost of the title, otherwise we do not need DRM at all!

That's what iPod succeeded in doing -- lowering that cost, while keeping
the cost of the $0 rip at some cost above what was delivered to iPod
customers. It, famously, works for Apple's iPod, creating significant
revenue streams. The goal is *not* 100% protection, but a revenue stream.

...And, looking at the future, P2P clients will get easier to use - not
harder, making the delta in convenience diminish.

Hagai Bar-El wrote:

...There is no proof that there is no way to make this
reverse-engineering process _practically_ too complex to carry out,
especially when the code makes use of functions running on external
components.

Hagai, "proof" and "practically" don't go well together in
the same sentence! "Practically" is an economic question.

Software can be made very complex when this is its purpose (and also
when this is not), and reverse-engineering, such as reverse-compilation,
is always more complex than coding.
History shows that hiding keys in code never succeeded in the long-run,
and it can be proven that _complete_ obfuscation cannot occur, but
nothing proves that obfuscation is not possible to the _practical_ extent.

History shows that obfuscation can create a barrier.
It is up to the details as to whether it is enough of
a barrier. Using obfuscation *alone* doesn't seem to
work. Using obfuscation along with legal and contract
provisions, and selling to a business community might
work.
(But, I think we are agreeing?!)

However, I still do not feel comfortable with the applicability of your
model to some attacks on DRM, although I agree with the statement in
general.
Indeed, if the attack costs more than the price of the content (or
equals) then no circumvention is worth it. However, a circumvention
activity that results in unprotected content (such as this one) adds
another factor which is the fact that the cost of circumvention is not
paid by most consumers.

It's probably best to assume that the content is
available for $0 somewhere. We can after all buy a
CD and rip that. The question then becomes, what is
the cost for the ordinary user to get the content?

That's what iPod succeeded in doing -- lowering that
cost, while keeping the cost of the $0 rip at some
cost above what was delivered to iPod customers.
It, famously, works for Apple's iPod, creating
significant revenue streams. The goal is *not* 100%
protection, but a revenue stream.

> Why not? As long as practicality can be quantified, a proof can be
> formed based on this quantification. You do not prove impossibility, in
> this case, but that succeeding is at least as hard as doing X, where X
> is your impracticality threshold.

Well, practicality cannot be quantified.  It's
a marketing or economics question, what is
practical for one person is not practical for
another.

> Okay, we're making some progress. ;)
> In the typical DRM world - you will not be able to rip a song off a CD.
> The DRM proponents do not admit that the content will be available for
> $0 somewhere, as naive as it may be to believe so.



Right.  That's their belief.  I submit that this is
simply a belief that we do not need to adopt ourselves,
as it seems to be ludicrous on the face of it.  Unless
they are paying for us to pretend that belief, that
is ;)

> If you assume that the content is available for $0 somewhere even after
> we have DRM in place then what you're actually saying is that DRM made
> no difference. The situation today is that the "bad guys" have built an
> effective network that makes "available for $0 somewhere" = "available
> for 0$ everywhere" for some cost of download + searching + handling
> fakes, etc. per title per location. This infrastructure was achieved and
> is here to stay.

>

> So, if the content is "available for $0 somewhere" then we're back in
> square 1.


I think that's where we are.

> You may say that content duplication costs (download + searching +
> handling fakes, etc.), and this is true, but apparently today this cost
> is bearable and is lower than the cost of the title, otherwise we do not
> need DRM at all!


Well, it is bearable for some part of the population,
being those who a) struggle to get file sharing to
work, and b) accept the legal risks, etc etc.

It is not bearable for some other part of the popn.,
who prefer to a) buy an iPod, b) plug in to some big
network like iTunes, and c) click-to-pay when told to
do so.


The marketing question is whether group 2 can survive
and generate sufficient revenue, even in the presence
of group 1.

Building DRM is not about making it impossible to copy,
but is about creating group 2.  Very different question.

> iPod sells convenience.
ow much money are they making in comparison to
> the size of the industry?


iPod is actually making *significant* amounts of money
compared to the rest of the industry ... within the
context that they are growing like a dotcom success.
It is already selling as many singles as some other
channels sell (I don't recall the stats though) and
it has until yesterday held the line at the ridiculously
outrageous price of $0.99.

> They have their loyal customers, but most
> people just get pirated stolen copies of their MP3's over the P2P
> networks and upload them on their cheap MP3 players...
> iPod sells to people who are willing to pay for extra convenience. I may
> be one, but they are not the majority.

40:1 was the ratio reported yesterday.  Yes.

Hagai Bar-El wrote:
>> Hagai, "proof" and "practically" don't go well together in the same
>> sentence!  "Practically" is an economic question.
> Why not? As long as practicality can be quantified, a proof can be formed
> based on this quantification. You do not prove impossibility, in this case,
> but that succeeding is at least as hard as doing X, where X is your
> impracticality threshold.


Unfortunately, what is "practical" has so many variables that cannot be
determined that you can only at best make a guess at what reasonable values
would be.


Examples are: . . .

> Whereas there is a proof that hiding code in software ultimately is
> impossible, there is no proof that hiding cannot be done in a way that will
> require at least X amount of effort.
  There is no guarantee that X amount of effort is required for a given
protection scheme; consider any number of encryption schemes that were
considered uncrackable, until cryptanalysis advanced to the point that a
standard method sufficed to break that scheme. In programming, a novel approach
to a problem may well allow an attacker to breeze though your protection as
though it wasn't there, and examine the state of a unprotected, running system
for patchout purposes.

  At any given moment, a protected executable has two pieces

1. A protected and non-executable protected block
2. An unprotected and executable block to remove the protection as needed

of the two, the latter is almost invariably the target of the "hack", not the
former.

> If you assume that the content is available for $0 somewhere even after we
> have DRM in place then what you're actually saying is that DRM made no
> difference. The situation today is that the "bad guys" have built an
> effective network that makes "available for $0 somewhere" = "available for 0$
> everywhere" for some cost of download + searching + handling fakes, etc. per
> title per location. This infrastructure was achieved and is here to stay.

There are two aspects of this.


  First is that infringing internet audio files are almost always mp3s; mp3s are
a lossy compression format (giving amazing sound quality for the size, but not
original CD quality) so there *is* a premium to be had from purchasing an
original CD product.

  Labels could make good arguments that the latter market is the one they are
trying to reduce (or at least confine to using downloaded tracks) but in
practice, the cracking tools for the DRM are as freely available as the tracks
themselves, so DRM only serves to inconvenience legitimate users.

Jeff K wrote:

Hagai, List,
Is it *impossible* to hide a secret key in program code?

It is possible to hide a secret key in code.
But if the code needs the secret key, then it
is possible for any attacker to single step
the program and extract the secret key.

Why not? As long as practicality can be quantified, a proof can be
formed based on this quantification. You do not prove impossibility, in
this case, but that succeeding is at least as hard as doing X, where X
is your impracticality threshold.

Well, practicality cannot be quantified. It's
a marketing or economics question, what is
practical for one person is not practical for
another.

Okay, we're making some progress. ;)
In the typical DRM world - you will not be able to rip a song off a CD.
The DRM proponents do not admit that the content will be available for
$0 somewhere, as naive as it may be to believe so.

Right. That's their belief. I submit that this is
simply a belief that we do not need to adopt ourselves,
as it seems to be ludicrous on the face of it. Unless
they are paying for us to pretend that belief, that
is ;)

If you assume that the content is available for $0 somewhere even after
we have DRM in place then what you're actually saying is that DRM made
no difference. The situation today is that the "bad guys" have built an
effective network that makes "available for $0 somewhere" = "available
for 0$ everywhere" for some cost of download + searching + handling
fakes, etc. per title per location. This infrastructure was achieved and
is here to stay.
So, if the content is "available for $0 somewhere" then we're back in
square 1.

I think that's where we are.

You may say that content duplication costs (download + searching +
handling fakes, etc.), and this is true, but apparently today this cost
is bearable and is lower than the cost of the title, otherwise we do not
need DRM at all!

Well, it is bearable for some part of the population,
being those who a) struggle to get file sharing to
work, and b) accept the legal risks, etc etc.
It is not bearable for some other part of the popn.,
who prefer to a) buy an iPod, b) plug in to some big
network like iTunes, and c) click-to-pay when told to
do so.
The marketing question is whether group 2 can survive
and generate sufficient revenue, even in the presence
of group 1.

Building DRM is not about making it impossible to copy,
but is about creating group 2. Very different question.

iPod sells convenience. How much money are they making in comparison to
the size of the industry?

iPod is actually making *significant* amounts of money
compared to the rest of the industry ... within the
context that they are growing like a dotcom success.
It is already selling as many singles as some other
channels sell (I don't recall the stats though) and
it has until yesterday held the line at the ridiculously
outrageous price of $0.99.

They have their loyal customers, but most
people just get pirated stolen copies of their MP3's over the P2P
networks and upload them on their cheap MP3 players...
iPod sells to people who are willing to pay for extra convenience. I may
be one, but they are not the majority.

40:1 was the ratio reported yesterday. Yes.

Hagai Bar-El wrote:

Hagai, "proof" and "practically" don't go well together in the same
sentence! "Practically" is an economic question.

Why not? As long as practicality can be quantified, a proof can be formed
based on this quantification. You do not prove impossibility, in this case,
but that succeeding is at least as hard as doing X, where X is your
impracticality threshold.

Unfortunately, what is "practical" has so many variables that cannot be
determined that you can only at best make a guess at what reasonable values
would be.
Examples are: . . .

Whereas there is a proof that hiding code in software ultimately is
impossible, there is no proof that hiding cannot be done in a way that will
require at least X amount of effort.

There is no guarantee that X amount of effort is required for a given
protection scheme; consider any number of encryption schemes that were
considered uncrackable, until cryptanalysis advanced to the point that a
standard method sufficed to break that scheme. In programming, a
novel approach
to a problem may well allow an attacker to breeze though your protection as
though it wasn't there, and examine the state of a unprotected, running system
for patchout purposes.

At any given moment, a protected executable has two pieces
1. A protected and non-executable protected block
2. An unprotected and executable block to remove the protection as needed
of the two, the latter is almost invariably the target of the "hack", not the
former.

If you assume that the content is available for $0 somewhere even after we
have DRM in place then what you're actually saying is that DRM made no
difference. The situation today is that the "bad guys" have built an
effective network that makes "available for $0 somewhere" =

"available for 0$

everywhere" for some cost of download + searching + handling

fakes, etc. per

title per location. This infrastructure was achieved and is here to stay.

There are two aspects of this.
First is that infringing internet audio files are almost always
mp3s; mp3s are
a lossy compression format (giving amazing sound quality for the size, but not
original CD quality) so there *is* a premium to be had from purchasing an
original CD product.

Labels could make good arguments that the latter market is the one they are
trying to reduce (or at least confine to using downloaded tracks) but in
practice, the cracking tools for the DRM are as freely available as the tracks
themselves, so DRM only serves to inconvenience legitimate users.

> It is possible to hide a secret key in code.
> But if the code needs the secret key, then it
> is possible for any attacker to single step
> the program and extract the secret key.

Actually, no. This is true assuming that the program will go through all
its possible traces when you "single step it". But in fact an arbitrary
program will be run with many different inputs, and may thus execute
many different traces. Imagine a program executing the following algorithm

if
ash(input)=hardcoded-value then {
   c:=Decrypt(input,encrypted-code)
   execute c };

   else abort;

. . .

Hi,
At 01/09/06 15:14, Ian G wrote:

Why not? As long as practicality can be quantified, a proof can be
formed based on this quantification. You do not prove impossibility, in
this case, but that succeeding is at least as hard as doing X, where X
is your impracticality threshold.

Well, practicality cannot be quantified. It's
a marketing or economics question, what is
practical for one person is not practical for
another.

Marketing and economics play a role when you're determining the least
significant bits of this value. You can easily avoid these parameters
using extra margins.

When you analyze the specifications of a new commerce application, do
you analyze all factors to see if the brute-force ability of the
opponent is of 67 bits of entropy or 70 bits of entropy, or do you
simply put 128 bits and call it a day?

If they want and they pay then I give. period.

You may say that content duplication costs (download + searching +
handling fakes, etc.), and this is true, but apparently today this cost
is bearable and is lower than the cost of the title, otherwise we do

not

need DRM at all!

Well, it is bearable for some part of the population,
being those who a) struggle to get file sharing to
work, and b) accept the legal risks, etc etc.
It is not bearable for some other part of the popn.,
who prefer to a) buy an iPod, b) plug in to some big
network like iTunes, and c) click-to-pay when told to
do so.
The marketing question is whether group 2 can survive
and generate sufficient revenue, even in the presence
of group 1.

Right, but so far no DRM is mentioned. I agree this is the purpose --
generating revenue streams by having a large-enough group 2. However, I
do not see how DRM can change this balance in our favor. If content is
always available somewhere for $0 as it is today, no costs will change
in comparison to the cost of an illegal copy today and the sizes of
these groups will not change.

Building DRM is not about making it impossible to copy,
but is about creating group 2. Very different question.

As long as a $0 copy is somewhere, and as long as the infrastructure is
there and useful to distribute this $0 copy (as the mere existence of
the problem of pirated content proves), then DRM will not change the
size of group 2.

iPod sells convenience. How much money are they making in comparison to
the size of the industry?

iPod is actually making *significant* amounts of money
compared to the rest of the industry ... within the
context that they are growing like a dotcom success.
It is already selling as many singles as some other
channels sell (I don't recall the stats though) and
it has until yesterday held the line at the ridiculously
outrageous price of $0.99.

I can't argue with this, as I do not have the numbers.

They have their loyal customers, but most
people just get pirated stolen copies of their MP3's over the P2P
networks and upload them on their cheap MP3 players...
iPod sells to people who are willing to pay for extra convenience. I

may

be one, but they are not the majority.

40:1 was the ratio reported yesterday. Yes.

40:1 for whom? I believe it's 40 non-iPod users, stealing content over
the net against each 1 law-abiding iPod user -- please don't tell me
it's the other way around. If content infringers were 1/40 of the
consuming population then DRM was not worth the efforts...

If I am guessing right that 1/40 is paying and 39/40 are stealing then
it will prove that the content industry is loosing too much money and
apparently the group 2 is not large enough as it is.

It is possible to hide a secret key in code.
But if the code needs the secret key, then it
is possible for any attacker to single step
the program and extract the secret key.

Actually, no. This is true assuming that the program will go through all
its possible traces when you "single step it". But in fact an arbitrary
program will be run with many different inputs, and may thus execute
many different traces. Imagine a program executing the following algorithm
if Hash(input)=hardcoded-value then {
c:=Decrypt(input,encrypted-code)
execute c };
else abort;
. . .

Well, practicality cannot be quantified. It's
a marketing or economics question, what is
practical for one person is not practical for
another.

Marketing and economics play a role when you're determining the least
significant bits of this value. You can easily avoid these parameters
using extra margins.

Oh, you mean crypto-view of impracticality. OK, at
least I understand your term now.

Cryptographers extend that meaning too far. They
tend to blithely assume that because we have a bunch
of components which achieve pareto-security (to use
some jargon) then other components should also be
usefully judged by the same metrics.

Right, but so far no DRM is mentioned. I agree this is the purpose --
generating revenue streams by having a large-enough group 2. However, I
do not see how DRM can change this balance in our favor. If content is
always available somewhere for $0 as it is today, no costs will change
in comparison to the cost of an illegal copy today and the sizes of
these groups will not change.

DRM cannot change the balance because it is classically
targetted in the wrong direction. E.g., stopping kids
from listening to songs. If it was targetted in a
different direction then it might help; we could argue
that this would require a new term, but skipping that,
what would happen if we targetted it to:
management of digital revenues
and further we said:
collection of revenues from usage of rights
With a nod to slippage, this then becomes
identification of the rights,
reporting on the usage,
(snip)

As long as a $0 copy is somewhere, and as long as the infrastructure is
there and useful to distribute this $0 copy (as the mere existence of
the problem of pirated content proves), then DRM will not change the
size of group 2.

The size of group 2 is already large, it is the corporations
of the western world. They won't deal in open nets, they
will pay for product. We don't need to make them any larger,
we just need to make it easy for them to pay.

iPod is actually making *significant* amounts of money
compared to the rest of the industry ... within the
context that they are growing like a dotcom success.
It is already selling as many singles as some other
channels sell (I don't recall the stats though) and
it has until yesterday held the line at the ridiculously
outrageous price of $0.99.

I can't argue with this, as I do not have the numbers.

Take it as no more than an impression. Even if we
had the numbers to hand, they would still be subject
to lots of debate, as I describe below :) It's simply
my impression that iPod has achieved significant sales
that are now moving the market.

They have their loyal customers, but most
people just get pirated stolen copies of their MP3's over the P2P
networks and upload them on their cheap MP3 players...
iPod sells to people who are willing to pay for extra convenience. I

may

be one, but they are not the majority.

40:1 was the ratio reported yesterday. Yes.

40:1 for whom? I believe it's 40 non-iPod users, stealing content over
the net against each 1 law-abiding iPod user -- please don't tell me
it's the other way around. If content infringers were 1/40 of the
consuming population then DRM was not worth the efforts...

Yes, 40 on the side of sharing, 1 on the side of
purchasing from traditional suppliers (offering
paid download).

If I am guessing right that 1/40 is paying and 39/40 are stealing then
it will prove that the content industry is loosing too much money and
apparently the group 2 is not large enough as it is.

No such.
Firstly, they are sharing not stealing. We can show
that there is a spectrum from "listening together"
to stealing ... and a lot happens in between.
When you play a record at a party you are either a)
engaging in reasonable use, or b) sharing, or c) using
the content beyond the licence, all depending on who
you ask.

Next, many regimes have accepted sharing as reasonable.
For example, many countries have extra taxes on cassette
tapes meant to compensate authors. If there is no extra
tax on rippers, that is hardly the rippers' fault; why
then are we allowed to share on cassette but not on PC?

Hi Ariel,
At 04/09/06 18:21, Ariel Waissbein wrote:

It is possible to hide a secret key in code.
But if the code needs the secret key, then it
is possible for any attacker to single step
the program and extract the secret key.

Actually, no. This is true assuming that the program will go through all
its possible traces when you "single step it". But in fact an arbitrary
program will be run with many different inputs, and may thus execute
many different traces. Imagine a program executing the following
algorithm
if Hash(input)=hardcoded-value then {
c:=Decrypt(input,encrypted-code)
execute c };
else abort;
. . .

This seems as an interesting approach, and I can see how it helps
against static analysis of the code (by making the code readable only in
runtime). However, the typical attack we have in mind is of an attacker
tracing program execution step by step during an execution that requires
the program making use of the key.

When this is the case, the program will inevitably decrypt itself in
front of the attacker's eyes and establish the key. The fact that the
code was once encrypted has no significance (it's already decrypted when
it's traced). Also, the fact that the program runs slightly differently
each time does not seem to help, because in each run that requires the
key the program needs to establish this key, in this way or the other.
As far as the attack is concerned, only the result, that is, the key
(snip)

Ian G wrote:

It is possible to hide a secret key in code.
But if the code needs the secret key, then it
is possible for any attacker to single step
the program and extract the secret key.

Actually, no. This is true assuming that the program will go through all
its possible traces when you "single step it". But in fact an arbitrary
program will be run with many different inputs, and may thus execute
many different traces. Imagine a program executing the following algorithm
if Hash(input)=hardcoded-value then {
c:=Decrypt(input,encrypted-code)
execute c };
else abort;
here hardcoded-value=hash(K), encrypted-code=Encrypt(K,code), ENcrypt
(snip)

So there is a possibility to inlude "licensing functions" that over a
seemingly arbitrary input will follow different traces and generate new
cryptographic keys that decrypt unused code.

You also need to take into account that "dead code" is difficult to
identify (the computational problem is intractable), and therefore
someone analysing a pices of code that haven't been executed so far
might not be able to guess if the code is ever going to execute (or it
is dead code inserted on purpose by the licensee).

Of course, I am not claiming that this solves the software protection
problem nor that the problem of breaking our scheme in a practical
setting is impossible. But in some contexts, reversing the code will
yield nothing new.

There are indeed many parameters, maybe even more than the ones you
listed, but you do not need to consult all these because you can afford
a large safety margin, just as you do with ciphers.

This seems as an interesting approach, and I can see how it helps
against static analysis of the code (by making the code readable only in
runtime). However, the typical attack we have in mind is of an attacker
tracing program execution step by step during an execution that requires
the program making use of the key.

I agree with you, whenever the program "computes" and uses a key, then
it is lost for security purposes. An analyst/attacker may insert
breakpoints in every call to a decryption function and catch all these
used keys. However unused keys, that are computed out of unseen imput,
cannot be inferred.

In the scenario I disucss, different from the music protection scenario,
the program that is being protected has many branches and many different
functions. The code is encrypted not only once, but many times at
different portions of code which are either isolated or nested. The
"idea" behind this reasoning is that some portions of code will not be
executed during the standard usage, and the attacker cannot execute all
the possible traces of the program, therefore some encrypted portions
(snip)

When I mentioned dead code, what I meant is that on top of the technique
discussed above, the protected program will include some portions of
dead code, and that the attacker will have to decide whether they are
dead code, or they will be decrypted and executed some time in the
future. That is, the technique will resist simple forms of dynamic
analysis. Probably, a carefull analysis by a skilled attacker will
render all the keys (if no external input -that cannot be guessed by the
(snip)

Hagai Bar-El wrote:

There are indeed many parameters, maybe even more than the ones you
listed, but you do not need to consult all these because you can afford
a large safety margin, just as you do with ciphers.

Actually, you can't.
If you put too much protection on it, you inconvenience the
legitimate users
of your product so much they will go elsewhere (to your competitors)
rather than
put up with the overheads of your protection scheme. The lowest grade machine
you can reasonably use once your protection has been added forms the
lower bound
of your potential market. if you are a game, then the tradeoff
becomes even more
vicious - you are trading, not user wait time, but framerate for your
(snip)