[OT] RFC for DRM replacement

[James Michael DuPont]

--- Mark Rafn <dagon at dagon.net> wrote:

> > > >Mark Rafn wrote:
> > > >>Fundamentally, if the client is open-source, it can be 
> > > >>modified, and the 
> > > >>modified version can LIE and say it's the original version. 
> > > Anything 
> > > >>which prevents this is not open-source.
> > 
> > > Mário Amado Alves answered:
> > > >Many (most?, all?) open source licenses require authorship
> notices
> > be kept.
> 
> The program doesn't have to lie to humans, only in the API.  It's
> fine to
> require a notice that the work has been changed.  Requiring the form
> of
> that notice, or that the notice be usable for other programs to
> behave
> differently is not open-source. 

My proposal is one that it would be very hard to fake that notice. 
If the notice was a checksum of the programs content data at a given
time period, coupled with the algorithm in memory itself, is almost
impossible to fake. The auditing system will require that all clients
are able to prove that they have not changed at any time. The modified
software could try and fake this, but my idea is that the data used for
producing the checksums changes slightly for each session. It should be
possible to agree on a give set of versions that will be usedin a
transaction.

> 
> On Tue, 9 Sep 2003, James Michael DuPont wrote:
> > CUT! 
> > We are talking about a malicious user who is modifing the software
> to
> > LIE about the fact it is modified. They wont be telling anyone that
> > they did this
> 
> I wasn't.  I was talking about an honest open-source user and
> contributor 
> who is free to make a derived work from open-source software.   Of
> course 
> the documentation, and if possible the program itself will make it
> clear 
> that it's modified and based on the original work.  
> 
> For some works, this notice cannot be in the place which contains the
> original declaration, because that's part of the API.  Any program
> which tries to restrict workalikes or modified versions that use the
same 
> protocol or API calls is clearly not in the spirit of open-source.
> 

I think that the spirit of open source is not hurt by the idea of a
secure transaction. These things are separate from each other.

> > My solution is to introduce a game theory, where the game itself is
> > changed so often (the key) that it is very hard to crack all of
> them
> > quickly.
> 
> If the client is open source, nobody has to crack the key.  It's
> there in 
> the client.

If the client uses a third transaction key to handle the session, and
this key is introduced only in a short period of time, then it will be
hard to crack.

If the some data inside the client is encrypted, then it is hard to get
out.

If the assembler of the program has been modified based on some
cryptographic algorithm, using the translation based on the session
key, then it will be not possible to have a binary hack.

When all of this is in place, and the software has a way to access its
code memory and calculate an checksum of the code and the data on key
sections, then all of this can be checked by the auiditing system.

Basically, what I am trying to say, is that given a known set of data
at a random time point (known to the server) it should be possible to
create a checksum of the code and the data. That will be also
impossible to fake without running a copy of the program in parallel
(for a FPS this is very much data)
> 
> >
>
-------------------------------------------------------------------------------------------------------------------
> > http://www.advogato.org/article/698.html
> >
>
-------------------------------------------------------------------------------------------------------------------
> > 1. There are valid applications where a group of people agree to
> use
> > one version of the software and want to eliminate cheaters. A First
> > person shooter for example would be a good example 
> 
> Sure.  There are many of them, and it's probably best not to make the
> entire client open-source in that case.  Or distribute keys
> seperately 
> from the program, and give them only to trusted players, revoking
> them 
> when cheating is discovered.

Or to audit the clients on a random and regualar basis, to apply all
these security techniques to the issue.

> 
> > 2. By allowing for a auditing of the clients on a random basis, and
> the
> > inclusion of the entire memory of the software including of the
> data at
> > a specified timepoint you can get a secure fingerprint that is very
> > very difficult to fake. 
> 
> As long as the auditing program is trusted to be the original
> version. 
> Which means it's not open source. 

I disagree .
The issue is not if it is open source but the idea of transaction where
the parties cannot change the open source software that is running
without telling the others.

> 
> This is a pretty complicated system for something that boils down to
> "make 
> a non-free program that audits the free program."

Its all about this : 
Making a free program that is audited by free programs. 
Making a declaration system that allows software to say what it is. 
It is not about the freedom to change the source, but the security of a
transaction.

mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
--
license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3