Hi Xavier, On Thu, Aug 25, 2016 at 5:10 PM, Xavier Pegenaute M2M < [email protected]> wrote:
> 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. > But surely if someone takes the hardware, they just need to boot it and it will decrypt itself. So unless you are storing the decryption key outside the device I am not sure how this will provide you additional security. no? > > 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 >> > > > -- > Snapcraft mailing list > [email protected] > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft >
-- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
