1

On a first-generation Pixel that is running Pie, in locksettings.db there is a field named sp-handle that contains a 64-bit value. sp is an abbreviation for "synthetic password". Under /data/system_de/0/spblob there are three files:

  • 0000000000000000.handle
  • XXXXXXXXXXXXXXXX.pwd
  • XXXXXXXXXXXXXXXX.secdis
  • XXXXXXXXXXXXXXXX.spblob

XXXXXXXXXXXXXXXX is the lowercase hexadecimal representation of the aforementioned 64-bit value. (I actually have several sets of pwd/secdis/spblob (some missing the spblob or the secdis file—I cannot remember which) presumably due to my attempts to get TWRP to decrypt my Pixel.) There are also files under /data/misc/keystore/user_0 named 1000_USRSKEY_synthetic_password_XXXXXXXXXXXXXXXX and .1000_chr_USRSKEY_synthetic_password_XXXXXXXXXXXXXXXX.

These "synthetic passwords" are mentioned and used in TWRP and SyntheticPasswordManager.java. They are used in decryption, but I can't tell how they are used in it or if they are also used in password authentication. Are they used to decrypt /data/misc/vold/user_keys/ce/0/current/encrypted_key (which I'm told is used in file-based encryption)? What are the purpose of the .pwd, .secdis, and .spblob files? Are the files gatekeeper.*.key used in deriving synthetic passwords?

Update

This paper from Qualcomm goes into greater detail on "synthetic passwords" than the source code, but it doesn't answer the more important questions like:

  • What is the purpose of and what is inside of XXXXXXXXXXXXXXXX.spblob?
  • What is the purpose of and what is inside of XXXXXXXXXXXXXXXX.pwd? What is the purpose of and what is inside of XXXXXXXXXXXXXXXX.pwd?
  • Is the authentication token used in decrypting the CE key?
  • @Robert It is, but it isn't clear enough on whether auth tokens are used in decrypting anything. – Melab Sep 30 '19 at 3:14
1

First. You need to understand, two gatekeeper enroll processes are involved in synthetic passowrd.

Here is the process:

  1. generate synthetic password, it's just a random number
  2. use real password to enroll a fake id. and get sid(secure_id)
  3. use keystore to generate an AES key, and bound it to sid. and use it to encrypt synthetic password
  4. use synthetic password to enroll the real user_id.

So you will see, in order to unlock real user, you need to know synthetic passowrd. However it's encrypted by keystore, so you need real password to unlock the keystore first.

To understand it , you need to first understand how gatekeeper works (eg. what is secure_id? how it works?). That's another topic

00000000000.handle: return value of gatekeeper first enroll by synthetic password derived password.

handle.pwd: second gatekeeper enroll by real password with a fake userid (eg. user_id+10000)

handle.secdis: Actually a random number. used to encrypt synthetic password

handle.spblob: encrypted synthetic password

/data/misc/keystore/user_0/XXX: keystore key. used for encrypting synthetic password.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.