SmartCard loss might eventually happen, but the card locks itself after 3 failed attempts to enter the pin. Eventually the public key should be removed from the static keyring

An attacker might try to trick a devop into signing an incorrect update, e.g. build server is compromised. If we now the hash of what has been signed, we can blacklist that hash and distribute it with rescue system update. Mind that valid rootfs with exploitable security flaws can be installed eternally as well, so they should be blacklisted too.

Signing requires entering the pin. Only production/fieldtest updates shall use a SmartCard to sign. Daily / (Testing?) builds still use a private key stored locally on the builder.

SmartCards keys can be backed up / cloned by generating private/public keys on the host computer then transferring the private key to several cards. Printouts of the private key can be used as backups.

To rotate keys they need to be added/removed from the keyring in the rescue system. Using a new key requires that the latest rescue system is installed on the target. If the rescue system is outdated, does not contain the new key, upgrades of the rootfs signed with the new key will fail. In this case users must install interim versions that are signed with a key known to the legacy rescue-system and still trustworthy.

OpenSSL might come to mind first, but GnuPG offers the same cryptography algorithms. Feature wise both offer what we need, while GnuPG - IMHO - is far easier to use. Many Linux distributions use it for signing their updates. So we are not doing much wrong in deciding in favor of GnuPG. GnupG 1.x is designed for embedded, it is hard to beat footprint wise, see #Image-footprint. #Image-footprint

- RSA keys of 1024, 2048, 3072 and 4096 bit are supported.- store three RSA key pairs. All keys use the same identity but are used for different purposes: authentication, encryption and signing.- tamper resistant smart card. Nitrokey Start is implemented in the microprocessor.

Both work out of the box. Nitrokey is about 30% smaller. Nitrokey offers the same features based on OSS as kernel concepts does.

Both designs rely on BasicCard, with an with OpenGPG applet. BasicCard shall also be the basis for the German Health Card. NitroKey Pro embeds a BasicCard and a USB MCU serving as a card reader, in a compact form factor. Mind that the reader is part of security concept, since it has access to the pin. It's probably easier to attack then the card itself.Discussion NitroKey/KernelConcepts.

The server hosting the upgrade instructions is part of the security design. If these packages are served by our update server then that server must use https and a valid x509 certificate. Evtl. it is sufficient to sign the packages.gz, but that's not discussed here.

TLS still provides secrecy what patches are installed and what vulnerabilities the client still has while installing the update.

It's easier to generate x509 certificates using OpenSSL. It's probably easier to buy a certificate for the keyserver from a certification provider. But we can also create our own root certificate and install the public key in our firmware images and rescue system. End users will not use those servers directly, since those are the only used by our firmware.

The self-signed certificate warning is not visible to users unless the surf explicly to those server, in that case we can advertise our CA root key.This has the advantage that we can use real short expiry periods on all certificates (e.g. 4 weeks) and rotate them every 2 weeks which limits the amount of damage a stolen certificate can do.

Buying a certificate has the advantage that we don't have to serve the ca structures ourselves.

Controlling the builder allows an attacker to inject his own code during regular builds. The final output will be signed as a regular update. Few cues prevent such an attack

testing will verify that patches are included in the final outputIt's not enough to replace the rootfs by it's own malicious rootfs. The output still has to pass testing department, open bugs are retested, that means all patches must be present.

recipes and builder scripts are under version controlAn attacker needs to the builder recipes after the build is started and revert them before the build is complete, otherwise they risk discovery

rootfs must be hosted from the update server, not random serverIf an image is signed it can't be taken back easily. An attacker having a copy of such image, needs to control update server too, since the address of the update server is hard-coded in the target, and they can only be installed through USB otherwise. (*)

Private keys can not be stolen, since it doesn't leave the secure token card. But this doesn't solve the problem what actually gets signed. Good care has to be taken to make the builder server as secure as possible.

no password logins

building 3rd party software risky (yocto)

(*) If we are aware of such images we can blacklist the hashes of such images in the rescue-system, without revoking the key itself

An attacker can downgrade to a previous version containing a known vulnerability¶

I a previous FW had security flaws might create an upgrade instruction. Since the FW is signed with a valid key, signature verification will not stop from this. Once the legacy FW is installed the known security issue can be exploited

The builder will sign updates using GnuPG key pair without password. The builder key is signed by a trusted key, that is kept secure. That trusted key is best stored on a secure SmartCard which is readily supported by GnuPG. The public key of the trusted entity is exported and included in the rescue system initramfs.

In case the builder machine is compromised its key must be revoked, and replaced with a new key. The rescue system will fetch the current public builder key from the key server. This is important since it allows existing installations to verify updates, that are signed with the new un-compromised builder key. Revocation of the builder key is done by uploading a revocation certificate onto the key server.

Installations of updates start with by downloading the current builder key, which can be looked up on the key server by a well known user id, e.g. email address.

The key server must be trusted. An attacker that gained the builder keys, can use them forever if he suppresses their revocation. This can be achieved by impersonating the key server, e.g. through DNS spoofing. Hence the key server itself must use a valid certificate. Key servers use the Horowitz key protocol (hkp), which is a tiny layer on top of http, hence using TLS shouldn't be an issue.