Cause we are doing it wrong. And the whole situation messes with the UX.
As a user, just a few considerations:
- relying on android doesnt differentiate sfos
if we use (for example) TEE with blobs; or hwcomposer; then whats the point of having a separate OS? - is TEE an open spec? See open-tee for example
- whats the counterpart of TEE on sony devices?
- if the pin code is too short; how about limiting retries to a smaller ammount before back-off time (i.e. 3/4 times)?
I am sure it has been all discussed above. In short, the solution using underlying TEE or similar ensures that it is impossible to brute-force decrypt the volume after you DD-copy it from the device. Such 3-4 entry limitation on software (SFOS) level will not work for such case. In principle, you can use any HW-assisted key generation for encryption, I used the one that is readily available. Thatâs, obviously, for the version described here - âcommunityâ encryption.
For âofficialâ encryption, solution is based on longer PINs/PWDs. I presume it is still connecting PIN/PWD check with LVM decryption - so the same PIN/PWD has to be used for the both operations.
Whether TEE is open SPEC - no idea, havenât checked it.
yes. I have 2 headers of LUKS volume and exchanging them with dd on-the-fly (and then trying to unlock the phone) clearly shows that.