Re: [RAUC] RAUC bundle encryption, design question

[Evan Edstrom <evan@evanedstrom.com>]

Thank you for the helpful feedback. I like the direction of this
design quite a bit. Agree with implementing the encryption using
OpenSSL in user-space. I will expand a little on our specific use
case, I'd like to dig a bit deeper on the CMS message contents.

We have a crypto key storage chip on our embedded device, an
ATSHA204A. We want to feed it a salt, and it will generate a key from
the given salt and its internal secret key. In our case all of the
devices, given the same salt, will produce the same key. I'd like to
use this key to decrypt the CMS message. Other users of RAUC may want
to handle this differently. I wasn't quite clear how you were
picturing RAUC being delivered a key for the CMS message in a generic
way.

Regardless, to use this approach we would need a portion of the bundle
metadata which is not encrypted to store the salt. Since this may
differ from user to user, I would propose allowing a user to pass a
file to the bundle generator which would be stored in the bundle
signed but not encrypted. On the device, we would need a handler to
deliver the data so we could  send it to the crypto device, then
provide the resulting key to RAUC to open the bundle. RAUC would then
have everything it needed to decrypt the message and in turn mount the
encrypted squashfs partition. A RAUC user wouldn't have to leverage
this, but a custom data section coupled with a handler between the
start and decrypt steps would be widely accommodating.

My other proposal is to either move or include a copy of the manifest
in the unencrypted but signed portion of the bundle metadata. Since
decrypting and mounting a bundle could take a little time, having it
easily accessible would allow getting a quick response from "rauc
info", it would be nice to do compatibility checks at this time too.
You could also inspect a bundle off-device to see what it was. For
example on a artifact storage server or web interface.

I drew a crude diagram. Wasn't sure if all mail clients rendering in
fixed width was a good assumption, so I put it here:
http://file.evanedstrom.com/osrc/rauc/misc/bundle_logic1.txt

Evan

On Thu, Aug 23, 2018 at 2:04 AM Jan Lübbe wrote:
> On Wed, 2018-08-22 at 13:27 -0700, Evan Edstrom wrote:
> > On Tue, Aug 21, 2018 at 1:03 AM, Jan Lübbe wrote:
> > > On Mon, 2018-08-20 at 11:39 -0700, Evan Edstrom wrote:
> > I agree building in encryption support is nice, though successful
> > implementation of encryption and security for embedded devices
> > requires some level of custom hardware.
> What kind of custom hardware are you thinking about? I'd prefer to
> reuse and integrate with existing HW/SW as much as possible.

Just mean that two embedded devices from different companies are
likely to look extremely different in terms of how they handle
security. Specifically key storage or generation (see use case above).

> > This is going to be very
> > device specific and I'm worried forcing the use of a specific
> > procedure may be too limiting. I wonder if we would still need to
> > provide some user customizability in the form of a handler somewhere.
> You want to use a random payload key for every bundle to avoid problems
> with key/IV reuse. So I think the (encrypted) payload key needs to be
> contained in the bundle metadata. If you have a fixed (shared secret)
> key on the devices, this could still be handle by passing it as a
> password to the CMS decryption.

I do like this idea of having a random payload key stored in an
encrypted CMS message. But somehow OpenSSL needs to get a key to
decrypt the CMS message. I am worried about the potential variety in
this area across devices.

_______________________________________________
RAUC mailing list