Re: [RAUC] RAUC bundle encryption, design question

["Jan Lübbe" <jlu@pengutronix.de>]

Hi Evan,

thanks for starting this discussion!

On Mon, 2018-08-20 at 11:39 -0700, Evan Edstrom wrote:
> I am using RAUC for a commercial product, and one of the things we
> need to accomplish is to encrypt our update bundles. I've manually
> created an encrypted rauc bundle using a LUKS container. Once the
> container is opened it can be mounted like normal as a squashfs
> partition and used by RAUC.

A normal RAUC bundle looks (mostly) like this:
[ squashfs ][ CMS signature over hash of squashfs ]

I expect that your LUKS container wraps both:
[ LUKS header ][ LUKS encrpytion ( RAUC bundle ) ]

So you get symmetric encryption of whole bundle with a password (i.e. a
shared secret), right?

While this setup is pretty straight forward, I see some downsides:
- RAUC cannot read any information about the bundle before decryption
- With a single shared secret, there is no way to revoke a compromised
key (for example extracted from a single device in the field)

> This seems generally useful; if this is something you'd like to see in
> the project I'd be happy to contribute and submit a pull request. I
> wanted to seek your input before I begin about the proper scope for
> this, as it could be achieved in many different ways. Here are the two
> methods I've narrowed in on.
> 
> * Option 1:
> Provide an optional "decryption handler" for the user to implement
> which provides the bundle path and mount point. A user would implement
> their decrypt and mount steps as needed. If the config file defines
> this handler, the update process would essentially run the handler
> instead of r_mount_loop() in bundle.c.

r_mount_loop() only runs after reading and verifying the bundle
signature, so it would need a different layout than the one above.
Something like:
[ LUKS header ][ LUKS encrpytion ( squashfs ) ] CMS signature over hash
of LUKS header+encrypted data ]

> This gives a user the most flexibility as they're not locked into any
> particular encryption method or even bundle format. Bundle creation gets
> a little more tricky as there isn't a concept of handlers built in. Could have
> an optional argument which provides a mounted and empty bundle.

A squashfs is generated by using mksquashfs. The result would then be
copied into a fresh LUKS container. So creating encrypted bundles would
required root.

> * Option 2:
> Implement encryption support directly into RAUC as a compile option.
> This could create an encrypted bundle and decrypt and mount during
> install time.
> 
> This is much easier to use and allows easy encrypted bundle creation,
> but is quite a bit less flexible. It also adds a dependency, like
> cryptsetup, to the project.

I'd definitely prefer built-in encryption support. Mainly because:
- It can be integrated with the existing CMS-based signatures, so we
get support for multiple recipient devices with individual private
keys.
- It's easier to use (you don't need to write a handler).
- By using dm-crypt without LUKS, we can generate the encrypted bundle
without requiring root privileges (via OpenSSL).
- When using per device private keys, we can also store them in a TPM
or a PKCS#11 token/smartcard, so they can't be easily extracted.

> For either option, there is the possibility of inspecting a bundle
> file's header and knowing whether to run the default mount function or
> the handler. This would be useful if you thought clients should be
> able to accept either encrypted or unencrypted bundles.
Yes. We'd also need an option in the system.conf to configure which key
to use for decryption.

> Perhaps there is a much better way to do this than I've thought of.
> I'd love to hear your thoughts on this.

As we use CMS [1] for signing, we can potentially support everything
the OpenSSL cms tool (see 'man cms') supports (N-of-M signatures,
encryption with shared secrets and/or public/private keys).

So my current concept would be to use a differemt payload in the CMS
message (instead of a hash over the squashfs), consisting of
information about the encryption (algorithm, parameters and payload
key) and the payload hash (or dm-verity root hash). The CMS message
would then be encrypted in addition to being signed.

When opening the bundle, OpenSSL would detect that the CMS message is
encrypted, look for the matching private key and decrypt. Then we have
the information to configure dm-crypt and/or dm-verity on top of the
loop device. The rest of the installation would proceed as usual.

So the only places that would need to change are bundle opening (setup
OpenSSL for decryption and configure device mapper targets) and bundle
creation (optionally encrypt, optionally use veritysetup and use
OpenSSL for CMS encyption).

What do you think about this apporach?

[1] https://tools.ietf.org/html/rfc5652
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
RAUC mailing list