[U-Boot-Users] Secure Firmware + Firmware Upgrade?
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
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
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
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
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
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
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
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
participants (3)
-
Rohit -
Rohit Sharma
-
Wolfgang Denk