[RFC] mtd: ubi: UBI Encryption

[Andrew Murray]

On 12 August 2015 at 18:19, David Gstir <david at sigma-star.at> wrote:
> Hi!
>
> I'm fairly new to MTD/UBI/UBIFS, but I have a bit of knowledge of cryptography, so I'll focus on that. :)

Thanks!

>
>> On 10.08.2015, at 21:56, Andrew Murray <amurray at embedded-bits.co.uk> wrote:
>>
>> - The current implementation  encrypts with cbc(aes) across fixed sized
>>   units of hdrs_min_io_size - it also uses an IV based on the physcial offset
>>   of the block and user provided IV. The key/IV is read from a fixed location
>>   in flash. I'm not sure of the best way to manage/locate keys - this is
>>   clearly a hack.
>
> So does this mean the IV for each encryption-unit is chosen from a predictable sequence?
> If this is the case, using CBC makes the encryption vulnerable to certain types of attack.
> In general CBC requires random IVs to be secure. A common solution for disk encryption is to use ESSIV [1].

At present the IV is a fixed IV salt combined (^) with a block offset.
Thus if you can deduce the salt you could work out the IV.

ESSIV is apparently supported in kernel, I'll take a look and see if I
can also use this.

>
> Also, how do you handle cases where hdrs_min_io_size is not a multiple of the cipher's block size?
> I'm not a 100% sure how often this will happen, but in theory it could happen and will cause problems when using modes like CBC (len(ciphertext) >= len(plaintext)).

At present I don't - I don't even have any assertions to guard this. I
guess this is something I need to further consider - thanks.

>
> [1] https://en.wikipedia.org/wiki/Disk_encryption_theory#Encrypted_salt-sector_initialization_vector_.28ESSIV.29
>
>> - Encryption in UBI was preferred as it removed the complexity from userspace,
>>   though I suppose there is no reason why this can't be done within the MTD
>>   layer rather than in UBI and thus benefit all MTD users.
>
> Generally speaking, I'd argue for moving encryption to the highest layer possible. So, if you exclusively use UBIFS and need encryption, add it to UBIFS or even your userspace application.
> The main reason for this is that disk encryption on lower layers (e.g block-level) has fewer security guarantees, like no authentication of encrypted data for example. So it cannot prevent "evil maid" attacks.
> There is a nice writeup on this topic here: [2], which focuses on the commonly used XTS mode, but makes valid points for disk encryption in general.
>
> So, when you do encryption in UBI or MTD, be aware of the security implications and know your thread model.

Thanks for the links. Ultimately it will be up to the
user/system-designer to determine the best scheme (taking into account
above considerations) - I'm hoping to provide a kernel based option
that will be useful to some. There are already good userspace
facilities for encryption I don't see this deprecating those.

Thanks,

Andrew Murray

>
> [2] http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
>
>
> Thanks,
> David
>