From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rohit Sharma Date: Mon, 05 Jun 2006 07:13:45 +0530 Subject: [U-Boot-Users] Secure Firmware + Firmware Upgrade? In-Reply-To: <20060602202449.22350353A57@atlas.denx.de> References: <20060602202449.22350353A57@atlas.denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sat, 03 Jun 2006 01:54:49 +0530, Wolfgang Denk wrote: > In message <586f5d00606020556s1940cd23seb0a8e7d67dc32a6@mail.gmail.com> > you wrote: >> >> The bootcmd envrionment variable shall "cp the-boot-script-image from >> flash to RAM" and >> "bootm the-boot-script-image". The boot script image is not compressed. > > This is redundand. "bootm" includes loading the image to the load > address. No extra copy is needed here. > >> Case 1: If the boot-bit flag is set, the boot-script shall copy the >> image to RAM and check the signed/encrypted image for authenticity and >> integrity (how this is done is yet to be identified) > > You can check the image in flash before running "bootm" > Thanks for the correction >> Case 2: If the boot flag is not set the boot-loader shall >> copy the new firmware image to a given address in RAM via kermit >> protocol > > Copy from flash to RAM with kermit protocol? Either you omitted some > vital information here, or this is fundamentally broken. Sorry for not being verbose, here I meant that if the boot bit flag is not set it would imply that the firmware upgrade failed and its not safe to boot. It would than wait to load the firmware via kermit protocol. This image shall be saved to RAM. >> erase the old kernel image at the given address >> copy the new image from RAM to flash >> finally save env so the new firmware is writable >> set the boot-bit to boot from the new firmware > > You are aware that this is not really secure in any way, as it leaves > many ways to run random unsigned images, too? In my case the firmware upgrade is not secure that is my requirement is not to check if the firmware being replaced is authentic or not, it is the signed firmware that matters. The boot-script-image (which is set read-only) shall be the first image to be loaded and shall check to see if the firmware image is authentic or not i.e. only on next boot? Only when its type authentic shall it pass control to the main firmware else fall back to default working. Am sorry if i wasn't clear in letting you explain the same before. Do you still feel that its possible to tamper and by pass the security unless ofcourse if boot-script-image is manipulated? Thanks for you kind help !!! Best Regards, rohit -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/