Re: [RAUC] Stumped, have a appfs partition that is encrypted, how to get RAUC to update it

[Brian Hutchinson <b.hutchman@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7058 bytes --]

Hi Jan,


On Fri, Jul 23, 2021 at 9:40 AM Jan Lübbe <jlu@pengutronix.de> wrote:

> 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?
>

It's a long story, no requirement for "secure boot" only "encrypt files at
rest".  I know, I know.  I just follow schedules ;)


> > 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.
>
> So here is the test I did ... that didn't work.

I nfs booted my board.  rauc thinks I've booted from slot A so it's going
to try to update slot B.

I do:

cryptsetup luksFormat /dev/mmcblk2p2 /boot/luks_appfs_key
cryptsetup luksOpen /dev/mmcblk2p2 crypt_appfs2 --key-file
/boot/luks_appfs_key
mkfs.ext4 /dev/mapper/crypt_appfs2

My /etc/rauc/system.conf looks like:

[system]
compatible=MyBoard
bootloader=uboot

[keyring]
path=/etc/rauc/ca.cert.pem

[slot.kernel.0]
device=/dev/mmcblk2gp0p1
type=vfat
parent=rootfs.0

[slot.kernel.1]
device=/dev/mmcblk2gp1p1
type=vfat
parent=rootfs.1

[slot.rootfs.0]
device=/dev/mmcblk2gp1p2
type=ext4
bootname=A

[slot.rootfs.1]
device=/dev/mmcblk2gp1p2
type=ext4
bootname=B

[slot.appfs.0]
device=/dev/mmcblk2p1
type=ext4
parent=rootfs.0

[slot.appfs.1]
device=/dev/mapper/crypt_appfs2
type=ext4
parent=rootfs.1

So at this point, /dev/mapper/crypt_appfs2 is open but not mounted.

I have my bundle scp to /tmp so I try to install it and get:

installing
 0% Installing
 0% Determining slot states
20% Determining slot states done.
20% Checking bundle
20% Verifying signature
40% Verifying signature done.
40% Checking bundle done.
40% Checking manifest contents
60% Checking manifest contents done.
60% Determining target install group
80% Determining target install group done.
80% Updating slots
80% Checking slot kernel.1
83% Checking slot kernel.1 done.
83% Copying image to kernel.1
86% Copying image to kernel.1 done.
86% Checking slot rootfs.1
90% Checking slot rootfs.1 done.
90% Copying image to rootfs.1
[ 1901.504350] EXT4-fs (mmcblk2gp1p2): mounted filesystem with ordered data
mode. Opts: (null)
93% Copying image to rootfs.1 done.
[ 1927.854400] EXT4-fs (mmcblk2gp1p2): mounted filesystem with ordered data
mode. Opts: (null)
93% Checking slot appfs.1
96% Checking slot appfs.1 done.
96% Copying image to appfs.1
100% Copying image to appfs.1 failed.
100% Updating slots failed.
100% Installing failed.
LastError: Installation error: Failed updating slot appfs.1: failed to run
mkfs.ext4: Child process exited with code 1
Installing `/tmp/./update-myboard.raucb` failed

But yet I can do mkfs.ext4 /dev/mapper/crypt_appfs2 and mount it and the
filesystem is fine.

Looks like I'm missing something still.

Regards,

Brian

[-- Attachment #2: Type: text/html, Size: 13467 bytes --]