Artifact verification is ignored if there are no keys

We have enabled artifact validation with keys in our Mender configuration:

    "ArtifactVerifyKeys": [
        "/data/certstore/artifact-verify-key.pem",
        "/data/certstore/artifact-verify-key2.pem"
    ],

The keys are stored in the /data partition (which is read-write) so they can be updated. One of the keys might be missing in some cases if there is a single key currently in use. But there should always be at least one.

We have also tested the case where the two keys are missing (a possible attack scenario where someone manages to delete the keys). In this case, it seems the verification is not done (since there is no key), and the artifact is installed anyways.

We see errors about keys, but that doesn’t stop the installation:

INFO[0002] config: error reading artifact verify key from /data/certstore/artifact-verify-key.pem 
INFO[0002] config: error reading artifact verify key from /data/certstore/artifact-verify-key2.pem 
INFO[0002] No public key was provided for authenticating the artifact 

or with a signed artifact:

INFO[0002] config: error reading artifact verify key from /data/certstore/artifact-verify-key.pem 
INFO[0002] config: error reading artifact verify key from /data/certstore/artifact-verify-key2.pem 
INFO[0002] No public key was provided for authenticating the artifact 
WARN[0002] Installer: Installing signed artifact without verification as verification key is missing 

We expected that it would be rejected if there are keys declared in the configuration file, but none of them validates the artifact (including if no key exists at all). Otherwise, the security of the verification keys is somewhat easily defeated in our case.

The documentation seems to agree with this interpretation:

https://docs.mender.io/artifact-creation/sign-and-verify

If the Mender Client is configured to enable signature verification (through the ArtifactVerifyKey(s) option), it will reject any unsigned Artifacts. This is necessary because otherwise an attacker could simply inject unsigned Artifacts to bypass the signature verification.

but this is not what happens in this case.

Hi @pulkomandy,

Thanks for reaching out! I think the line of thinking needs to extend a bit beyond missing keys here. You state that the attack vector is:

“manages to delete keys that are used to verify signature”, which implies that the attacker has gained write access to the persistent data on the device anyways. In that case, the actual attack as I understand it, is in fact:

“attacker can modify arbitrary information on the device”, and once that is archieved, the signature verification is of no use anymore already. The attacker could just disable verification by modifying the configuration file, or even skip the deployment process completely by dropping files directly on the storage.

So as I understand it, the point to be made is: as long as a devices integrity is unharmed (including keys and configuration), the signature verification keeps it intact. If a device is already compromised, signature verification is effectively disabled.

Greets,
Josef