From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rohit Sharma Date: Mon, 05 Jun 2006 13:23:51 +0530 Subject: [U-Boot-Users] Secure Firmware + Firmware Upgrade? In-Reply-To: <20060605085725.CDFF4352655@atlas.denx.de> References: <20060605085725.CDFF4352655@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 Mon, 05 Jun 2006 14:27:25 +0530, Wolfgang Denk wrote: > In message you wrote: >> >> 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 > > In which way not safe? We have pretty good image protection using CRC > checksums. What sort of additional security do you want to gain with > this additional bit? I don't understand... Thanks, I was trying to achieve something like this (as mentioned in the example) => bootm $addr1 || bootm $addr2 || tftpboot $loadaddr $loadfile && bootm My technique was totally redundant and this sure is a more graceful way to accompalish the same. >> > 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. > > Your product will include GPLed boot loader., i. e. you must > accompany it with a written offer to give any third party a complete > copy of the corresponding source code. If I want to run my own code I > will just disable the "authenticity tests" in U-Boot and install my > own, free boot loader. Or I'll craft an image that passes your tests. The board on which I am working on shall be shipped as a small module to a big product. Even though the buyer of the product shall be the owner of the board, the warranty shall cease to exist if some one actually replaces the boot-loader. Secondly we don't want our clients to replace our firmware with any other firmware which may actually cause wrong behavior and may affect our goodwill or cause problems to them due to the nature of the product. I can understand that there are way to bypass and its not exactly fool-proof mechanism. I believe signing (PKI) the firmware would help in this regard. Giving source code is not an issue at all for me as private key shall still remain with us. The only issue i see for now is that the image header structure won't accomodate the Digital signature string i.e. "image_header_t" and it has to be appended at the end of the firmware data blob. Please let me know your views or how PKI implementation can be best done. I am planning to add the Digital signature at the end of the firmware data blob before generating the header. We shall be updating the boot-loader and shall distribute the source code with our product. > If I own the hardware, I > have every right to run any software I like on it. Due the nature of the product this is possible but than again the warranty would void if some one updates the software by themselves. Best Regards, rohit sharma -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/