Multiple public verification keys in mender.conf

General Discussions
1

Is it possible to include multiple public verification keys in the Mender configuration?

For example like this (that does not work):

{
  "ArtifactVerifyKey": "/opt/signatures/artifact-verify-key-20191015.pem",
  "ArtifactVerifyKey": "/opt/signatures/artifact-verify-key-20191112.pem",
  "RootfsPartA": "/dev/mmcblk1p2",
  "RootfsPartB": "/dev/mmcblk1p3"
}

This would make key rotation less strict, old keys could routinely be deprecated and upgrades would still be allowed to skip some minor updates.

1 Like
2

Not at the moment, no.

I do like the idea though!

3

Just want to follow up if there has been any progress in this area. It would be nice to see some mechanism to allow for intermediate key + revocation like x509/PKI/GPG subkeys. Is there anything in the future plan for this ?

4

hello @grandfield

thank you for your continued interest in Mender.
At the moment we do not support multiple keys in the configuration file.
Could you describe the use case you have in mind in detail, so we can bring it into discussion during the planing of a new release?

best regards,
peter

1 Like
5

Hi, thanks for the reply. The reason I mention a working/intermediate key setup is because a root key that defines a company’s identity is a very precious asset, and should be stored on a cryptokey / hsm. This key should only ever be accessed in rare circumstances. If this root key becomes a working key used to sign artifacts on a regular basis, then this will increase the chances of it being lost or stolen. Allowing devices on the field to trust this root key means that the working/intermediate key can be rotated or easily black listed in the event of loss or theft. It also means that devices running old software can install the latest updates form a mender server even if the working key has changed.

Another benefit to intermediate keys is the ability to avoid cumulative updates. With mender today for example if you sign artifact v1 with key1, and say v2 now tells the mender client that it will only trust artifacts signed with key2 from here on in, this means the v3 artifact will need to be signed with k2. This means any client running v1 will not be able to update directly to v3 because it doesn’t trust k2.

1 Like
6

Ping @eystein

7

Indeed this would be a nice improvement, it would probably be better to support certificates rather than public keys for signature verification too (just like we do for client authentication with 2.5 and newer). To this end it should not be necessary to support multiple public keys (you can just sign several public keys that validates with the same chain of trust).

I have noted it but we do not have any timelines for implementing support for this. If it’s time-critical for you we would be happy to incorporate any pull requests for this or develop it in the shorter term as part of a development funding project. Feel free to reach out if either could be of interest!

8

+1.

I am here searching for the same thing.