Hi Victor,
I totally agree with your comment, our second step is to
protect/hide/whatever the key store.
Regards
On 25/08/16 18:28, Victor Palau wrote:
Hi Xavier,
On Thu, Aug 25, 2016 at 5:10 PM, Xavier Pegenaute M2M
<[email protected] <mailto:[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
--
Snapcraft mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
