I recently obtained one Android phone for playing around with it and as security minded person (!) – I decided to secure parts of the device to the level of acceptability. Well, surely encryption was one of the techniques deployed. In multiple levels.
I decided to start from built-in, “full disk encryption” available readily off-the-shelve. By realizing that LUKS kind of approach has certain vulnerabilities for storing the keys and while allowing physical access to the device, key management will be one to dig deeper.
Well, then I recalled the old ‘SUSPEND TO RAM’ issue with one of the fairly well known encryption apps for Windows, which saved the keys to RAM. One thing lead to other and then I found what I was looking for – someone did the ‘recovery image’ for Android to obtain the keys from RAM.
So folks at Friedrich-Alexander Universite (FAU.DE) made excellent effort and report in bypassing Android encryption and some other security features by reading keys from frozen RAM (FROST http://www1.cs.fau.de/frost).
Well – should I leave this to the programmers hands to create better capability for scrambling the data avoiding the direct ‘mind melt’ with vector as FROST shows, wait someone builds decent keystore for phone – OR – should I try to circumvent the attack in other ways and create technique to dismantle the approach?
I selected the latter.
Very simply put: Mechanically enforced hardware reset for RAM prior bootloader init.
Further speculation with Tilo Muller & Michael Spreitzenbarh from FAU.DE revealed the approach was pretty much something to expect. They said that currently Google does wipe the user partition on a GNex if you unlock its bootloader, but RAM gets *never* wiped. Wiping RAM should defeat their attack. It would not even be necessary to wipe it on each boot; for most people, wiping RAM when unlocking the bootloader is sufficient.