Copy-Protection, License-Enforcement, DRM and VISTA

[John Dough]

I am a developer in a small company that develops DRM, copy-protection and
license enforcement tools for Windows developers. Our tools currently allow
the client to create licenses and integrate our run-time components into
their software to enforce a variety of license models.
Many of the mechanisms that provide this functionality, such as hiding
redundant copies of the license in hidden and inconspicuous locations on the
system and the registry are simply not going to work on Vista. Many
operations the run-time performs to detect hackers will require permissions
not likely to be present by default and naturally a hacker will refuse to
allow.

We are willing to redesign and adapt (we must - or we will die).

My question is - what does MS want Application DRM providers to do? What
avenues has Windows left open for us to provide functionality that:

a.. Detects if the user has installed a copy of a given application
before? (This would require that uninstalls of the product always leave
something behind the user can not easily see or find).
b.. Detect if the user has tampered with certain files (This would require
that hidden or secure copies of the files can be compared against on the
users system).
I guess this boils down to: Is there a secure, hidden location we can store
information on the users system that will not get removed on an uninstall
that we can reliably read, write, create and delete - without alerting the
user? I suspect the answer is "nowhere". If so - what do the hundreds of
thousands of software developers do that need to protect their application
from illegal copying? How do we create trial versions that aren't easily
defeated? etc.

Thanks for your feedback.

 

[Clint]

Well, one option is always the "phone home" approach. Get enough
information to uniquely identify the machine in question, send it back to a
server, and see if it's registered the software on it before.

One of the obvious drawbacks is the requirement for an Internet connection
to complete the installation, as well as the user response to "big brother".
Of course, some people also object to companies installing hidden portions
(making removal/backups/restores problematic) of their application too.

Clint

 

[Clint]

BTW, our software approach is the generation and sending of a registration
key. In our system, this is a manual process, but since we have < 250
clients, it's not a big deal. You could use a similar automated system,
though. Something that lets the user test the software first, but if they
want to register it and get the full features, they must go to a website and
obtain a key. That puts the onus on them to click the button to identify
themselves with you, as opposed to you "taking" the information in an
installation "phone home" model.

Clint

 

[Tyler Hunt [MS]]

Are you saying your software didn't work before as a standard user?

As far as creating a store that will let you read, write, create, and delete
at runtime, just create it at install time and ACL it appropriately.
Don't delete it during your software's uninstallation.

As for secure and hidden - this sounds like a contradiction, if all of this
software is running on an untrusted machine.

 

[John Dough]

Are you saying your software didn't work before as a standard user?

It did, once ACL'd properly - but this was an exception. It was trivial to
require administrator priv. for use of a product protected in this way and
treat the install as a standard user as a special case which had to have
the ACL manipulation done.

Now it seems that even when logged on as an "admin". The session doesnt
operate at this priviledge level by default - instead I have to explicitly
allow or disallow all kinds of operations. Am I missing something here?

As far as creating a store that will let you read, write, create, and
delete at runtime, just create it at install time and ACL it
appropriately.
Don't delete it during your software's uninstallation.

Understood. In XP, this was the exception, not the rule, since most users
in the target environments ran as admins or we could simply require that
they did. Now however, it seems that even when logged on as an admin, i am
not "really" and admin, unless i "run elevated". Again, is there an
important concept I am missing here?

As for secure and hidden - this sounds like a contradiction, if all of
this software is running on an untrusted machine.

Good cathc - you are correct. Emphasis on "hidden".

Thanks again for your help.

 

[Mark D. VandenBerg]

It did, once ACL'd properly - but this was an exception. It was trivial
to require administrator priv. for use of a product protected in this way
and treat the install as a standard user as a special case which had to
have the ACL manipulation done.

Now it seems that even when logged on as an "admin". The session doesnt
operate at this priviledge level by default - instead I have to explicitly
allow or disallow all kinds of operations. Am I missing something here?



Understood. In XP, this was the exception, not the rule, since most users
in the target environments ran as admins or we could simply require that
they did. Now however, it seems that even when logged on as an admin, i
am not "really" and admin, unless i "run elevated". Again, is there an
important concept I am missing here?



Good cathc - you are correct. Emphasis on "hidden".

Thanks again for your help.

In Vista, even though the current user is an Administrator account,
applications run as Standard unless explicitly allowed to elevate. The big
difference is that an Administrator level user merely clicks "OK" and a
Standard level user must enter the password of an Administrator level user
when UAC displays the prompt. This is by design to give the user more
control over what runs at an elevated level and what does not. This also
allows Sysadmins to prevent users from installing applications/modifying
computers that they should not be. Microsoft has been telling software
vendors for sometime now that this is the new reality. In essence,
Microsoft is preventing the uninformed user from falling victim to "social
engineering" so prevalent in today's spy/adware. You said yourself that you
plan on users running as an Administrator in XP; while the reality is that
with XP, this is true, from a security standpoint, it should not be true.
Because the average XP user is uninformed and unsophisticated about running
XP in a secure fashion, your software works.

Another example: Logitech SetPoint 2.6 is written so that it must run at an
elevated level. Think about that for a moment: what is it about software
for mice/keyboards that need to run at an elevated level?

A good source of additional information is available from Jimmy Brush's
site:

http://www.jimmah.com/vista/category.aspx?id=security

 

[John Dough]

[...]

Microsoft has been telling software vendors for sometime now that this is
the new reality. In essence, Microsoft is preventing the uninformed user
from falling victim to "social engineering" so prevalent in today's
spy/adware. You said yourself that you plan on users running as an
Administrator in XP; while the reality is that with XP, this is true, from
a security standpoint, it should not be true. Because the average XP user
is uninformed and unsophisticated about running XP in a secure fashion,
your software works.

Understood and I agree with you completely. We now wish to change our
product to be more in-line with the way security "should work" (albeit a bit
late - we want to adapt).

The problem is that we must be able to meet certain basic requirements in
order to do so. I am open to any new way we can accomplish this - even if
it menas throwing out a great deal of what we did before. So, knowing what
you do about the problem statement, what would you suggest?


[...]

A good source of additional information is available from Jimmy Brush's
site:

http://www.jimmah.com/vista/category.aspx?id=security

Thanks - will review carefully.

TIA.

 

[Kerry Brown]

[...]

Microsoft has been telling software vendors for sometime now that
this is the new reality. In essence, Microsoft is preventing the
uninformed user from falling victim to "social engineering" so
prevalent in today's spy/adware. You said yourself that you plan on
users running as an Administrator in XP; while the reality is that
with XP, this is true, from a security standpoint, it should not be
true. Because the average XP user is uninformed and unsophisticated
about running XP in a secure fashion, your software works.

Understood and I agree with you completely. We now wish to change our
product to be more in-line with the way security "should work"
(albeit a bit late - we want to adapt).

The problem is that we must be able to meet certain basic
requirements in order to do so. I am open to any new way we can
accomplish this - even if it menas throwing out a great deal of what
we did before. So, knowing what you do about the problem statement,
what would you suggest?

[...]

A good source of additional information is available from Jimmy
Brush's site:

http://www.jimmah.com/vista/category.aspx?id=security

Thanks - will review carefully.

TIA.

Here's a start

http://windowssdk.msdn.microsoft.com/en-us/library/default.aspx

http://msdn.microsoft.com/windowsvista/prodinfo/what/about/default.aspx

http://msdn.microsoft.com/windowsvista/support/faqs/vistafaq/default.aspx

Do you have a MSDN subscription? If you program in Windows it's some of the
best money you will pend.