Re: [Fsfe-uk] Explanation of Tivosiation and problems - comments sought

[Andy]

Damn, hit the wrong button, that will teach me for sending this at 1 am.
Sorry Chris I meant to send this to the list, not to you personally.


On 16/12/06, Chris Croughton <address@hidden> wrote:
> On Fri, Dec 15, 2006 at 04:10:53PM +0000, Ciaran O'Riordan wrote:
> > Allowing items #1 and #2 is important because they can be used for
> > security purposes.
>
> While distributing the keys so that anyone can still install any
> software they like?
I _think_ what was meant by distributing the keys was that each
machine produced had a different key, and thus you could give someone
the key to their device.

I would most certainly not want someone else installing things on my
device. Of course there are better ways to secure a system. I may
however want to modify the system myself, of course if I choose to do
this and I destroy the system then that is my fault and I have to fix
it myself.

Having said I wouldn't want other people installing things on my
device, this locking isn't going to prevent the manufacturer tampering
with my device is it? in fact it can even prevent me from stopping
them making a change to my device

Back on the subject of using a unique key per device, how easy/hard is
this going to be?
Is it easy to program each 'protection chip' separately?
Of course if each one had a different key then you would need to use a
different signature for every patch you send out. Thus I would suggest
a 2 key system.
A Master Key, held by the manufacturer, that can authorise a program
to run on any device, and a personal key, which is unique for each
device and is given only to the person who owns the device, along with
a warning and disclaimer that if they use this key to alter the system
and their system breaks its there own fault and don't come whining to
us. (Maybe have the device itself record if it has run programs signed
with the 'personal key' so it can void the warranty and the
manufacturer knows when the guy wants his device fixed that this is
what happened.)

Personally I would think a system that doesn't actually have the
ability to alter the program or main file system permanently while
running could be a good idea.
I have in fact used such a system, the root file system is held in
flash as a compressed RAM disk, this is read only, but the system
reads it sticks it in RAM and can modify it's files to its hearts
content, safe in the knowledge that rebooting it will destroy every
change it made. Like a never failing 'return to factory settings'
button.

The system can be changed, but not by nasty code, you need to create a
compressed RAM disk, save it to a flash memory card, power the device
off, insert the card, move a switch on the board and the boot loader
will store your new RAM disk.

Of course I downside to this approach is how do you apply patches? If
the software can make a permanent change then the security of the
system is gone completely.
My answer? Store the differences in a separate read/write location,
and make them digitally signed. At boot up apply them to the RAM disk.

We are back onto the secure locking thing aren't we? With one key
difference, with my proposal it is implemented in software, all the
user has to do is follow the procedure for changing the RAM disk and
alter the digital signature checking code to permit him to sign stuff
as well.

I am kind of going off topic so I will stop here

_ Andy

--
Did you think it should be legal to rip a CD to your PC or MP3 player?
Change the law, sign the petition http://petitions.pm.gov.uk/privatecopy/


--
Did you think it should be legal to rip a CD to your PC or MP3 player?
Change the law, sign the petition http://petitions.pm.gov.uk/privatecopy/