[U-Boot] U-Boot: Verified Boot: signed configuration and mix and match attack
Dear U-Boot devs,
I've setup verified boot on a imx6 board and want to protect my device against the "mix and match" attacks mentioned in "doc/uImage.FIT/signature.txt". That's why I have only implemented signed configurations and no signed images as in doc/uImage.FIT/signed-configs.its. My public key in my embedded fdt has the property required = "conf";
Booting a signed config with "bootm ${loadaddr}#conf@1" and an embedded public key required for configurations does work as expected and do fail to boot if I modify the config, image, hash, signature and so on.
If I boot any fit image(signed and unsigned) for example with "bootm ${loadaddr}:kernel@1 - fdt@1" to select the subimages directly, I could boot every image combination without signature verification although a signature is enforced for a configuration.
Is this the expected behavior?
I thought if I had set the public key in in the embedded fdt as required for configurations, bootm does only boot signed configurations and no subimages directly...
Best regards
Johann Neuhauser DH electronics GmbH
Hi Johann,
On 31 July 2018 at 02:22, Johann Neuhauser jneuhauser@dh-electronics.de wrote:
Dear U-Boot devs,
I've setup verified boot on a imx6 board and want to protect my device against the "mix and match" attacks mentioned in "doc/uImage.FIT/signature.txt". That's why I have only implemented signed configurations and no signed images as in doc/uImage.FIT/signed-configs.its. My public key in my embedded fdt has the property required = "conf";
Booting a signed config with "bootm ${loadaddr}#conf@1" and an embedded public key required for configurations does work as expected and do fail to boot if I modify the config, image, hash, signature and so on.
If I boot any fit image(signed and unsigned) for example with "bootm ${loadaddr}:kernel@1 - fdt@1" to select the subimages directly, I could boot every image combination without signature verification although a signature is enforced for a configuration.
Is this the expected behavior?
I thought if I had set the public key in in the embedded fdt as required for configurations, bootm does only boot signed configurations and no subimages directly...
I don't think there is any restriction on that at the moment. You are explicitly asking to boot particular images rather than a config. So I suppose it would be odd if U-Boot tried to enforce a config. Are you thinking it should try to find a config that has those images in it? But why not just specify the config to bootm?
Bear in mind also that users don't have access to the U-Boot command line when using verified boot, so they wouldn't be able to type this command.
Regards, Simon
Hello Simon,
Dear U-Boot devs,
I've setup verified boot on a imx6 board and want to protect my device
against the "mix and match" attacks mentioned in "doc/uImage.FIT/signature.txt".
That's why I have only implemented signed configurations and no signed
images as in doc/uImage.FIT/signed-configs.its.
My public key in my embedded fdt has the property required = "conf";
Booting a signed config with "bootm ${loadaddr}#conf@1" and an
embedded public key required for configurations does work as expected and do fail to boot if I modify the config, image, hash, signature and so on.
If I boot any fit image(signed and unsigned) for example with "bootm
${loadaddr}:kernel@1 - fdt@1" to select the subimages directly, I could boot every image combination without signature verification although a signature is enforced for a configuration.
Is this the expected behavior?
I thought if I had set the public key in in the embedded fdt as required for
configurations, bootm does only boot signed configurations and no subimages directly...
I don't think there is any restriction on that at the moment. You are explicitly asking to boot particular images rather than a config. So I suppose it would be odd if U-Boot tried to enforce a config. Are you thinking it should try to find a config that has those images in it?
No, I expected that I cannot boot sub images directly if there is a required public key for a configuration. After a dive into the bootm source I think this is not easily possible to enforce this behavior.
But why not just specify the config to bootm?
At first I wanted to use a simple boot script wrapped in a fit image (unsigned) and have only the needed commands enabled in U-Boot. Now I switched to a signed U-Boot script as boot script and can be sure that this one gets not tampered. The only bad thing is here that the source command does only have support for fit sub images and I have to sign the config and the image of my system image if I had a required certificate for images and configs.
Probably this behavior should be mentioned in the doc.
Many thanks for the clarification.
Best regards Johann Neuhauser
Hi Johann,
On 2 August 2018 at 07:20, Johann Neuhauser jneuhauser@dh-electronics.de wrote:
Hello Simon,
Dear U-Boot devs,
I've setup verified boot on a imx6 board and want to protect my device
against the "mix and match" attacks mentioned in "doc/uImage.FIT/signature.txt".
That's why I have only implemented signed configurations and no signed
images as in doc/uImage.FIT/signed-configs.its.
My public key in my embedded fdt has the property required = "conf";
Booting a signed config with "bootm ${loadaddr}#conf@1" and an
embedded public key required for configurations does work as expected and do fail to boot if I modify the config, image, hash, signature and so on.
If I boot any fit image(signed and unsigned) for example with "bootm
${loadaddr}:kernel@1 - fdt@1" to select the subimages directly, I could boot every image combination without signature verification although a signature is enforced for a configuration.
Is this the expected behavior?
I thought if I had set the public key in in the embedded fdt as required for
configurations, bootm does only boot signed configurations and no subimages directly...
I don't think there is any restriction on that at the moment. You are explicitly asking to boot particular images rather than a config. So I suppose it would be odd if U-Boot tried to enforce a config. Are you thinking it should try to find a config that has those images in it?
No, I expected that I cannot boot sub images directly if there is a required public key for a configuration. After a dive into the bootm source I think this is not easily possible to enforce this behavior.
It should be easy enough to change fit_image_load() to return an error if fit_uname_configp doesn't have a config.
But why not just specify the config to bootm?
At first I wanted to use a simple boot script wrapped in a fit image (unsigned) and have only the needed commands enabled in U-Boot. Now I switched to a signed U-Boot script as boot script and can be sure that this one gets not tampered. The only bad thing is here that the source command does only have support for fit sub images and I have to sign the config and the image of my system image if I had a required certificate for images and configs.
I don't quite get this, sorry. What is a FIT sub-image? Do you mean a FIT image? You can actually sign individual images if you want to, but as the docs mention, this is not fully secure since it is vulnerable to mix-and-match attacks.
But if do want to group images together, so that only certain ones can be used together, then a FIT config is the mechanism for that. You must sign each config simple because otherwise there is nothing protecting against the attack.
Probably this behavior should be mentioned in the doc.
Please send a patch.
Many thanks for the clarification.
You are welcome. But I suspect I have misunderstood this in some way, so let me know :-)
Regards, Simon
participants (2)
-
Johann Neuhauser -
Simon Glass