Check the VerifiedBootStatus in all operations

[jingtang10]

https://developer.android.com/training/articles/security-key-attestation#certificate_schema_verifiedbootstate

Only proceed with the operation if the VerifiedBootStatus is

• Verified

Will not proceed if the VerifiedBootStatus is

• SelfSigned
• Unverified, or
• Failed

[dustinking-google]

Just a quick summary of what I take to be the context here. Verifying boot status is something that we can do as part of key attestation. We can check that a hardware-backed key pair coming from keystore on the device has a certificate chain going back to the Google Hardware Attestation Root Certificate, which is the relevant root of trust for Android devices. If the boot status is not verified, there's no valid certificate chain, or the certificate chain has been revoked, we can refuse to proceed with db operations and/or invalidate the key pair.

This presupposes that we're using an appropriate hardware-backed key pair from keystore for our key material for encryption. The first thing to do is probably to make sure that db access follows the appropriate patterns/uses the appropriate libraries for this.

Since we are expecting to support devices that are used offline, we can't expect to be able to check a current revocation list on every app startup. We'll have to decide what to require in terms of CRL freshness. There will be some trade-offs between security and convenience here.

In general, there are going to be some of the usual sorts of trade-offs between security and prevention of accidental data loss that go with encryption. Also, since the client is expected to perform the check on its own, there's no way to fully protect against a rooted device that lies to the app in the appropriate ways about the results of all the checks we do.

[dustinking-google]

Since we're using a Room database, we'll probably want to use SQLCipher to encrypt it. My understanding is that we'll need to supply the key material to SQLCipher, so we should be able to generate and manage hardware-backed keypairs for that purpose that we'll be able to perform key attestation on.

[stevenckngaa]

Jing, could you please clarify the meaning of all operations?

While the key attestation result contains the VerifiedBootState that can be used to verify the integrity of the device, can we make an assumption that apps integrated with FHIR library always run on devices that have a hardware backed keystore? Android CDD 11 2.2.5 Security Model 9.11/H-0-2 is only applied to handheld devices but not tablets. Also, earlier Android version may not have hardware backed keystore. This documentation said only supported devices running Android 9.0 or above can have a StrongBox Keymaster.

Alternatively, there is SafetyNet attestation API, which assesses the device's integrity by examining both the device's software and hardware environment. From my understanding, this would work on devices that don't have hardware keystore. And, of course, it uses key attestation on supported devices. However, a drawback is it requires server side integration.

Apart from SafetyNet attestation API, we could also use SafetyNet Verify Apps API to mitigate risk case 3.