meta-swupdate: generation of signed update images

[George McCollister]

Is anyone working on (or planning) changes to meta-swupdate to generate images using the new signature support?

I'll need these changes and will probably do it myself if no one gets to it first.

This is a rough list of items that need to be worked on:

Add variable which enables signing

Add variable which specifies signing key

Install the public key which is used for verifying images

Generate hashes for images and put the hashes in sw-description (this may be a bit tricky, anyone have any ideas on best approach here?)

Sign sw-description placing output in sw-description.sig

Include sw-description.sig in cpio archive

Include debug key for testing? (meta-intel-iot-security/meta-integrity does this for it's keys)

Update README

Regards,

George McCollister

[Stefano Babic]

Hi George,

On 19/04/2016 21:15, George McCollister wrote:
> Is anyone working on (or planning) changes to meta-swupdate to generate
> images using the new signature support?

Yes, next step is to enhance meta-swupdate to generate automatically the
.swu image with inclusion of signature and hashes.

I did some hacks to test swupdate, nothing for mainline. This work must
be done. Of course, these changes are planned, but I am now busy with
another project and I had to postpone this. Glad that you want to
contribute on this.

>
> I'll need these changes and will probably do it myself if no one gets to
> it first.
>
> This is a rough list of items that need to be worked on:
> Add variable which enables signing

+1

Variable should be set in the recipe for the .sw, that is the one that
inherits swupdate class.

> Add variable which specifies signing key

I thought this is bound to MACHINE and we do not need any variable for it.

> Install the public key which is used for verifying images

This should be not part of meta-swupdate. In fact, where keys are stored
is the most sensible issue. Keys can be stored outside rootfs, for
example on another storage with raw access. IMHO storing public key
should be done in the BSP layer.

> Generate hashes for images and put the hashes in sw-description (this
> may be a bit tricky, anyone have any ideas on best approach here?)

This is my idea how I would like to implement it.

We need to extend swupdate class with a function to insert hashes.
Because swupdate supports multiple parsers (not only libconfig), a
native tool based that parses sw-description and adds attributes cannot
be unique, and we need one of them for each supported parser. And user
can write his own parser using LUA. This is not practicable.

I thought about a type of annotation - I explain with an example:

{
filename = "core-image-full-cmdline-beaglebone.ext3";
device = "/dev/mmcblk1p2";
type = "raw";
@generated-hash;
}


We could write a python function that reads sw-description. Maybe we
have (if there are not better ideas) to rule that the annotation should
follow the filename. That simplifies the work for the function: the hash
to be inserted is always related to the last "filename" entry found.

Or we remove the bind and the annotation should have the name of the image:

{
filename = "core-image-full-cmdline-beaglebone.ext3";
device = "/dev/mmcblk1p2";
type = "raw";
@core-image-full-cmdline-beaglebone.ext3;

}


> Sign sw-description placing output in sw-description.sig

Right, this is easy

> Include sw-description.sig in cpio archive
> Include debug key for testing? (meta-intel-iot-security/meta-integrity
> does this for it's keys)

How are keys managed ? I have not seen.

IMHO keys should be supplied outside meta-swupdate.

> Update README

I would say that documentation in meta-swupdate must be *strongly* enhanced.

In this list for meta-swupdate, I would also add support for systemd.

Best regards,
Stefano babic

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[George McCollister]

On Wed, Apr 20, 2016 at 2:39 AM, Stefano Babic <sba...@denx.de> wrote:
> Hi George,
>
> On 19/04/2016 21:15, George McCollister wrote:
>> Is anyone working on (or planning) changes to meta-swupdate to generate
>> images using the new signature support?
>
> Yes, next step is to enhance meta-swupdate to generate automatically the
> .swu image with inclusion of signature and hashes.
>
> I did some hacks to test swupdate, nothing for mainline. This work must
> be done. Of course, these changes are planned, but I am now busy with
> another project and I had to postpone this. Glad that you want to
> contribute on this.
>
>>
>> I'll need these changes and will probably do it myself if no one gets to
>> it first.
>>
>> This is a rough list of items that need to be worked on:
>> Add variable which enables signing
>
> +1
>
> Variable should be set in the recipe for the .sw, that is the one that
> inherits swupdate class.
>
>> Add variable which specifies signing key
>
> I thought this is bound to MACHINE and we do not need any variable for it.

If we make it a variable it can be set in numerous places (local.conf,
image recipe, etc) and can be overridden with machine specific keys if
desired.

>
>> Install the public key which is used for verifying images
>
> This should be not part of meta-swupdate. In fact, where keys are stored
> is the most sensible issue. Keys can be stored outside rootfs, for
> example on another storage with raw access. IMHO storing public key
> should be done in the BSP layer.

This is a public key so privacy isn't a concern. While in many cases
you don't want someone to change the key and install an unsigned
update we are relying on swupdate to enforce the signature
verification. It makes no sense (security wise) for instance to
install the key in ROM and then to install swupdate in writable flash.
For this reason I see no security problem with installing the public
key along side swupdate.

If your concern is that your rootfs is going to be in say a squashfs
and you _want_ the user to be able to easily change the key I suppose
we could add a variable to disable installation of the key and it
could be handled separately. This problem could also be solved using a
R/W overlay.

>
>> Generate hashes for images and put the hashes in sw-description (this
>> may be a bit tricky, anyone have any ideas on best approach here?)
>
> This is my idea how I would like to implement it.
>
> We need to extend swupdate class with a function to insert hashes.
> Because swupdate supports multiple parsers (not only libconfig), a
> native tool based that parses sw-description and adds attributes cannot
> be unique, and we need one of them for each supported parser. And user
> can write his own parser using LUA. This is not practicable.

Agreed

>
> I thought about a type of annotation - I explain with an example:
>
> {
> filename = "core-image-full-cmdline-beaglebone.ext3";
> device = "/dev/mmcblk1p2";
> type = "raw";
> @generated-hash;
> }
>
>
> We could write a python function that reads sw-description. Maybe we
> have (if there are not better ideas) to rule that the annotation should
> follow the filename. That simplifies the work for the function: the hash
> to be inserted is always related to the last "filename" entry found.
>
> Or we remove the bind and the annotation should have the name of the image:
>
> {
> filename = "core-image-full-cmdline-beaglebone.ext3";
> device = "/dev/mmcblk1p2";
> type = "raw";
> @core-image-full-cmdline-beaglebone.ext3;
> }
>

How about this? It should be less dependent on the format:

{
filename = "core-image-full-cmdline-beaglebone.ext3";
device = "/dev/mmcblk1p2";
type = "raw";

sha256 = "@core-image-full-cmdline-beaglebone.ext3";

}

>
>> Sign sw-description placing output in sw-description.sig
>
> Right, this is easy
>
>> Include sw-description.sig in cpio archive
>> Include debug key for testing? (meta-intel-iot-security/meta-integrity
>> does this for it's keys)
>
> How are keys managed ? I have not seen.

They have a variable IMA_EVM_KEY_DIR that defines the directory which
hold the keys.
If you are just doing testing/experimentation you can add the
following and skip key generation step:
IMA_EVM_KEY_DIR = "${IMA_EVM_BASE}/data/debug-keys"

Example keys might be less relevant since swupdate is using a simple
key pair rather than certificates.

If you care to read more about meta-integrity, look here:
https://github.com/01org/meta-intel-iot-security/tree/master/meta-integrity

[Stefano Babic]

Hi George,

On 22/04/2016 18:16, George McCollister wrote:
> On Wed, Apr 20, 2016 at 2:39 AM, Stefano Babic <sba...@denx.de> wrote:
>> Hi George,
>>
>> On 19/04/2016 21:15, George McCollister wrote:
>>> Is anyone working on (or planning) changes to meta-swupdate to generate
>>> images using the new signature support?
>>
>> Yes, next step is to enhance meta-swupdate to generate automatically the
>> .swu image with inclusion of signature and hashes.
>>
>> I did some hacks to test swupdate, nothing for mainline. This work must
>> be done. Of course, these changes are planned, but I am now busy with
>> another project and I had to postpone this. Glad that you want to
>> contribute on this.
>>
>>>
>>> I'll need these changes and will probably do it myself if no one gets to
>>> it first.
>>>
>>> This is a rough list of items that need to be worked on:
>>> Add variable which enables signing
>>
>> +1
>>
>> Variable should be set in the recipe for the .sw, that is the one that
>> inherits swupdate class.
>>
>>> Add variable which specifies signing key
>>
>> I thought this is bound to MACHINE and we do not need any variable for it.
>
> If we make it a variable it can be set in numerous places (local.conf,
> image recipe, etc) and can be overridden with machine specific keys if
> desired.

ok, normal Yocto behaviour.

>
>>
>>> Install the public key which is used for verifying images
>>
>> This should be not part of meta-swupdate. In fact, where keys are stored
>> is the most sensible issue. Keys can be stored outside rootfs, for
>> example on another storage with raw access. IMHO storing public key
>> should be done in the BSP layer.
>
> This is a public key so privacy isn't a concern.

Which public key should be part of meta-swupdate ? meta-swupdate is for
all targets, and if I or you deliver a public key, this is just for us.

> While in many cases
> you don't want someone to change the key and install an unsigned
> update we are relying on swupdate to enforce the signature
> verification. It makes no sense (security wise) for instance to
> install the key in ROM and then to install swupdate in writable flash.

Why not ? It does not depend on security, but on the production process.

The keys are part of the device and can be stored together with device
relevant data: serial number, mac address, and so on.

All this data can be written to a different storage as the one where
swupdate's rootfs is stored - I do not know, it depends on the project.
And the way to store can be different: for example, with SPI flashes is
not uncommon to flash a part of the device (with bootloader) before
soldering. Or the device's data are stored later in a controlled
test-equipment, where just the bootloader runs - and the bootloader has
not full access to the whole device.

Nevertheless, the use case you mention makes sense. You have keys in
ROM, and the user decides (with risks if there is just one copy on the
target) to let swupdate update itself. The running swupdate makes sure
that only a new verified swupdate can be installed, and there are no
issues if swupdate is a writable flash.

> For this reason I see no security problem with installing the public
> key along side swupdate.

It is not a security issue, but we cannot think that all projects work
at the same way. The customer/user decides himself where to store the
keys, and binding the keys to swupdate's rootfs seems to me a bad idea.

>
> If your concern is that your rootfs is going to be in say a squashfs
> and you _want_ the user to be able to easily change the key I suppose
> we could add a variable to disable installation of the key and it
> could be handled separately. This problem could also be solved using a
> R/W overlay.

My concern is that we cannot know all use cases, and moving the key in
swupdate's rootfs is just one use case.

Agree.

>
>>
>>> Sign sw-description placing output in sw-description.sig
>>
>> Right, this is easy
>>
>>> Include sw-description.sig in cpio archive
>>> Include debug key for testing? (meta-intel-iot-security/meta-integrity
>>> does this for it's keys)
>>
>> How are keys managed ? I have not seen.
>
> They have a variable IMA_EVM_KEY_DIR that defines the directory which
> hold the keys.
> If you are just doing testing/experimentation you can add the
> following and skip key generation step:
> IMA_EVM_KEY_DIR = "${IMA_EVM_BASE}/data/debug-keys"
>
> Example keys might be less relevant since swupdate is using a simple
> key pair rather than certificates.

Right.

Best regards,
Stefano Babic