[U-Boot] U-Boot: Verified Boot: signed configuration and mix and match attack

[U-Boot] U-Boot: Verified Boot: signed configuration and mix and match attack

[Johann Neuhauser]

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 at 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 at 1 - fdt at 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
 

[U-Boot] U-Boot: Verified Boot: signed configuration and mix and match attack

[Simon Glass]

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 at 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 at 1 - fdt at 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

[U-Boot] U-Boot: Verified Boot: signed configuration and mix and match attack

[Johann Neuhauser]

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 at 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 at 1 - fdt at 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

[U-Boot] U-Boot: Verified Boot: signed configuration and mix and match attack

[Simon Glass]

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 at 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 at 1 - fdt at 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