[ipxe-devel] [ipxe] [crypto] New command imgdigest, verify image using digest (#34)

[Thomas Bakketun]

Example use case:

* DHCP server issues filename = http://10.0.1.1/boot.ipxe
* The subnet is isolated and contains only trusted servers. Thus we can trust the content of boot.ipxe without any signatures.
* boot.ipxe loads images from a different server. We can't trust this data, maybe because the connection is not secure.
* These images should never change. New images are published at different URLs.
* These images are then verified using imgdigest with an embedded digest.
* Thus, the images are essentially included in boot.ipxe, and can be trusted just as much as boot.ipxe it self.

When an image is updated:
* A new image is produced somewhere and it's hash is computed.
* We somehow decides if the new images hash is trustworthy.
* The boot.ipxe is updated with the new URL and hash.

Using imgverify instead:
* We need a signing certificate and private key.
* The private key must be kept secret.
* ipxe must be have some way of knowing if the certificate is trusted, probably by embedding it.
* When an image is changed we need access to the private key in order to create a new signature.
* We don't have to update boot.ipxe, but we do need to store the new signature file somewhere.

Often you might want to use both imgverify and imgdigest. The first the script is verified using imgverify, everything else using imgdigest. This is useful since the calculating the hashed don't require access to a private key. This is can done on a build server. If we don't trust the build server anymore, we can simply stop signing the hashes produced by it.

---
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/34#issuecomment-78995776
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20150313/ffaa6107/attachment.htm>