4 ms·

How do you handle key and/or certificate storage at the client side? Depending on the threat model, the update verification step can be subverted.

by Cyph0n 9y ago

geofft 9y ago
You install manually / out-of-band (in my old job, you installed by copying to a USB stick from a desktop machine), and the updater runs within the OS, because you can safely write to the unused partition while the OS runs. So it has the full set of functionality that you ship with your OS - Python, OpenSSL, GPG, whatever. You're not downloading the update from the bootloader or anything (which would take too long). Once the device has been installed, there is always at least one working partition on the device - the partition that was last booted. So you don't need a minimal recovery partition or anything. (You could build a recovery command-line option in, if you want, but it's just a custom way of booting the normal partition.)
- Cyph0n 9y ago
  How do you protect keys and/or certificates stored on the device from being exfiltrated or replaced by an adversary?
  - wmf 9y ago
    Unless you have a TPM or something you just don't; this is an unsolvable problem in general.
  - geofft 9y ago
    For all of my use cases, either physical access counts as game over and is out of the threat model, or we're using Secure Boot for verifying the bootloader and/or TPMs for keeping secrets, at which point this is a problem with known solutions that aren't specific to image-based updates. If you're using Secure Boot with read-only images, one thing to try is dm_verity, which is how Chrome OS solves this problem - it's a Merkle hash of the entire block device that's checked lazily as blocks are accessed. If a block has been tampered with, you can configure dm_verity to either panic the system or return an I/O error for that block. (Or you can just read the entire image and verify it up front at the cost of slower boot time.) In particular, for all my use cases, there's already some mechanism for the device gaining a secure channel to the rest of the infrastructure, so if you're worried about keeping updates secret (which you may or may not be!), just protect updates by that mechanism.
eystein 9y ago
Disclaimer: I work on the Mender project. Signing and verification in Mender is covered here: https://docs.mender.io/artifacts/signing-and-verification https://docs.mender.io/artifacts/signing-and-verification

How do you handle key and/or certificate storage at the client side? Depending on the threat model, the update verification step can be subverted.

by Cyph0n 9y ago

How do you handle key and/or certificate storage at the client side? Depending on the threat model, the update verification step can be subverted.

geofft 9y ago

You install manually / out-of-band (in my old job, you installed by copying to a USB stick from a desktop machine), and the updater runs within the OS, because you can safely write to the unused partition while the OS runs. So it has the full set of functionality that you ship with your OS - Python, OpenSSL, GPG, whatever. You're not downloading the update from the bootloader or anything (which would take too long). Once the device has been installed, there is always at least one working partition on the device - the partition that was last booted. So you don't need a minimal recovery partition or anything. (You could build a recovery command-line option in, if you want, but it's just a custom way of booting the normal partition.)

Cyph0n 9y ago
How do you protect keys and/or certificates stored on the device from being exfiltrated or replaced by an adversary?
- wmf 9y ago
  Unless you have a TPM or something you just don't; this is an unsolvable problem in general.
- geofft 9y ago
  For all of my use cases, either physical access counts as game over and is out of the threat model, or we're using Secure Boot for verifying the bootloader and/or TPMs for keeping secrets, at which point this is a problem with known solutions that aren't specific to image-based updates. If you're using Secure Boot with read-only images, one thing to try is dm_verity, which is how Chrome OS solves this problem - it's a Merkle hash of the entire block device that's checked lazily as blocks are accessed. If a block has been tampered with, you can configure dm_verity to either panic the system or return an I/O error for that block. (Or you can just read the entire image and verify it up front at the cost of slower boot time.) In particular, for all my use cases, there's already some mechanism for the device gaining a secure channel to the rest of the infrastructure, so if you're worried about keeping updates secret (which you may or may not be!), just protect updates by that mechanism.

eystein 9y ago

Disclaimer: I work on the Mender project. Signing and verification in Mender is covered here: https://docs.mender.io/artifacts/signing-and-verification https://docs.mender.io/artifacts/signing-and-verification