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 <[EMAIL PROTECTED]> 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/ _______________________________________________ Fsfe-uk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/fsfe-uk
