1

Say a legitimate app makes use of either:

  • No keystore
  • Software-only keystore (for encryption/decryption of data)
  • Hardware-backed keystore (for encryption/decryption of data)

For the following scenarios (assuming the device encrypted), I'm wondering if the following assertions are correct and if some questions can be answered.

No keystore

Attacker has physical access to locked device

  • Attacker can't access legitimate app's data without additional exploits

Attacker has physical access to unlocked device

  • Attacker can physically use legitimate app

  • Attacker can't access the legitimate app's raw data (internal storage) without additional exploit to gain root privileges

Attacker has physical access to device + knowledge of PIN

  • Attacker can physically use legitimate app

  • Attacker can physically remove the device's drive and attach it to another device under the attacker's control. The attacker can then retrieve the drive's decryption key by using using the PIN (along with PBKDF2) and access the legitimate app's data.

Attacker has remote access through a malicious app without root access and without knowledge PIN

  • Attacker can't access the legitimate app's data without additional exploits

Attacker has remote access through a malicious app + root access without knowledge of PIN

  • Attacker has full access to legitimate app's data

  • Attacker can easily gain access to all of the legitimate app's internal storage

Attacker has remote access through a malicious app + root access + knowledge of PIN

  • Attacker has full access to legitimate app's data

Software-only keystore

Attacker has physical access to locked device

  • Attacker can't access legitimate app's data

Attacker has physical access to unlocked device

  • Attacker can physically use legitimate app

  • Attacker can't access the app's raw data (internal storage) without an additional exploit to gain root privileges

Attacker has physical access to device + knowledge of PIN

  • Attacker can physically use legitimate app

  • Attacker can physically remove the device's drive and attach it to another device under the attacker's control. The attacker can then retrieve the drive's decryption key by using using the PIN (along with PBKDF2) and access the legitimate app's data.

Attacker has remote access through a malicious app without root access and without knowledge of pin

  • Attacker can't access legitimate app's data

Attacker has remote access through a malicious app + root access without knowledge of PIN

  • Attacker can trick the keystore process into encrypting/decrypting the legitimate app's data.

  • Attacker can't access the legitimate app's data from another device without first obtaining the secrets from the keystore (which requires the PIN). However the attacker can easily install a keylogger to eventually obtain the PIN.

Attacker has remote access through a malicious app + knowledge of PIN without root access

  • Attacker can't access legitimate app's data

Attacker has remote access through a malicious app + root access + knowledge of PIN

  • Attacker can trick the keystore process into encrypting/decrypting the legitimate app's data.

  • Attacker can also easily decrypt the legitimate app's keystore by using the PIN (along with PBKDF2). The legitimate app's data can then be accessed from any other device under the attacker's control.

Hardware-backed keystore

Attacker has physical access to locked device

  • Attacker can't access legitimate app's data

Attacker has physical access to unlocked device

  • Attacker can physically use legitimate app

  • Attacker can't access the legitimate app's raw data (internal storage) without an additional exploit to gain root privileges

Attacker has physical access to device + knowledge of PIN

  • Attacker can physically use legitimate app

  • Attacker can easily gain root access but on some devices the process of doing so will wipe out the phone's data prior to unlocking the bootloader. If data isn't wiped, the attacker gets access to all of the legitimate app's internal storage

  • Attacker can't physically remove the device's drive and attach it to another device under the attacker's control since the keystore is hardware-backed.

Attacker has remote access through a malicious app without root access and without knowledge of PIN

  • Attacker can't access the legitimate app's data without additional exploits

Attacker has remote access through a malicious app + root access without knowledge of PIN

  • Attacker can trick the keystore process into encrypting/decrypting the legitimate app's data.

Attacker has remote access through a malicious app + knowledge of PIN without root access

  • Attacker can't access legitimate app's data

Attacker has remote access through a malicious app + root access + knowledge of PIN

  • Attacker can trick the keystore process into encrypting/decrypting the legitimate app's data.

  • Attacker can't decrypt the legitimate app's private keys since the keys never leave the TEE. The attacker can only encrypt/decrypt data on the compromised device.

Questions / Observations

  • Is the above correct?

  • It seems like in all 3 cases (No keystore, software-only keystore, and hardware-backed):

    • If the attacker is remote and doesn't have root access, he/she cannot access the legitimate app's data

    • If the attacker is remote and does have root access, he/she can access the legitimate app's data.

  • If the above is correct, when considering a remote attacker:

    • What additional security does a software-only keystore provide over no keystore?

    • What additional security does a hardware-backed keystore provide over a software-only keystore? I understand that in the case of a hardware-backed keystore the attacker never actually obtains the legitimate app's private keys and must therefore rely on the compromised device to decrypt the legitimate app's data. But at the end the line the attacker still gets access to the legitimate app's data so it doesn't seem to make a difference)?

1 Answer 1

3

The purpose of a key store is not to restrict access to an application or application data, it's purpose is to protect the credential from being exposed during use. Since a key store will willingly leverage its knowledge to encrypt data or access sensitive application information, it's not really a challenge for an attacker to leverage as you pointed out in many of your breakdowns across all three types.

So why bother with a key store then? In this case, the protection is more to do with your ability to prevent the extraction of keys that may be used for off device purposes such as mobile credentials vai UAF, SSH keys or others. This is especially critical for corporate environments where mobile users may use these keys to access a network remotely.

Therefor, the real difference comes down to how an attacker may get to the keys and replay them from another device.

Without a keystore, the keys are stored on the device with read and potentially write permissions. A user can try to hide the keys, but a rooted user can easily find and overwrite standard file protections. This is certainly insecure and a challenge even for modern desktops today.

With a software keystore, the OS Kernel can set the private key as non-exportable. This means that even a root user can't theoretically extract the key through a nice GUI. However, since the key must still be stored somewhere on a drive, it has been demonstrated that the file can be retrieved and encrypted through a memory attack. This is definitely a lot more work for an attacker, but it's doable.

With a hardware keystore, the OS doesn't even know what they key is. The private key is securely stored in a one way mechanism that can import/generate certificates but cannot export them because they are not designed to do so. This allows applications to reference the hardware stored key without risking the key being dumped to memory. To date, the only attack that's been successfully completed against hardware (that I know of) was due to a manufacturers poor implementation of the RSA standard. The keys weren't exported, but they could be cracked through analysis of the public certificate.

In summation, key stores are not about protecting data or applications, they are for protecting identities from theft. In most consumer cases, this isn't a major concern but for many businesses, the ability to securely store identities without risk of exposure is huge so long as RDP, SSH, and other remote network capabilities exist. I hope this clarifies the true value that they are supposed to provide.

7
  • Thanks. That was very helpful. However it seems like many developers make use of the keystore to encrypt an app's local data. For example see this. According to my understanding and to you answer, there doesn't seem to be any security benefit in using the keystore to encrypt local app data. Would you agree?
    – el_tigro
    Commented Jan 9, 2019 at 21:37
  • From your answer "it has been demonstrated that the file can be retrieved and encrypted through a memory attack", should "encrypted" be replaced with"decrypted"?
    – el_tigro
    Commented Jan 9, 2019 at 21:46
  • @ Catanman - you are correct. I'll make that edit on decrypted. Encrypting data with the keystore is only useful if the attacker is attempting to move the encrypted data off of the device before decypting it. Assuming the attacker has the ability to call against the entire keystore, local attacks can continue without impediment. Commented Jan 9, 2019 at 21:54
  • So I guess encrypting data with the keystore makes it a bit more difficult for an attacker to gain access to the decrypted data, even though the attacker wouldn't require an additional exploit.
    – el_tigro
    Commented Jan 10, 2019 at 20:06
  • The following suggestion in the Recommendations section of This paper paper pretty much confirms what you're saying: "This again does not solve the whole problem: an attacker can change the user ID of the application that uses the files. However, this is again harder than just renaming the files."
    – el_tigro
    Commented Jan 10, 2019 at 20:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .