use only u-boot default environment

[giuliodominutti]

What I'm trying to do:

I want to close the u-boot shell access to a normal user. I want that a user if need to change something in env has to modify it directly in the source code of u-boot.

Now I'm starting from sd, and I had previously loaded u-boot with a modified envionment (I added a random string try = XYZ) and I saved it.

Now in u-boot I added

#define CONFIG_ENV_IS_NOWHERE

#undef CONFIG_ENV_IS_IN_MMC

Without undef command I cant build the image.

With this configuration now I when stop u-boot I can still read old values like "try = XYZ". I'm not able to delete or edit previously stored variables.

What is my problem: I don't want to see old variables, because this mean that someone can take my sd change only the environment and load it's new variables. This for example can break the first command executed because u-boot seems to me not to overwrite it's default values if it's already defined.

Someone has a valid method to suggest?

with: "env default -a" i can load default env, but again if I set this as first command to be executed, I can't be sure someone else will change it.

As a sub question I'm also interested to understand if it's possible to authenticate and/or encrypt the environment? (also a yes/no answer is well accepted) (in environment.h I found CONFIG_ENV_AES, but  I can't find an explanation about this)

Thanks in advance

[giuliodominutti]

I already found the perfect response to first question. It was my mistake I had defined that command in uboot with the flag setted in read only. ( It was very strange that without a specified address for env it was able to find it )

Still remains the last question. It is possible to authenticate and/or encrypt the u-boot environment?

Thanks and sorry for previously dumb error.

[Carlos_Musich]

Hi Giulio,

yes, there are many authentication and encryption references, you can find internal NXP references as external. There is also the option of using High Assurance Boot (HAB) component of the ROM which protects against the potential threat of attackers modifying areas of code or data in programmable memory to make it behave in an incorrect manner. The HAB also prevents attempts to gain access to features which should not be available. You can fin HAB information on chapter 8 of Reference Manual.

Please see below some references:

Encrypted U-boot Example 

Encrypted boot loader on SabreSD i.MX6q board 

Encrypt / Decrypt data from uboot using CAAM 

Secure boot (with NXP tools) · inversepath/usbarmory Wiki · GitHub 

Multi-stage Secure Boot in iMX6 through SPL & u-boot.img 

Regards,
Carlos

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[giuliodominutti]

Thanks for your reply, unfortunately I already sow that link, but maybe I need to explain better my problem:
I was already capable to close the board ad start a u-boot signed & encrypted. I'm also able to sign (only sign) both a kernel and a dtb. Now I want to close the shell access set an environment of boot that checks the signs of all images. and after authentication is checked it start kernel. I understand the use of the hab_api to verify images and now I want to build a chain of step that verifies all images utilized. for this reason I'm trying to not give user access to environment. With access an user can eliminate an authentication step.

At the moment the best idea I had is to use the default environment, don't give access to env at user and use only authenticated bootscript to change environment variables.

What i want to understand now is, there is a better way to do this thing? (the environment can be signed?) and i only authenticate kernel and device tree, can I also encrypt them? (and how can i then decrypt them with uboot?)

[Carlos_Musich]

Hi Giulio,

I am sorry for the long time. Please see below some conclusions of experts:

1. The signing is not possible due of this u-boot env tutorial [1] which explains how the env is kept in flash (as a binary) vs how is kept in RAM (as a hashtable totally different comparing with the binary).

The signature is made offline and compared at runtime, so the data being maintained different in the RAM compared with the one from flash, this will make signing impossible. 

But also, I found out that at the beginning of the u-boot env a CRC is maintained and calculated. So if a hacker will take the SD card and try to change some env variables, those will be ignored by u-boot (because CRC will be different) and will use the default one (hardcoded into u-boot code). Is true, a hacker can calculate also the CRC…but at least is safer than nothing.

2. The encryption was possible some time ago via an u-boot specialized tool, but right this support is deprecated/removed due of some vulnerabilities. Details can be found out here [2]. This tool has been deprecated since v2017.09 and the support for this tool was removed in the following commit [3].

[1] https://nnc3.com/mags/LJ_1994-2014/LJ/246/11725.html

[2] Vulnerability Note VU#166743 - Das U-Boot AES-CBC encryption implementation contains multiple vulner... 

[3] [U-Boot] env: Remove CONFIG_ENV_AES support - Patchwork 

Regards,
Carlos

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------