[SlightlyAboveMyPaygrade] The problems with encryption on Android

[Razer]

>
> 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/