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

[Chris Croughton]

On Sat, Dec 16, 2006 at 12:57:54AM +0000, Andy wrote:

> 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.

I suspected that was what you had done <g>.

> 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.

Yes, that's how I understood it as well.  However, allowing a user to
install whatever they like is dangerous.  Just look at all the Windows
trojans and viuses, many (possibly most) spread by users installing
things just because someone says "this is good".  Do you really want
them doing that with a car engine controller, or a mobile phone?

> 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.

But in the meantime you (possibly not you personally, but many people in
your position) will waste a lot of support time trying to debug the
system which the user declares "nothing changed, it just doesn't work".
And people won't leave it at "I broke it, it's my fault", these days
everything has to be someone else's fault and they 'deserve'
compensation (a friend of mine, who works in insurance claims, recently
had a person insisting on 'compensation' for injuries he caused to
himself!).  Even if you dismiss those claims they will still eat your
time and enthusiasm.

> 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

Indeed.  But I wonder if they will even bother with them if they are
blocked from keeping the key secret.

> 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?

Since this is done already with every network card (the MAC address) I
don't see why not.  Even if you don't want to use flash memory an
automated process to program fuse-programmable devices isn't al that
hard to set up.

> 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.

Yup.  Just imagine someone reprogramming their car's system at 70mph on
the M1...

> 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.

I've been glad of one of those very recently.

> 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.

I've seen a system which did something very similar to this.  After a
while the new version came out, rewrote the master copy and deleted the
patches so it started again.  (As I recall that wasn't signed, although
it was checksummed in case of coruption.)

> 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.

Yes, it can, although that also means that you could modify the software
so that it no longer required anything to be signed...

Chris C