[U-Boot-Users] Secure Firmware + Firmware Upgrade?

[Rohit Sharma <rohits79@gmail.com>]

On Mon, 05 Jun 2006 14:27:25 +0530, Wolfgang Denk <wd@denx.de> wrote:

> In message <op.tange7swdfxu59@sys.t-mobile.de> 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/