Snappy + root encryption

[Joshua Perry]

> On Aug 24, 2016, at 10:30 AM, Tyler Hicks <tyhicks at canonical.com> 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
> 
>> 
>> Regards
>> 
>> On 23/08/16 13:21, Mark Shuttleworth wrote:
>>> Hi Xavier
>>> 
>>> With snaps on classic (deb-based) Linux there have been some bugs
>>> related to encrypted home directories, not sure if those are fixed yet
>>> but they are definitely in progress.
>>> 
>>> On Ubuntu Core (where the whole system is a collection of snaps, there
>>> are no debs by default) it should be possible to have an encrypted disk.
>>> The main question would be what your expectations of the boot process
>>> would be. Most people who want Ubuntu Core are doing so for distributed
>>> devices where there isn't going to be a human around if the machine
>>> reboots.
>>> 
>>> Mark
>>> 
>>> On 23/08/16 06:26, Xavier Pegenaute M2M wrote:
>>>> Hi all,
>>>> 
>>>> I am interested on building a snappy system with encryption to rootfs,
>>>> I've been looking around but I didn't find any document or guide about
>>>> it. Does snappy support it? If this is the case some one could point
>>>> me to some info about it?
>>>> 
>>>> Regards

I’ll chime in here since we share a similar use-case. We are using an ATECC508A(1) for hardened cryptographic key storage and ECDH ephemeral key setup.

Our trust chain is pretty typical--as far as secure-boot processes are concerned--rooted in the boot ROM which verifies the bootloader, u-boot verifies the kernel and other boot assets, and then the kernel/init verifies the rootfs.

During device personalization this Secure Element internally generates a keypair which we sign with our distribution signing certificate. The data volume is then encrypted with a random symmetrical key which is in turn stored--encrypted with the SE public key--in the boot volume.

Once the kernel and initrd are verified during the boot process, the init script communicates with the SE (using an encrypted I2C channel set up by the boot ROM to verify the u-boot signature) and asks it to verify the rootfs signatures (a and b) and decrypt the symmetrical key for mounting the data volume.

We didn’t see the necessity in rootfs encryption since we don’t store sensitive data there. So while we do sign and verify our rootfs loads to ensure system integrity, we only encrypt the data volume.

1. https://github.com/AtmelCSO/cryptoauth-openssl-engine
 <https://github.com/AtmelCSO/cryptoauth-openssl-engine>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160825/f3d82825/attachment.html>