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