Snappy + root encryption

[Xavier Pegenaute M2M]

Hi Tyler, All,

my use case is something like this:

we develop some software that can be installed in some hardware provided 
by the client. One of our clients requires a snappy distribution. To 
protect our data we need to encrypt all FSs in the snappy. Even if at 
the moment we have some weak points such as the place were we store the 
keys. It is not expected to have a human around every time the snappy 
boots but time to time it may be possible.
Our goal is to protect the content in case some one takes the hardware 
and mount the partitions as an external drive.

To do so I want to encrypt the FSs with LUKS and provide somehow the key 
at boot time and decrypt the FSs: system-a/b, writable and swap. During 
this process I am facing some problems which I need to solve asap:
- The configured grub on the FS, apparently does not belong to the real 
system. When I run update-grub from a fresh installation does not appear 
the same menu options than when booted before.
- The "break=premount" parameter does not work
- The kernel and initrd image are located in /boot but the "boot" 
partition point to /boot/efi which I guess it will be a problem when de 
rootfs is encrypted.
     As a solution, I guess it is better to move the kernel + initrd to 
/boot/efi. I will need to only update grub and update-initramfs. Am I 
missing something?

Best Regards,
Xavi

On 24/08/16 18:30, Tyler Hicks wrote:
> On 08/23/2016 06:47 AM, Xavier Pegenaute M2M wrote:
>> Hi Mark,
>>
>> actually, our goal is to provide hardware to be delivered on costumer
>> premises but for this we need an extra layer of security. This is the
>> reason we are considering the encryption solution.
>>
>> If it is possible our first and preferred solution is to encrypt as much
>> as possible starting from rootfs.
>>
>> I guess I should port the cryptsetup package and dependencies to snap,
>> but since I saw in your mailing list some references I wanted to be sure
>> this is not already done or being in process.
>>
>> As a second step, AFAIK, I should modify the boot process to include
>> support for partition decryption which again I am not sure this is
>> already supported on snappy (crossing fingers xD ).
> Will your devices have a display and a keyboard? Will a human always be
> present during the boot process (after a planned or unplanned reboot) to
> enter the password?
>
> If the answer is 'no' to either of those questions, there's more work to
> do in order to provide secure storage of the encryption key in a way
> that makes it automatically accessible during the boot process.
>
> Let us know what your needs are and we can at least capture the use case
> and requirements in a feature request bug so that we can try to support
> you when designing the storage encryption solution in the platform
> itself. Thanks!
>
> Tyler