- During OTA upgrades if security state or ROT changes then Keymaster
keys requires upgrade. So for such usescases, if the FBE ephemeral
key export fails, check whether KM key requires upgrade and try for
exporting ephemeral key again.
CRs-Fixed: 2632902
Change-Id: I3ee2fcd97a56b628dc4304867c8f2b8da875f883
Signed-off-by: Neeraj Soni <neersoni@codeaurora.org>
- Commit 77df7f2 / http://aosp/1217657 ("Refactor to use
EncryptionPolicy everywhere we used to use raw_ref") unintentionally
made fscrypt_initialize_systemwide_keys() start specifying keepOld=true
(via default parameter value) when retrieving the system DE key, and
likewise for read_or_create_volkey() and volume keys.
As a result, if the associated Keymaster key needs to be upgraded, the
upgraded key blob gets written to "keymaster_key_blob_upgraded", but it
doesn't replace the original "keymaster_key_blob", nor is the original
key deleted from Keymaster. This happens at every boot, eventually
resulting in the RPMB partition in Keymaster becoming full.
Only the metadata encryption key ever needs keepOld=true, since it's the
only key that isn't stored in /data, and the purpose of keepOld=true is
to allow a key that isn't stored in /data to be committed or rolled back
when a userdata checkpoint is committed or rolled back.
So, fix this bug by removing the default value of keepOld, and
specifying false everywhere except the metadata encryption key.
Note that when an affected device gets this fix, it will finally upgrade
its system DE key correctly. However, this fix doesn't free up space in
Keymaster that was consumed by this bug.
Test: On bramble:
- Flashed rvc-d1-dev build, with wiping userdata
- Flashed a newer build, without wiping userdata
- Log expectedly shows key upgrades:
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key:
/metadata/vold/metadata_encryption/key
D vold : Upgrading key: /data/unencrypted/key
D vold : Upgrading key: /data/misc/vold/user_keys/de/0
D vold : Upgrading key:
/data/misc/vold/user_keys/ce/0/current
- Rebooted
- Log unexpectedly shows the system DE key being upgraded again:
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /data/unencrypted/key
- "keymaster_key_blob_upgraded" unexpectedly still exists:
$ adb shell find /data /metadata -name
keymaster_key_blob_upgraded
/data/unencrypted/key/keymaster_key_blob_upgraded
- Applied this fix and flashed, without wiping userdata
- Log shows system DE key being upgraded (expected because due to the
bug, the upgraded key didn't replace the original one before)
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /data/unencrypted/key
- "keymaster_key_blob_upgraded" expectedly no longer exists
$ adb shell find /data /metadata -name
keymaster_key_blob_upgraded
- Rebooted
- Log expectedly doesn't show any more key upgrades
$ adb logcat | grep 'Upgrading key'
Bug: 171944521
Bug: 172019387
(cherry picked from commit c493903732d0c17b33091cf722cbcc3262292801)
Merged-In: I42d3f5fbe32cb2ec229f4b614cfb271412a3ed29
Change-Id: I42d3f5fbe32cb2ec229f4b614cfb271412a3ed29
Change-Id: I0449b812e91c13020a8b653f2149c33e46027b97
This patchset introduces support decryption for Android 11.
In this update we deprecate ext4crypt. To specify the
policy version to use, use TW_USE_FSCRYPT_POLICY := 1 or
TW_USE_FSCRYPT_POLICY := 2. By default policy version will
be set to 2 if this variable is omitted.
Change-Id: I62a29c1bef36c259ec4b11259f71be613d20a112
The stored id for the different types of the lock pattern was chnaged
with Android 11. You can find the updated list in the LockPatternUtils:
https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-11.0.0_r25/core/java/com/android/internal/widget/LockPatternUtils.java#113
It was changed in 5e891bcc04556a3595ab349381acc2a2e36a69d1:
5e891bcc04
The old CREDENTIAL_TYPE_PASSWORD_OR_PIN was essentialy split in
CREDENTIAL_TYPE_PASSWORD and CREDENTIAL_TYPE_PASSWORD_OR_PIN.
This code updates the matching in twrp, so that the correct unlocking
method for file base decryption can be found. Without these changes twrp
always try to use the default password and obviously fails. With these
changes the usual password dialog is shown and the decryption is
successfully.
Change-Id: Ia8d47223b30a5301d4b9d2230241039612055ebb
Signed-off-by: Alexander Sulfrian <asulfrian@zedat.fu-berlin.de>
Co-authored-by: althafvly <althafvly@gmail.com>
* Add CLI support using the command "twrp decrypt <PASSWORD> [USER ID]"
* Add GUI support using the menu Advanced --> Decrypt User
multiuser: Parse users only when Decrypt_DE runs successfully
multiuser: Warn when not all users are decrypted
Change-Id: Ia5e943b13c2d5ec5c34ae97661133c19ff471e6d
for android-10
This will support updating the ramdisk to a different
compression format and co-exist with magisk.
We are also cleaning up and removing non android-10
api makefile actions.
We are also moving twrp repacking to its own class. We
check the new ramdisk format and if it's different
we have magisk compress using the new ramdisk format.
Change-Id: I770030aae7797e75817178b2f0fccd9f39dc23af
fscrypt aosp doc: https://source.android.com/security/encryption/file-based
kernel fscrypt doc: https://www.kernel.org/doc/html/v4.18/filesystems/fscrypt.html
This commit implements the ability for TWRP to use fscrypt to decrypt
files on the fscrypt implementation. It has been implemented mostly
in a new successor library to e4crypt called libtwrpfscrypt. Most of the
code was ported from AOSP vold.
Notable updates include:
- updated policy storage by libtar
- lookup of fbe policies by libtwrpfscrypt
- threaded keystore operations
Big thanks to Dees_Troy for the initial trailblazing
of encryption in TWRP.
Change-Id: I69cd2eba3693a9914e00213d4943229635d0cdae
This reverts commit 0b25b1d79b.
Reason for revert: Changes need to be made to libtwrpfscrypt to include this patchset. Will cherry-pick this patch later and make necessary modifications.
Change-Id: I7601d7b820129709b05d9b4368573b6f1048de02
* Add CLI support using the command "twrp decrypt <PASSWORD> [USER ID]"
* Add GUI support using the menu Advanced --> Decrypt User
Change-Id: Id2681bc2b1012a0571417f7a6e0b980b1b25c61c
(cherry picked from commit 5a79f67a1b1bd1bcadeca0a4896a871646652534)
- Requires TW_INCLUDE_LIBRESETPROP
(set automatically if TW_OEM_BUILD is not set)
- Set based on installed system (if present)
- Will set values back to TWRP defaults
after decryption completes
- Only included/run on Oreo+ systems
Change-Id: I41fcc1af8cd4b15329574f7403f7491320199f48
(cherry picked from commit 3284a66e23fbc6e1a82df668b497ef931d9c0081)
This allows flame to boot TWRP. Still will need to work on
super partition for vendor and system access.
The plan will be to cherry-pick any updates to android-9.0
through gerrit.twrp.me to this branch as a WIP.
* Some devices like lavender, etc. getting failed to decrypt
Change-Id: I63ca05c4f87cdd17d48d4541a5a8121c736beb02
Signed-off-by: Mohd Faraz <androiabledroid@gmail.com>
Re-implemented SP800Derive in C++, which is added as the new key
derivation function in Android 9.0 May update. From file
services/core/java/com/android/server/locksettings/SP800Derive.java in
frameworks/base.
This is required to get TWRP working on any Android device that has a
screen lock set up after the May update.
Change-Id: I5c1a51b110033f2b0b75d5e36fd8098c05e95179
cryptfs.cpp based on CAF tag LA.UM.7.3.r1-05900-sdm845.0
Used CAF because AOSP no longer contains code for qcom's hardware
crypto.
Change-Id: I921cbe9bed70989f91449e23b5ac3ec1037b7b97
* build modified vdc_pie binary with 'checkpw' command support
if building with Android 9.0 platform. That command and others
we don't care about, are removed from Pie vdc. Our vdc_pie will
run if system sdk version is > 27, otherwise system vdc is used.
Code adapted from Android 9.0 system/vold/vdc.
* include prebuilt vdc_pie(arm, arm64) binary if building with lower
than Android 9.0 platform - vdc_pie cannot be build from source
with those platforms without additional imports from Android 9.0
* skip vdc "getpwtype" command for Pie - vds communicates with vold
directly, no need for connection retries first
* add /system/bin/servicemanager to required services
* mount per-devive additional partitions needed for decryption
listed with device BoardConfig.mk TW_CRYPTO_SYSTEM_VOLD_MOUNT
flag like(space separated):
TW_CRYPTO_SYSTEM_VOLD_MOUNT := vendor cust odm
* add function to backup crypto footer before running vdc commands
and restore it after - on Xiaomi Mi Max 3 both Oreo and Pie stock
roms vold alters cripto footer when decrypting data in recovery
which causes system to ask for crypto password at next reboot
although password stays unchanged. Crypto footer backup/restore
added as workaround for systems whit ro.build.version.sdk > 25.
Also to preserve crypto footer integrity decryption attempts are
skipped if footer backup fails to ensure no data loss.
Code adapted from
https://gerrit.omnirom.org/#/c/android_bootable_recovery/+/31206/
Change-Id: I0a383f3843578fa55595cfea3b7c9c4431646a1a
Rather than using hard-coded system, use ANDROID_ROOT
environment variable to allow AB devices to mount
system_root at a custom path. This allows the /system
path to be bind mounted from $ANDROID_ROOT/system
so that the vold_decrypt paths can remain unchanged.
Change-Id: I9a7b13385e43f169f1df4c75b2a003fc6913952c
Building in 9.0 may require you to add a flag to your twrp fstab
with the fileencryption details like:
fileencryption=ice:aes-256-heh
Verify this against your device's stock fstab of course.
Change-Id: If9286f5d5787280814daca9fbc8f5191ff26a839
It seems that old Scrypt-config.mk is unaware of arm64 architecture.
In fact, crypto_scrypt-neon.c can be compiled into arm64 as well. This
CL adds an arch section for arm64.
Bug: 65425184
Test: adb shell /data/nativetest64/scrypt_test/scrypt_test
Change-Id: Ib451de642c7cc4548bfdc0879781981654b21b8f
Merged-In: If40a30378b8038324aad44071107130d7722e28d
* Allow custom definition of strace path with TW_ flags.
* `TW_CRYPTO_SYSTEM_VOLD_DEBUG := true`
will use default path: /sbin/strace.
* `TW_CRYPTO_SYSTEM_VOLD_DEBUG := /system/xbin/strace`
will use the provided `/system/xbin/strace` path.
Change-Id: I5e12a10176d17a4f26487de0976a776d48c4142e
Signed-off-by: nailyk-fr <nailyk_git@nailyk.fr>
* Separate stdout and stderr buffers:
vdc's return codes get sent to stdout, but the possible presence of
other error messages in the output buffer will cause a valid return
from vdc not to be parsed properly, and subsequent decryption to fail
due to "misunderstood" return code.
eg on the U11+ (htc_ocm) libc will generate an error to stderr due to
a missing property area resulting a proper connection to vold being
incorrectly parsed, and breaking decryption.
* Improve logging.
Change-Id: I57987ebe4ee6754a78e79ca177506098f8301f8f
libnativeheader exports headers under nativeheader. These were
available before incorrectly as global headers in order to give
access to jni.h.
Test: modules using external/scrypt find headers
Bug: 63762847
Change-Id: I9baf896015a1920f8a26daa2a0c549169628890f
Support decrypting Pixel 1 devices using secdis method with the
gatekeeper instead of weaver.
Add a bit of a dirty workaround to a permissions issue that the
keystore presents because the keystore checks the uid of the
calling process and refuses to let the root user add authorization
tokens. We write the auth token to a file and start a separate
service that runs under the system user. The service reads the
token from the file and adds it to the keystore. You must define
this service in your init.recovery.{hardware}.rc file:
service keystore_auth /sbin/keystore_auth
disabled
oneshot
user system
group root
seclabel u:r:recovery:s0
TWRP will run this service when needed.
Change-Id: I0ff48d3355f03dc0be8e75cddb8b484bdef98772
