<story><title>The limitations of Android N Encryption</title><url>https://blog.cryptographyengineering.com/2016/11/24/android-n-encryption/</url></story><parent_chain></parent_chain><comment><author>tytso</author><text>So I only worked on the ext4 encryption feature in the Linux kernel which was used to implement Android FBE, and so I&amp;#x27;m not an expert on vold, but there shouldn&amp;#x27;t be a reason why vold needs to hang on to the key.  Vold is responsible for pushing the keys into the kernel, but what ext4 uses to do the per-file encryption is stored on a kernel keyring, &lt;i&gt;not&lt;/i&gt; in userspace.  So vold should be destroying the key after it loads it into memory --- it certainly can&amp;#x27;t use the key for anything useful.&lt;p&gt;As far as being able to remove the keys while the phone is locked --- I can&amp;#x27;t comment on future product directions, but it&amp;#x27;s fair to say that the people working on the upper layers of the Android security system aren&amp;#x27;t idiots, and the limitations of what was landed in the Android N release was known to them.   It is no worse than what we had in older versions of Android (with FDE, we were using dm-crypt, and the keys were living in the kernel as well), and while it doesn&amp;#x27;t help improve security with respect to the &amp;quot;evil maid&amp;quot; attack, it does significantly improve the user experience.&lt;p&gt;I agree that there is certainly room to improve, and note that future changes will require applications to make changes in how they access files, which does make it a much trickier change to introduce into the ecosystem without breaking backwards compatibility with existing applications.&lt;p&gt;As far as why different keys are being used for different profiles --- this makes it much easier to securely remove a corporate, &amp;quot;work&amp;quot; profile from a phone without needing to do a secure erase on the entire flash device --- either because an employee is leaving their existing employer and there is corp data on a BYOD phone&amp;#x2F;tablet, or because the phone has been lost, and corporate security policy about how quickly corp data should be zapped from the phone might be different from what the user might want to exercise when they have temporarily misplaced the phone.   (e.g., you might have a different tradeoff of losing unbacked-up data from your personal files versus their getting compromised while you hope that someone turns in your phone to lost+found than your company&amp;#x27;s security policies might require.)</text></comment>
<story><title>The limitations of Android N Encryption</title><url>https://blog.cryptographyengineering.com/2016/11/24/android-n-encryption/</url></story><parent_chain></parent_chain><comment><author>arkadiyt</author><text>For a really in-depth dive about the iOS class keys system he mentions I recommend this 2016 blackhat talk by Ivan Krstic (head of security at Apple): &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=BLGFriOKz6U&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=BLGFriOKz6U&lt;/a&gt; (relevant portion starts at 6:56)</text></comment>