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

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

[Rohit]

Hello,

I know this has been asked directly/indirectly before but i need to
know if my approach is correct or not? Any correction or opinion are
highly appreciated so please feel free to correct me.

My requirement is to
(1) Load and boot an image which is signed i.e. before the image could
be booted i need to check for the authenticity. This is to support
image for a given vendor only
(2) Support Firmware Upgrade

Following is my approach:

The flash memory segment shall be virtually divided into four partitions
(1) Boot-bit (type read-write)
(2) U-Boot image (type read-only)
(3) Boot Script Image (type read-only)
(4) Firmware Image (type read-write)

The boot-delay environment variable shall be set to 0 so boot process
could not be manually overridden,
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.

The very first thing boot-script-image shall check to see will be if
the Boot-bit is set or not

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)
If the check is successfull the image shall than be decrypted,
expanded and executed (bootm)

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
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
reset CPU


Best Regards,
rohit

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

[Wolfgang Denk]

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

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

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


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Don't tell me how hard you work.  Tell me how much you get done.
                                                     -- James J. Ling

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

[Rohit Sharma]

On Sat, 03 Jun 2006 01:54:49 +0530, Wolfgang Denk <wd@denx.de> 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/

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

[Wolfgang Denk]

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

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

> Am sorry if i wasn't clear in letting you explain the same before. Do yo> u  > 
> still feel that its possible
> to tamper and by pass the security unless ofcourse if boot-script-image > is  > 
> manipulated?

Yes of course it is possible to boot my own custom images. There  are
several  ways  to  do  this.  And  I  intentionally  avoid  the  term
"tampered" here, because it does not apply. If I own the hardware,  I
have every right to run any software I like on it.



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Actual war is a very messy business. Very, very messy business.
	-- Kirk, "A Taste of Armageddon", stardate 3193.0

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

[Rohit Sharma]

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/

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

[Rohit Sharma]

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/

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

[Wolfgang Denk]

In message <op.tanxj1fkdfxu59@sys.t-mobile.de> you wrote:
> 
> 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.

You could write the signature to a separate file and use a multi-file
image to combine image and signature.

> Due the nature of the product this is possible but than again the warranty
> would void if some one updates the software by themselves.

The same is true if someone loads and runs  an  image  that  was  not
officially  released  -  so why goong through all this effort just to
make it more difficult to someone who *wants* to ignore the warranty?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Making files is easy under  the  UNIX  operating  system.  Therefore,
users  tend  to  create  numerous  files  using large amounts of file
space. It has been said that the only standard thing about  all  UNIX
systems  is  the  message-of-the-day  telling users to clean up their
files.                            -- System V.2 administrator's guide

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

[Rohit Sharma]

On Mon, 05 Jun 2006 18:39:06 +0530, Wolfgang Denk <wd@denx.de> wrote:

> In message <op.tanxj1fkdfxu59@sys.t-mobile.de> you wrote:
>>
>> 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.
>
> You could write the signature to a separate file and use a multi-file
> image to combine image and signature.

Thanks for the suggestion!!!

>> Due the nature of the product this is possible but than again the  
>> warranty
>> would void if some one updates the software by themselves.
>
> The same is true if someone loads and runs  an  image  that  was  not
> officially  released  -  so why goong through all this effort just to
> make it more difficult to someone who *wants* to ignore the warranty?

Due to the very nature any corrupted image can be actually turn out to
be futile for the very person. Its for their safety only.

Thanks for your kind help.

Best Regards
rohit


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/