[Lvfs-announce] Peripheral device cryptographic verification metadata

Hi all,

Some LVFS protocols indicate the firmware contents are signed, for
instance com.logitech.unfyingsigned is only used for hardware that
does cryptographic verification of the firmware contents using a
vendor public key. Some protocols we know are unsigned due to the
design of the protocol, or the expected capabilities of the device,
for instance com.microsoft.uf2 =E2=80=93 none of the devices are capable of
much more than CRC16 or MD5, and certainly not fast enough to
implement anything strong like AES or RSA-2048.

Some update protocols just transport the image to the target device
and make no guarantee of the device firmware validation behaviour.
Such =E2=80=9Cgeneric=E2=80=9D protocols include NVMe, ATA, Redfish, DFU an=
d many
others =E2=80=93 probably also including UEFI UpdateCapsule =E2=80=93 but s=
ee below.

We=E2=80=99ve decided for these generic =E2=80=9Ctransport=E2=80=9D protoco=
ls to allow both
fwupd quirks and the LVFS firmware to define if the device supports
signed updates. The device integrity metadata can be set as part of
the metainfo.xml file at upload time or set from the LVFS web console
post-upload. The metadata is optional, but recommended. If omitted,
the device firmware is indicated as neither signed or unsigned, and
nothing is shown in the CLI tools.

To do this, add this to the metainfo file:
<custom>
<value key=3D"LVFS::DeviceIntegrity">some-value-here</value>
</custom>

The allowed values for LVFS::DeviceIntegrity are:

=E2=80=A2 signed : The firmware payload is verified on-device the payload
using strong cryptography such as RSA-2048, AES or ECC. It is usually
not possible to modify or flash custom firmware not provided by the
vendor.

=E2=80=A2 unsigned: The firmware payload is unsigned possibly with a checks=
um,
but it is possible to modify and flash custom firmware.

Note: If the device is doing XTEA, CRC32 or some other checksum for
validation then it is considered unsigned, even if the hashing
mechanism is secret or obfuscated. In this instance =E2=80=9Csigned=E2=80=
=9D means
that the device is doing cryptographically strong checks on either the
deployment of the update, or on every boot.

At the moment we=E2=80=99re **not** adding this metadata for firmware deplo=
yed
using UEFI UpdateCapsule, although this might change in the future.
When, and if it does change, I=E2=80=99ll send some more detailed instructi=
ons
about the requirements (e.g. BootGuard policy, OpenTitan, etc) and
some more specific advice. For UEFI Capsule updates please do not set
LVFS::DeviceIntegrity at all at the moment.

If you=E2=80=99re unsure about anything (or if you want this information se=
t
client side in the quirk files), please ask me offlist and I=E2=80=99m happ=
y
to give advice as required.

Thanks,

Richard.