> On Aug 24, 2016, at 10:30 AM, Tyler Hicks <[email protected]> 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>
--
Snapcraft mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
