Save the date! Android Dev Summit is coming to Mountain View, CA on November 7-8, 2018.

Android Protected Confirmation

Supported devices that run Android 9 (API level 28) or higher give you the ability to use Android Protected Confirmation. When using this workflow, your app displays a prompt to the user, asking them to approve a short statement. This statement allows the app to reaffirm that the user would like to complete a sensitive transaction, such as making a payment.

If the user accepts the statement, your app can use a key from Android Keystore to sign the message shown in the dialog. The signature indicates, with very high confidence, that the user has seen the statement and has agreed to it.

Caution: Android Protected Confirmation doesn't provide a secure information channel for the user. Your app cannot assume any confidentiality guarantees beyond those that the Android platform offers. In particular, don't use this workflow to display sensitive information that you wouldn't ordinarily show on the user's device.

After the user confirms the message, its integrity is assured, but your app must still use data-in-transit encryption to assure the confidentiality of the signed message.

To provide support for high-assurance user confirmation in your app, complete the following steps:

  1. Generate an asymmetric signing key using the KeyGenParameterSpec.Builder class. When creating the key, pass true into setUserConfirmationRequired(). Also, call setAttestationChallenge(), passing a suitable challenge value provided by the relying party.

  2. Enroll the newly-generated key and your key's attestation certificate with the appropriate relying party.

  3. Send transaction details to your server and have it generate and return a blob of extra data. Extra data might include the to-be-confirmed data or parsing hints, such as the locale of the prompt string.

    For a more secure implementation, the blob must contain a cryptographic nonce for protection against replay attacks and to disambiguate transactions.

  4. Set up the ConfirmationCallback object that informs your app when the user has accepted the prompt shown in a confirmation dialog:

    class MyConfirmationCallback : ConfirmationCallback() {
        override fun onConfirmed(dataThatWasConfirmed: ByteArray?) {
            super.onConfirmed(dataThatWasConfirmed)
            // Sign dataThatWasConfirmed using your generated signing key.
            // By completing this process, you generate a "signed statement".
        }
    
        override fun onDismissed() {
            super.onDismissed()
            // Handle case where user declined the prompt in the
            // confirmation dialog.
        }
    
        override fun onCanceled() {
            super.onCanceled()
            // Handle case where your app closed the dialog before the user
            // could respond to the prompt.
        }
    
        override fun onError(e: Exception?) {
            super.onError(e)
            // Handle the exception that the callback captured.
        }
    }
    

    If the user approves the dialog, the onConfirmed() callback is called. The dataThatWasConfirmed blob is a CBOR data structure that contains, among other details, the prompt text that the user saw as well as the extra data that you passed into the ConfirmationPrompt builder. Your app should use the previously-created key to sign the dataThatWasConfirmed blob. You should then pass this blob, along with the signature and transaction details, back to the relying party.

    To make full use of the security assurance that Android Protected Confirmation offers, the relying party must perform the following steps upon receiving a signed message:

    1. Check the signature over the message as well as the attestation certificate chain of the signing key.
    2. Check that the attestation certificate has the TRUSTED_CONFIRMATION_REQUIRED flag set, which indicates that the signing key requires trusted user confirmation. If the signing key is an RSA key, check that it doesn't have the PURPOSE_ENCRYPT or PURPOSE_DECRYPT property.
    3. Check extraData to make sure that this confirmation message belongs to a new request and hasn't been processed yet. This step protects against replay attacks.
    4. Parse the promptText for information about the confirmed action or request. Remember that the promptText is the only part of the message that the user actually confirmed. The relying party must never assume that to-be confirmed data included in extraData corresponds to the promptText.
  5. Add logic similar to that shown in the following code snippet to display the dialog itself:

    // This data structure varies by app type. This is just an example.
    data class ConfirmationPromptData(val sender: String,
            val receiver: String, val amount: String)
    
    val myExtraData: ByteArray = byteArrayOf()
    val myDialogData = ConfirmationPromptData("Ashlyn", "Jordan", "$500")
    val threadReceivingCallback = Executor { runnable -> runnable.run() }
    val callback = MyConfirmationCallback()
    
    val dialog = ConfirmationPrompt.Builder(context)
            .setPromptText("${myDialogData.sender}, send
                            ${myDialogData.amount} to
                            ${myDialogData.receiver}?")
            .setExtraData(myExtraData)
            .build()
    dialog.presentPrompt(threadReceivingCallback, callback)