On Wed, Sep 18, 2019 at 08:27:57AM +0300, Janne Karhunen wrote: > > The way I see this is that the greatest asset to protect on any device > is the user data. The data security comes first, then the device > security as a mechanism to protect that same data. You could even say > that the device security is worthless when the device is empty. The > user data is almost always mutable by nature. So, would be really > great if the fs-verity metadata storage would take it into a > consideration that one day someone will want to use it for the mutable > data as well, even if Google does not want at this point in time. > Things like photos, videos are ideal use cases for the verity like Ted > pointed out. Writable data is tricky, and has several problems. The first is performance; the block which gets modified and the cryptographic checksum has to be updated atomically; and if you use a Merkle tree, you have to update multiple blocks in the Merkle tree atomically. The journalling necessary to address this is really tricky. The other problem is if you want to update authenticated checksums while blocks are being updated, this raises the question about how do you secure the key used to sign the checksums? For read-only data, the private signing key can be stored off the device. For example, it can be stored on an off-line build server for a Red Hat package. Or Google can store the signing key for APK's on a secure server inside their data centers before the package is made available on Google Play Download servers. For mutable data, the signing key needs to be stored on the mobile device --- so the value is significantly decreased. After all, if a malicious attacker can take over the phone in order to modify a photo, the malicious attacker can also steal the signing key off the mobile device and then modify the photo. There are solutions for these problems. For example, one could use a storage device with 4128 byte sectors, with an inline encryption engine (ICE) which uses AES-GCM (an Authenticated Encryption with Associated Data mode), with the key stored in a secure enclave and where the host OS authenticates to the secure enclave, and then the secure enclave delivers the key to the ICE without the key ever touching the general purpose CPU. But in general, they all require a lot of custom hardware. And I'm not making any comments about any future product features in Android, but it's safe to say that security architects have been talking about such designs for quite some time. The challenge has always been balancing the cost / benefit tradeoffs, and whether customers are willing to pay what it costs, either in $$$ or performance, to get that level of security. Cheers, - Ted
