sad treacherous computing day

Alfred M. Szmidt ams at gnu.org
Tue May 8 21:47:17 UTC 2007


   > This example has nothing to do with TC or DRM.  This is how just
   > about any modern operating system works.  I cannot update the
   > kernel on this machine since I do not have the permission to do
   > so because the kernel disallows me to do that task, but there is
   > no need for a specially crippled chip for this task.  So I still
   > do not see the use of DRM/TC.

   An attacker who has physical access to your machine can pull the
   disk and put his own kernel on it that will perform his own
   nefarious tasks. But if you made use of the TC module then I
   believe you can prevent him from being able to do this -- the
   system will simply refuse to load his modified kernel.

The attackar can then copy all data, install keyloggers, trojans,
backdoors and what not, so you are SOL anyway.  I could achive the
same thing, in a far more flexible way by just storing a hash of all
files on the file system, and then doing a integrity check of all
`important' files, like the kernel; this could be done on boot using a
RO memory stick that is only plugged in during boot.

   If *you* have the keys to the TC module then it becomes a very
   powerful tool for ensuring that your systems are not compromised
   while your back is turned. If someone else has the keys to the
   machine then obviously the machine belongs to them, and you are
   just a user (e.g., games consoles, some mobile phones).

This begs another question, how can you trust that the TC module
doesn't have a backdoor?  Atleast with software, I can disect the
assembly output.

I still cannot see anything useful about DRM/TC, and I'm trying hard.
Sorry.



More information about the Discussion mailing list