All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakob Oestergaard <jakob@unthought.net>
To: Dean McEwan <dean_mcewan@linuxmail.org>
Cc: szepe@pinerecords.com, viro@parcelfarce.linux.theplanet.co.uk,
	alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org
Subject: Re: Digital Rights Management - An idea (limited lease, renting, expiration, verification) NON HAR*D*WARE BASED.
Date: Mon, 19 May 2003 13:01:23 +0200	[thread overview]
Message-ID: <20030519110122.GC14971@unthought.net> (raw)
In-Reply-To: <20030515104458.4886.qmail@linuxmail.org>

On Thu, May 15, 2003 at 10:44:58AM +0000, Dean McEwan wrote:
> Actually the program is dynamically encrypted with a new key each time.

Yeah, whatever

> Intefering with memory buffers causes the kernel to delete the
> program, Key is sent over VPN, tampering with the kernel causes the
> MD5 hash to be incorrect,

Who sends the now-incorrect MD5?  The kernel? But since it's been
tampered with, how do you know it sends the trust now-incorrect MD5 sum,
instead of a copy of the original MD5 sum?

> and key isn't sent, DRM self scans itself,

What for?

If DRM is tampered with, making it scan itself is pretty useless - once
it has been tampered with, it can no longer be trusted to perform the
self scan.   In other words, such self-scanning is fundamentally flawed.

Read "The inevitability of failure" - pay special attention to the fact
that they *never* recommend anything like self-scanning, but rather
focus on mechanisms to ensure that whatever it was you wanted to
self-scan could never have been tampered with in the first place (thus
making the self-scanning that can't work anyway, a non-issue).

  http://www.nsa.gov/selinux/inevit-abs.html

> MD5 hash sums are made on the sources and DRM will dynamically
> recompile itself every 32 seconds, checking the sources.

... using which compiler ?

... compiled using which compiler ?

Nevermind that - you don't need to answer.

Read "Reflections on trusting trust" by Ken R.

   http://cm.bell-labs.com/who/ken/trust.html


Your idea is fundamentally flawed. You can always add more layers of
self-checking-self-checkers, but this does not change the fact that the
idea is fundamentally flawed.

I'm sorry - it's not that I don't like you or anything like that - but
the idea is stupid, just give it up   :)

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

  parent reply	other threads:[~2003-05-19 10:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-15 10:44 Digital Rights Management - An idea (limited lease, renting, expiration, verification) NON HAR*D*WARE BASED Dean McEwan
2003-05-15 11:17 ` Riley Williams
2003-05-19 11:01 ` Jakob Oestergaard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-15 14:37 Dean McEwan
2003-05-15 14:19 Dean McEwan
2003-05-14 15:22 Dean McEwan
2003-05-14 16:13 ` viro
2003-05-14 19:07   ` Tomas Szepe
2003-05-15  6:46 ` Valdis.Kletnieks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030519110122.GC14971@unthought.net \
    --to=jakob@unthought.net \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=dean_mcewan@linuxmail.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=szepe@pinerecords.com \
    --cc=viro@parcelfarce.linux.theplanet.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.