Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Encryption - Move to FBE; /cache partition encryption #596
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Feb 19, 2017
Contributor
The issue tracker isn't used as a Q&A / training platform. Support is only for customers. You're not bringing up any new information or making a concrete feature request. Feature requests aren't really wanted anyway, there are enough filed already.
We're not at the mercy of Google when it comes to encryption other than APIs exposed to apps. You're misunderstanding the scope of device encrypted storage and there's no such thing as a /proc partition. Pixels don't have a /cache partition.
|
The issue tracker isn't used as a Q&A / training platform. Support is only for customers. You're not bringing up any new information or making a concrete feature request. Feature requests aren't really wanted anyway, there are enough filed already. We're not at the mercy of Google when it comes to encryption other than APIs exposed to apps. You're misunderstanding the scope of device encrypted storage and there's no such thing as a /proc partition. Pixels don't have a /cache partition. |
thestinger
closed this
Feb 19, 2017
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
Show comment Hide comment
thestinger
Feb 19, 2017
Contributor
Not that there's anything interesting in /cache on the last generation of devices anyway... I really don't have time to respond to stuff like this, and I should just be closing them.
|
Not that there's anything interesting in /cache on the last generation of devices anyway... I really don't have time to respond to stuff like this, and I should just be closing them. |
cypherpunkglobal commentedFeb 19, 2017
I know you are pretty much at the mercy of Google on this, but many, e.g. Matt Green (https://blog.cryptographyengineering.com/2016/11/24/android-n-encryption/), have stated that the move from FDE to FBE in Nougat is being implemented poorly and that ultimately FBE ends up potentially being less secure than FDE in certain scenarios. Some have suggested that FDE on top of FBE would have been a better path, (or at least should have been an option) (imho a device should be a brick on first boot until the encryption password is entered).
On a plain vanilla install of Copperhead on a Pixel, what data and metadata which is currently encrypted using FDE tied to the user's password on the 5X and 6P will no longer be encrypted with encryption directly tied to the user's password (i.e. Credential Encrypted Storage), not just "Device Encrypted Storage" (which is worse than FDE).
Have you taken into account how well apps you are bundling with CopperheadOS take advantage of Credential Encrypted Storage?
Also, any plans to actually evict keys for Credential Encrypted Storage from keyring when the screen is locked?
Finally, is data in the /cache and /proc partitions, which can contain sensitive information and metadata, encrypted whatsoever whether using FDE or FBE? If not, even if wiped, the data can be recovered in a forensic examination of the internal flash.
If devices running this OS are to be considered secure, they should at least come close to the standards set by iOS devices when it comes to physical security (not that they dont have their own issues). Hence, multiple layers of encryption with both FDE and FBE would have seemed an easy way to avoid the risk of leaking potentially sensitive metadata, while gaining some physical security from FBE.