Correct implementations of keymaster should reject using an n-bit
RSA key to sign less than n bits of data, because we specify that
keymaster should not perform padding.
Change-Id: Ibdff1bbfbee84fd5bdbfb3149a124dbbaa7827fc
Note that this also changes the boot sequence, and moves the test for corrupted
data to cryptfs_restart_internal.
Bug: 17213613
Change-Id: I0f86e8fe3d482e2d1373bd0f4d0d861e63ad8904
In field reports, sometimes the remaining time gets stuck for many
minutes. This has to be caused by a spurious low reading early on which
cannot be overridded because of old logic.
Solution: allow time to increase but only by large amounts (avoid time
jittering up and down).
Bug: 16973374
Change-Id: I49d23ae8c54ded416cbedf383a3c03b33dc02e1c
Store salted scrypt of intermediate key in crypto header
When mount fails, check if matches, and if it does return error
code prompting a wipe
Bug: 11477689
Change-Id: I3dcf9e0c64f2a01c8ba8eaf58df82cbe717d421b
Set flag on starting encryption to say it failed, and only clear
when we get into a recoverable state (partially or fully encrypted.)
Go to recovery on seeing this flag on boot
Bug: 16552363
Change-Id: I7e452b653edf3a087ecfaba8f81f41765a1c8daf
When a crypto is enabled with a wipe flag (obsolete?),
it will correctly handle the fstab's choice for the fs type.
Remove the dead code for FAT_FS which was un-invocable.
Change-Id: I8d141a0d4d14df9fe84d3b131484e9696fcd8870
Signed-off-by: JP Abgrall <jpa@google.com>
The code was using encrypted_upto == 0 as an indicator that encryption
has succeeded. This meant that if no encryption happened, we would reboot
continually.
We now set encrypted_upto to fs_size when encryption is complete.
Also don't start to encrypt unless we are at 10% power. Stop when we
get to 5% power. This should lead to partial encryptions only very
rarely.
Bug: 15513202
Change-Id: I6214d78579d1fbbe2f63ee8862473d86a89d29b3
This reverts commit 5cc86c5741.
Without two more commits, this will break encryption. I'll re-commit when the other two pass code review.
Change-Id: I71720d065c16cf0f7f534e74ffe883f1e113c477
Stop encryption when battery is low, mark position, and continue on reboot.
Note - support for multiple encrypted volumes removed as no devices seem
to exist with an fstab that uses this feature. If you want support for such
a device, contact me and we will re-add it with appropriate testing.
Bug: 13284213
Change-Id: I1f7178e4f7dd8ea816cbc03ab5c4f6543e98acaa
If we are not to double prompt, we need to pass the password from
CryptKeeper to KeyStore. Since the entire framework is taken down
and restarted, we must store the password in a secure system daemon.
There seems no better way than holding it in vold.
Change-Id: Ia60f2f051fc3f87c4b6468465f17b655f43f97de
Add a call to vold that says if we decrypted the data partition. Reset the
flag so that it only returns true the first time.
Bug: 12990752
Change-Id: Ib00be87137c00fb8ad29205c85a3ea187764b702
Modify enablecrypto command to make the password optional. When it is
not there, default encrypt the device.
Remove a warning by making at least some parts of this file const-correct.
Bug: 11985952
Change-Id: Ie27da4c4072386d9d6519d97ff46c6dc4ed188dc
Store encryption type in crypto footer, and provide functions to
manipulate it. Add mount_default_encrypted command to vdc to allow
mounting of default encrypted volumes at boot time.
Bug: 8769627
Change-Id: Ie41848f258e128b48b579e09789abfa24c95e2b2
By setting ro.crypto.readonly to 1, cryptfs will mount an encrypted
filesystem that is normally mounted read-write as read-only instead.
To be used when recovery mounts /data.
Bug: 12188746
Change-Id: If3f3f9a3024f29ebc4ad721a48546a332cb92b6b
Prior to this, the Key derivation function would get
blindly updated even if the user entered the wrong password.
Now, we only attempt to upgrade the KDF if the pwd/key have
been verified (i.e. after a successful mount).
Bug: 11460197
Change-Id: I0469228cc9b87c47754e8ca3c7146651da177da5
Currently, if a non-framework process or service is using /data,
unmounting will fail as nothing will kill it.
Instead of rebooting on unmount failure, we now kill all processes
using /data, then try one more time.
Bug: 11291208
Change-Id: I6c5276c78aa55965914ace96e1db74dc80fca3c1
With the recent selinux changes imposed on vold, it no longer has
permission to run a shell, so invoking the filesystem formatting
commands with system(3) gives an error. So change to using
android_fork_execvp().
Bug: 10279958
Change-Id: Ifa18b28867618858ec7c5cfcc67935e377de38fb
scrypt is a sequential memory-hard key derivation algorithm that makes
it more difficult for adversaries to brute force passwords using
specialized equipment. See http://www.tarsnap.com/scrypt/scrypt.pdf for
more details of the algorithm.
This adds support for initializing disk encryption using scrypt and
upgrading from the previous PBKDF2 algorithm.
Change-Id: I1d26db4eb9d27fea7310be3e49c8e6219e6d2c3b
In order to make it easier to upgrade the crypto footer, extract some
constants to a header file instead. Then the header can control what the
current version is and the upgrade_crypto_ftr code should be the only
thing that needs to be updated.
Change-Id: I3ed5a7d3b640419cd8af91388d94a00de8cc09db
In the future, we'd like to have the ability to upgrade from any
supported version to any future version. Change the upgrade function
slightly to support this.
Change-Id: I3b20ccfff51c4c86f1e5e08690c263dc95ff5ce4
