Security Update for PrivatOS 1.0.5b

Earlier this week we announced the release of PrivatOS 1.0.5b. This release contains significant security updates, which include disabling SSLv3 to protect against POODLE attacks and giving users the option to use different device screen unlock and device encryption passcode/passwords. Separate and unique screen lock and encryption passwords are an important feature that no other Android OEM provides.

In general, Android only allows users to encrypt their device if a screen lock passcode/password has been set. This screen lock passcode/password then becomes the encryption key for device encryption. But many users do not want to set a strong passphrase for screen lock, since long passphrases can be cumbersome to type so frequently. A weak screen lock passcode then becomes a weak device encryption key. By providing our users with the option to separate these passwords, we are able to limit the times in which they are inconvenienced by a strong password at reboot time. Therefore, those that choose to use this feature will have a significant reduction in the risks associated with offline attacks against the device encryption key.

Why was decoupling the screen unlock from device encryption such a big deal? In order to encrypt a device, Android leverages the cryptfs module of the vold (Volume Daemon) daemon. The cryptfs module has a set of commands including checkpw, restart, cryptocomplete, enablecrypto, changepw, verifypw, getfield, setfield. However, the cryptfs module can only be accessed by root and system users, so either a System app or a rooted device can access these commands. When a user encrypts their phone in the Settings app, a service is called to send the command “cryptfs enablecrypto inplace ‘user’s password’” command to vold. In Android, the ‘user’s password’ will be the lock screen password/passcode. This will trigger the phone to start the encryption process.

Five-plus character passcodes/passwords are acceptable for screen lock, as there is no way to bruteforce the code without shutting down the phone and pressing the key combinations one-by-one. Combined with rate limiting and wiping the device after a number of tries, this is relatively secure. However, the data needed to brute force device encryption (encrypted password, salt, etc.) can be extracted from a seized device relatively easily. Even with Android 4.4 switching from PBKDF2 to scrypt, a 4-digit passcode can still be broken in under an hour. If the device encryption and screen lock passcode are the same, the attacker can gain full access to the device.

Prior to the release of PrivatOS 1.0.5b, the Settings app did not permit the user to change just the encryption password. Therefore, our users were caught in a catch-22 between security and usability. The majority of the time users choose usability. Now we provide our customers with an improved path to both.

This new option is found in Settings > Security (shown below). We enabled this feature through the cryptfs changepw command, which has no effect on the screen lock. However, when setting a new encryption password, the user will also be able to modify their screen lock passcode if desired.

On a final unrelated but important note: We are aware of the privilege escalation vulnerability that exists in all Android versions prior to L. We are in the midst of testing and will be releasing a fix shortly.