Hi Brian,

On Thu, 2021-07-22 at 08:55 -0400, Brian Hutchinson wrote:
> Hi Jan,
>
> On Thu, Jul 22, 2021 at 8:16 AM Jan Lübbe <jlu@pengutronix.de> wrote:
> > On Thu, 2021-07-22 at 08:11 -0400, Brian Hutchinson wrote:
> > > I'm wanting to have a rootfs that is read-only SquashFS and a appfs that
> > > is encrypted.
> > I assume you want to have a A/B appfs.
>
> Yes, have A/B for Kernel, dtb, rootfs and appfs.

OK, as a side-node: I'd suggest storing the kernel in the rootfs, as that gets
rid of potential inconsistencies, avoids the need to reserve space in the kernel
partitions and reduces the number of build artifacts to keep track of.

> > How do you encrypt your appfs? dm-crypt or fscrypt?
> So process in factory will set everything up on eMMC the first time with:
>
> cryptsetup luksFormat /dev/mmcblk2p1 & /dev/mmcblk2p2
> cryptsetup luksOpen /dev/mmcblk2p1 crypt_appfs1 (same thing for
> /dev/mmcblk2p2)
> mkfs.ext4 /dev/mapper/crypt_appfs1 & crypt_appfs2

So dm-crypt with luks header.

> Then in normal use just have a script that figures out which slots we are
> starting, A or B to determine with appfs partition to use and cryptsetup
> luksOpen then mount /dev/mapper.

I'd open both and only mount the active one. (see below)

> > > I know a bundle can have pre and post triggers so maybe I can use those to
> > > cryptsetup luksOpen the partition and then mount it and then RAUC can do
> > > it's
> > > normal thing ... but I've not researched that enough to know if that's the
> > > way
> > > to go so thought I'd ask for some guidance to point me in the right
> > > direction
> > > first.

There is the "pre-install" slot hook:
https://rauc.readthedocs.io/en/latest/using.html#slot-hooks

It's not appropriate for your use-case, though, as it's called after RAUC has
mounted the target slot, as that would be too late.

> > If you use dm-crypt, you can just use the device-mapper path for the slot's
> > device= propert in system.conf. That way, the encryption is transparent to
> > rauc.

> Not following how that would work since the inactive appfs would be
> "closed/encrypted".

You'd luksOpen both apps partitions during boot, before starting RAUC. 

From your other mail:
> Sorry, forgot to reply-all to last message.  So when I did my luksFormat etc.,
> I used a key-file that I created with openssl rand -base64 32 >
> luks_appfs_key. 

Hmm, I thought you'd use a TPM or kernel trusted keyrings to store the key.
Where do you store this key file, so it's not easily readable by the attacker?

> Are you telling me that if I add a key and put it in the rauc key ring in
> /etc/rauc and in my system.conf refer to my appfs by /dev/mapper name rauc
> will know what to do to "open" the inactive appfs to do the update?

No. The rauc keyring is only for checking the signature on the bundle.


> I guess I'm hung up on how the "open" will take place and how to tell rauc
> about the key to use etc.  

rauc has no special support for any specific type of block device, as it just
uses the abstraction as provided by the Linux kernel, similar to mkfs.ext4.

So anything that can be used by i.e. ext4 can be used by rauc, you only have to
setup the devices before starting rauc. This means that rauc works with HDDs,
SSDs, USB-Sticks, SD-Cards, eMMCs, NVMe, RAID, LVM, dm-verity/-crypt/-integrity
and anything else that's represented as a Linux block device, without needing
specific code for each.

In the case of block device encryption, this also avoids the need to give rauc
access to the key material. Having a service/script during boot be the only
place where the key is handled, avoids exposing it in the rest of the system,
where it could be compromised.

So my suggestion is: During boot, get the key material in your project-specific
way (TPM/HSM/OP-TEE/...) and use cryptsetup/dmsetup to create both
/dev/mapper/crypt_appfs[12] and then discard the key material from userspace, so
only the dm-crypt target keeps it alive. In rauc's system.conf, you set
device=/dev/mapper/crypt_appfs1 and /dev/mapper/crypt_appfs2 for the appfs
slots. This way, it rauc can use them as any other block device.