[SlightlyAboveMyPaygrade] The problems with encryption on Android

[b0z0 at SDF.ORG]

Nice article Rr +1
:  )

On Tue, 15 Aug 2017, Razer wrote:

> Date: Tue, 15 Aug 2017 19:54:27 -0700
> From: Razer <g2s at riseup.net>
> To: "cypherpunks at lists.cpunks.org" <cypherpunks at lists.cpunks.org>
> Subject: [SlightlyAboveMyPaygrade] The problems with encryption on Android
> 
>>
>> The limitations of Android N Encryption
>>
>> Over the past few years pixelphonewe’ve heard more about smartphone
>> encryption than, quite frankly, most of us expected to hear in a
>> lifetime. We learned that proper encryption can slow down even
>> sophisticated decryption attempts if done correctly. We’ve also
>> learned that incorrect implementations can undo most of that security.
>>
>> In other words, phone encryption is an area where details matter. For
>> the past few weeks I’ve been looking a bit at Android Nougat’s new
>> file-based encryption to see how well they’ve addressed some of those
>> details in their latest release. The answer, unfortunately, is that
>> there’s still lots of work to do. In this post I’m going to talk about
>> a bit of that.
>>
>> (As an aside: the inspiration for this post comes from Grugq, who has
>> been loudly and angrily trying to work through these kinks to develop
>> a secure Android phone. So credit where credit is due.)
>>
>> Background: file and disk encryption
>>
>> Disk encryption is much older than smartphones. Indeed, early
>> encrypting filesystems date back at least to the early 1990s and
>> proprietary implementations may go back before that. Even in the
>> relatively new area of PCs operating systems, disk encryption has been
>> a built-in feature since the early 2000s.
>>
>> The typical PC disk encryption system operates as follows. At boot
>> time you enter a password. This is fed through a key derivation
>> function to derive a cryptographic key. If a hardware co-processor is
>> available (e.g., a TPM), your key is further strengthened by
>> “tangling” it with some secrets stored in the hardware. This helps to
>> lock encryption to a particular device.
>>
>> The actual encryption can be done in one of two different ways:
>>
>>     Full Disk Encryption (FDE) systems (like Truecrypt, BitLocker and
>> FileVault) encrypt disks at the level of disk sectors. This is an
>> all-or-nothing approach, since the encryption drivers won’t
>> necessarily have any idea what files those sectors represent. At the
>> same time, FDE is popular — mainly because it’s extremely easy to
>> implement.
>>     File-based Encryption (FBE) systems (like EncFS and eCryptFS)
>> encrypt individual files. This approach requires changes to the
>> filesystem itself, but has the benefit of allowing fine grained access
>> controls where individual files are encrypted using different keys.
>>
>> Most commercial PC disk encryption software has historically opted to
>> use the full-disk encryption (FDE) approach. Mostly this is just a
>> matter of expediency: FDE is just significantly easier to implement.
>> But philosophically, it also reflects a particular view of what disk
>> encryption was meant to accomplish.
>>
>> In this view, encryption is an all-or-nothing proposition. Your
>> machine is either on or off; accessible or inaccessible. As long as
>> you make sure to have your laptop stolen only when it’s off, disk
>> encryption will keep you perfectly safe.
>>
>> So what does this have to do with Android?
>>
>
> Find out, with links:
> https://blog.cryptographyengineering.com/2016/11/24/android-n-encryption/
>
>

b0z0 at sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org