using PIN for lock screen does not work

[dk1978]

Hi Max,

good work on the WiFi- can confirm that it works in the latest build.

I found a problem while trying out first steps: it is possible to store a PIN for the lock screen, but trying to use it for unlocking the device always results in a "wrong PIN" error message. I will look into it next, let me know if you have any ideas where to start.

BR, dk1978

[mstaz]

Hi dk1978,

Yes, I also noticed that storing PIN doesn't work. I assume it's caused by keystore/keymaster which doesn't work yet. I always get this output in logcat:

01-13 23:48:29.396 460 460 E KeyMasterHalDevice: Keymaster does not support date for security patch level

I already tried to set the patch levels to same as from stock image (0111): VENDOR_SECURITY_PATCH := 2018-08-05 PLATFORM_SECURITY_PATCH := 2020-02-05

Unfortunately without any change. I fear it can't be read or it depends on AVB (Android Verified Boot) what is still disabled.

BR, Max

[dk1978]

Hi Max, I just confirmed that the stock system shows the same warning:

03-09 17:48:15.672   490   490 E KeymasterUtils: TA API Major Version: 4
03-09 17:48:15.672   490   490 E KeymasterUtils: TA API Minor Version: 0
03-09 17:48:15.672   490   490 E KeymasterUtils: TA Major Version: 4
03-09 17:48:15.672   490   490 E KeymasterUtils: TA Minor Version: 157
03-09 17:48:15.672   491   491 E KeymasterUtils: TA API Major Version: 4
03-09 17:48:15.672   489   489 I ServiceManagement: Removing namespace from process name android.hardware.boot@1.0-service to boot@1.0-service.
03-09 17:48:15.672   491   491 E KeymasterUtils: TA API Minor Version: 0
03-09 17:48:15.672   491   491 E KeymasterUtils: TA Major Version: 4
03-09 17:48:15.672   491   491 E KeymasterUtils: TA Minor Version: 157
03-09 17:48:15.673   491   491 E KeyMasterHalDevice: Keymaster does not support date for security patch level
03-09 17:48:15.673   490   490 I ServiceManagement: Removing namespace from process name android.hardware.gatekeeper@1.0-service-qti to gatekeeper@1.0-service-qti.
03-09 17:48:15.674   491   491 I ServiceManagement: Removing namespace from process name android.hardware.keymaster@4.0-service-qti to keymaster@4.0-service-qti.

I am struggling a bit to figure out what it wrong here... BR, Daniel

[dk1978]

Hi, I have just managed to fix this. I don't have a full explanation of what was going on, but I believe that the Qualcomm KeyMasterHalDevice implementation expects us to use file-based encryption, just like the stock image does. I do not believe that it cares about the AVB status - messing with the stock vendor and even system image did not seem to hurt.

Here is a forum entry with some related problems and explanations.

Here is an extract of the logcat output showing how vold now uses file-based encryption on the userdata partition and creates some sort of automatic key for that purpose:

03-11 22:02:24.780   476   476 I vold    : Vold 3.0 (the awakening) firing up
03-11 22:02:24.780   476   476 V vold    : Detected support for: ext4 f2fs ntfs vfat
03-11 22:02:24.784   476   476 W vold    : Failed to LOOP_GET_STATUS64 /dev/block/loop3: No such device or address
03-11 22:02:24.784   476   476 W vold    : Failed to LOOP_GET_STATUS64 /dev/block/loop2: No such device or address
03-11 22:02:24.784   476   476 W vold    : Failed to LOOP_GET_STATUS64 /dev/block/loop5: No such device or address
03-11 22:02:24.784   476   476 W vold    : Failed to LOOP_GET_STATUS64 /dev/block/loop7: No such device or address
03-11 22:02:24.784   476   476 W vold    : Failed to LOOP_GET_STATUS64 /dev/block/loop6: No such device or address
03-11 22:02:24.784   476   476 W vold    : Failed to LOOP_GET_STATUS64 /dev/block/loop4: No such device or address
03-11 22:02:24.784   476   476 W vold    : Failed to LOOP_GET_STATUS64 /dev/block/loop1: No such device or address
03-11 22:02:24.784   476   476 W vold    : Failed to LOOP_GET_STATUS64 /dev/block/loop0: No such device or address
03-11 22:02:24.786   476   476 D vold    : VoldNativeService::start() completed OK
03-11 22:02:24.786   476   478 I vold    : e4crypt_initialize_global_de
03-11 22:02:24.786   476   478 I vold    : Creating new key in /data/unencrypted/key
03-11 22:02:24.811   426   426 W hwservicemanager: getTransport: Cannot find entry android.hardware.keymaster@3.0::IKeymasterDevice/default in either framework or device manifest.
03-11 22:02:24.812   476   478 I vold    : List of Keymaster HALs found:
03-11 22:02:24.812   476   478 I vold    : Keymaster HAL #1: Keymaster HAL: 4 from QTI SecurityLevel: TRUSTED_ENVIRONMENT HAL: android.hardware.keymaster@4.0::IKeymasterDevice/default
03-11 22:02:24.812   476   478 D vold    : Computing HMAC with params { (seed: a5eb1b1055ac8a92112c1f42fb95265b8c6a991ab6fe91f887686a6b293, nonce: bc9dce3eb8327d8293d39b8412d09fc0f31cd9d58cfe1da3d9ee1de43edf) }
03-11 22:02:24.812   476   478 D vold    : Computing HMAC for Keymaster HAL: 4 from QTI SecurityLevel: TRUSTED_ENVIRONMENT HAL: android.hardware.keymaster@4.0::IKeymasterDevice/default
03-11 22:02:24.815   476   478 I vold    : Using Keymaster HAL: 4 from QTI for encryption.  Security level: TRUSTED_ENVIRONMENT, HAL: android.hardware.keymaster@4.0::IKeymasterDevice/default
03-11 22:02:24.815   476   478 D vold    : Creating key that doesn't need auth token

The necessary changes are in my forked repository.

BR, Daniel

[mstaz]

Hi Daniel, Great job! :+1: If I get it right, storage needs to be encrypted to get this working, isn't it? Interesting that these changes are forcing the device to be encrypted. So encryption is also working. Really great. Anyway with that I got the fingerprint sensor working as well. I'll commit my changes for that. BR, Max

[dk1978]

Hi Max, thanks. The device needs to use file-based encryption, yes. According to this, full-disk encryption will likely be deprecated in the future.

Before my changes the running build offered a settings feature labelled "encrypt your phone", which was apparently trying (and failing) to carry out a full-disk encryption. That feature disappeared now, and the phone says "Encrypted".

BR, Daniel