Cryptography is an indispensable tool used to protect information in computing systems. It is used everywhere and by billions of people worldwide on a daily basis. It is used to protect data at rest and data in motion. While extremely useful, cryptography is also highly brittle. The most secure cryptographic system can be rendered completely insecure by a single specification or programming error.to argue that a cryptosystem is secure, we rely on mathematical modeling and proofs to show that a particular system satisfies the security properties attributed to it. We often need to introduce certain plausible assumptions to push our security arguments through. This presentation is about exactly that: constructing practical cryptosystems in android platform for which we can argue security under plausible assumptions.part one just covers fundamentals topics in cryptography world. see videos : https://www.youtube.com/playlist?list=PLT2xIm2X7W7j-arpnN90cuwBcNN_5L3AU https://www.aparat.com/v/gtlHP

1. DO THE
RIGHT THING
EVEN IF NO
ONE IS
LOOKING
How to do cryptography right in android
Part #2
Arash Ramez

2. TOC
• Dive into Android KeyStoreProvider
• How to Implement Fingerprint Authentication
• SSL Pinning
• End-to-End Encryption Communication

3. Android Keystore
• KeyStore (API 1) / JKS or BKS based keystores
• You will have to create a KeyStore file and you will also have to manage the
secret to access to it. This secret is very sensitive and difficult to hide from
attackers.
• Android KeyStore Provider (API 18)
• TEE based keystore
• check KeyInfo#isInsideSecureHardware() method to see whether the key is saved there
or not
• significantly enhanced in Android 6.0 (API level 23)
• Android 9 (API level 28)
• StrongBox (Titan M on Google Pixel 3)

4. Android keystore system
• The Android Keystore system lets you store cryptographic keys in a
container to make it more difficult to extract from the device. Once keys
are in the keystore, they can be used for cryptographic operations with the
key material remaining non-exportable
• introduced in Android 4.3 (API level 18)
• Firstly, Android Keystore mitigates unauthorized use of key material outside
of the Android device by preventing extraction of the key material from
application processes and from the Android device as a whole
• Secondly, Android KeyStore mitigates unauthorized use of key material on
the Android device by making apps specify authorized uses of their keys
and then enforcing these restrictions outside of the apps' processes.

5. Security Features: Extraction prevention
• Key material never enters the application process.
• Key material may be bound to the secure hardware.
• (e.g., Trusted Execution Environment (TEE), Secure Element (SE)) of
the Android device

6. Android 4.3
• Android Key Store' has a public API for storing and using app-private
keys.
• There is an API and even a system settings field that lets you check
whether the credential store is hardware-backed (Nexus 4, Nexus 7)
or software only (Galaxy Nexus).
• isBoundKeyAlgorithm (deprecated in API level 23)
• Whether the key is bound to the secure hardware is known only once the key has been
imported. To find out, use:

7. Android 4.3 (API version 18)
• Instead of introducing yet another Android-specific API, key store access is
exposed via standard JCE APIs, namely KeyGenerator and KeyStore. Both
are backed by a new Android JCE provider, AndroidKeyStoreProvider and
are accessed by passing "AndroidKeyStore" as the type parameter of the
respective factory methods.
• those APIs were actually available in 4.2 as well, but were not public
• For a full sample detailing their usage, refer to the BasicAndroidKeyStore project in
the Android SDK
• The key store now supports multi-user devices and each user gets their
own set of keys
• stored in /data/misc/keystore/user_N, where N is the Android user ID
• Keys names (aliases) are mapped to filenames as before, and the owner app UID
now reflects the Android user ID as well.

8. Android 4.3: How to use?
• First, you create a KeyPairGeneratorSpec that describes the keys you
want to generate (including a self-signed certificate)
• Initialize a KeyPairGenerator with it and then generate the keys by
calling generateKeyPair()
• The most important parameter is the alias, which you then pass to
KeyStore.getEntry() in order to get a handle to the generated keys
later.
• There is currently no way to specify key size or type and generated
keys default to 2048 bit RSA

9. Android 4.3: Hardware or Software?
• If the device has a hardware-backed key store implementation, keys
will be generated outside of the Android OS and won't be directly
accessible even to the system (or root user).
• If the implementation is software only, keys will be encrypted with a
per-user key-encryption master key. We'll discuss key protection in
detail later.

10. Android 4.3: Keystore Implementation
• This hardware-backed design was initially implemented in the original
Jelly Bean release (4.1)
• Credential storage Has been implemented as a native keystore
daemon that used a local socket as its IPC interface.
• The daemon has finally been retired and replaced with a 'real' Binder service,
which implements the IKeyStoreService interface.
• What's interesting here is that the service is implemented in C++, which is
somewhat rare in Android.
• IKeyStoreService gets 4 new operations: getmtime(), duplicate(),
is_hardware_backed() and clear_uid().

11. Internals : 4 riders of apocalypse
• getmtime()
• returns the key modification time
• duplicate()
• copies a key blob (used internally for key migration)
• is_hardware_backed()
• will query the underlying keymaster implementation and return true when it
is hardware-backed.
• clear_uid()
• When an app that owns key store-managed keys is uninstalled for a user, only
keys created by that user are deleted.

12. Internals : key storage structure
• When an app that owns key store-managed keys is uninstalled for a user,
only keys created by that user are deleted.
• If an app is completely removed from the system, its keys are deleted for all
users.
• This prevents a different app that happens to get the same UID from accessing an
uninstalled app's keys.
• Key store reset, which deletes both key files and the master key, also
affects only the current user. Here's how key files for the primary user
might look like:
• 1000_CACERT_ca
• 1000_CACERT_cacert
• 10248_USRCERT_myKey
• 10248_USRPKEY_myKey
• 10293_USRCERT_rsa_key0
• 10293_USRPKEY_rsa_key0

13. Internals : How to protect keys
• The actual files are owned by the keystore service (which runs as the
keystore Linux user) and it checks the calling UID to decide whether
to grant or deny access to a key file, just as before. If the keys are
protected by hardware, key files may contain only a reference to the
actual key and deleting them may not destroy the underlying keys.
• Therefore, the del_key() operation is optional and may not be implemented.

14. The hardware in 'hardware-backed'
• Let's briefly discuss how it is implemented on the Nexus 4.
• The Nexus 4 is based on Qualcomm's Snapdragon S4 Pro APQ8064
SoC
• Like most recent ARM SoC's it is TrustZone-enabled and Qualcomm
implement their Secure Execution Environment (QSEE) on top of it.
• https://www.arm.com/products/silicon-ip-security
• Trusted application are separated from the main OS and the only way
to interact with them is through the controlled interface the
/dev/qseecom device provides.
• Load the libQSEEComAPI (proprietary)
• use the functions it provides to send 'commands' to the QSEE

15. The hardware in 'hardware-backed'
• In the case of the Nexus 4 keymaster, the used commands are:
GENERATE_KEYPAIR, IMPORT_KEYPAIR, SIGN_DATA and VERIFY_DATA.
• The keymaster implementation merely creates command structures,
sends them via the QSEECom API and parses the replies. It does not
contain any cryptographic code itself.
• The QSEE keystore trusted app, doesn't return simple references to
protected keys, but instead uses proprietary encrypted key blobs
(Similar to Thales HSMs)

16. Master Key
• In this model, the only thing that is actually protected by hardware
is some form of 'master' key-encryption key (KEK), and user-
generated keys are only indirectly protected by being encrypted
with the KEK.
• This allows for practically unlimited number of protected keys
• disadvantage: if the KEK is compromised, all externally stored key blobs are
compromised as well
• Of course, the actual implementation might generate a dedicated KEK for
each key blob created or the key can be fused in hardware; either way no
details are available

17. Master Key(cont)
• Qualcomm keymaster key blobs
are defined in AOSP code as
shown beside.
• This suggest that private
exponents are encrypted using
AES, most probably in CBC
mode, with an added HMAC-
SHA256 to check encrypted data
integrity. Those might be further
encrypted with the Android key
store master key when stored on
disk.

18. Are other implementations possible?
• Theoretically, a hardware-backed keymaster implementation does not
need to be based on TrustZone.
• Any dedicated device that can generate and store keys securely can
be used
• The usual suspects being embedded secure elements (SE) and TPMs
• However, there are no mainstream Android devices with dedicated
TPMs and recent flagship devices have began shipping without
embedded SEs, most probably due to carrier pressure (price is hardly
a factor, since embedded SEs are usually in the same package as the
NFC controller). https://www.nfcworld.com/2013/07/30/325212/no-
secure-element-in-new-nexus-7/

19. Are other implementations possible?
• All mobile devices have some form of UICC (SIM card), which typically
can generate and store keys
• So why not use that?
• Android still doesn't have a standard API to access the UICC, even though
'vendor' firmwares often include one. So while one could theoretically
implement a UICC-based keymaster module compatible with the UICC's of
your friendly neighbourhood MNO, it is not very likely to happen.

20. How secure are hardware-backed keys?
• The answer is, as usual, it depends.
• If they are stored in a real, dedicated, tamper-resistant hardware module, such as an embedded
SE, they are as secure as the SE
• And since this technology has been around for over 40 years, and even recent attacks are only
effective against SEs using weak encryption algorithms, that means fairly secure. As we mentioned
in the previous section, there are no current keymaster implementations that use actual SEs, but
we can only hope.
• What about ARM TrustZone?
• At the end trusted applications are just software that runs at a slightly lower level than Android. As
such, they can be readily reverse engineered, and of course vulnerabilities have been found.
• https://www.youtube.com/watch?v=8dYzv7_hKyE ( RootKits)
• while TrustZone secure applications might provide effective protection against Android malware
running on the device, given physical access, they, as well as the TrustZone kernel, are exploitable
themselves. Applied to the Android key store, this means that if there is an exploitable
vulnerability in any of the underlying trusted applications the keymaster module depends on, key-
encryption keys could be extracted and 'hardware-backed' keys could be compromised.

21. Advanced usage
• Android 4.3 offers a well defined public API to the system key store. It
should be sufficient for most use cases, but If needed you can
connect to the keystore service directly (as always, not really
recommended)
• Because it is not part of the Android SDK, the IKeyStoreService
doesn't have wrapper 'Manager' class, so if you want to get a handle
to it, you need to get one directly from the ServiceManager.
• That too is hidden from SDK apps, but, as usual, you can use
reflection

22. Advanced usage(cont.)
• Of course, if the calling UID doesn't have the necessary permission,
access will be denied, but most operations are available to all apps.
• By using the IKeyStoreService directly you can store symmetric keys or
other secret data in the system key store by using the put() method,
which the current java.security.KeyStore implementation does not
allow (it can only store PrivateKey's). Such data is only encrypted by
the key store master key, and even the system key store is hardware-
backed, data is not protected by hardware in any way.

23. Advance Usage Scenario
• Storing application secrets in Android's credential storage
• Let's quickly review what we know about the keystore daemon
(described in more detail here):
• it's a native daemon, started at boot
• it provides a local control socket to allow apps and system services to talk to it
• it encrypts keys using an AES 128 bit master key
• encrypted keys are stored in /data/misc/keystore, one file per key
• the master key is derived from the device unlock password or PIN
• it authorizes administration commands execution and key access based on
caller UID

24. Storing application secrets in Android's
credential storage
• Cons: Required using private
(hidden) keystore APIs, and was thus
not guaranteed to be portable across
versions

25. Typical usage
• Since the sign() operation implements a 'raw' signature operation
(RSASP1 in RFC 3447), key store-managed (including hardware-
backed) keys can be used to implement signature algorithms not
natively supported by Android. You don't need to use the
IKeyStoreService interface, because this operation is available through
the standard JCE Cipher interface:

26. Custom API
• If you want to use a more modern (and provably secure) signature
algorithm than Android's default PKCS#1.5 implementation, such as
RSA-PSS you can accomplish it with something like this (see sample
project for AndroidRsaEngine)/ (Using SpongyCastle)

27. Key Exchange Usage
• If you need to implement RSA key exchange, you can easily make use
of OAEP padding like this:

28. Random Key Generation
• Some SecureRandom Thoughts ( Vulnerability)
• http://android-developers.blogspot.jp/2013/08/some-securerandom-thoughts.html
• The keystore daemon/service uses /dev/urandom directly as a source of randomness,
when generating master keys
• used for key file encryption
• HW-based Keys:
• They are not generated using Android's default SecureRandom implementation
• Bouncy Castle's PSS and OAEP implementations do use SecureRandom internally
• you might want to seed the PRNG 'manually' before starting your app to make sure it doesn't start
with the same PRNG state as other apps.
• RSA keys generated by the softkeymaster OpenSSL-based software implementation
might be affected, because OpenSSL uses RAND_bytes() to generate primes
• Are probably OK since the keystore daemon/service runs in a dedicated process and the OpenSSL
PRNG automatically seeds itself from /dev/urandom on first access

29. Android Security: The Forgetful Keystore
• https://doridori.github.io/android-security-the-forgetful-
keystore/#sthash.G3v7Ei7g.FKZKJA9f.dpbs
• Due to a nasty bugof Android (more common before Android 5) if the
user changes the lock screen pattern into a password or just deletes
the pattern, the KeyStore will be fully corrupted. The same happens
when the user performs a "Clear credentials" from the Android
settings. With the classic KeyStore instead, you could store it in the
external storage and keep it even after a device factory reset.
However, as mentioned before, it is still less secure than the provider.

30. Recommended Book and Sample Application
https://github.com/nelenkov/android-keystore

31. Keystore redesign in Android M
• Quite significant security change in Android M : KeyStore Redesign
• The most visible new feature is support for generating and using
symmetric keys that are protected by the system keystore.
• (refer to slide no.24)
• Android M introduces a keystore-backed symmetric KeyGenerator,
and adds support for the KeyStore.SecretKeyEntry JCA class
• To support this, Android-specific key parameter classes and associated
builders have been added to the Android SDK.

32. Use case:
• Here is how generating and retrieving a 256-bit AES key

33. Enhancements
• This is pretty standard JCA code, and is in fact very similar to how
asymmetric keys (RSA and ECDSA) are handled in previous Android
versions. What is new here is, that
• Along with basic properties such as key size and alias, you can now specify the
supported key usage (encryption/decryption or signing/verification), block
mode, padding, etc.
• Those properties are stored along with the key, and the system will disallow
key usage which doesn't match the key's attributes.
• This allows insecure key usage patterns (ECB mode, or constant IV for CBC
mode, for example) to be explicitly forbidden, as well as constraining certain
keys to a particular purpose, which is important in a multi-key cryptosystem
or protocol.
• Key validity period (separate for encryption/signing and
decryption/verification) can also be specified.

34. User Authentication can be Required!
• Another major new feature is
requiring use authentication
before allowing a particular key
to be used
• Thus, a key that protects sensitive
data, can require user
authentication on each use (e.g.,
decryption), while a different key
may require only a single
authentication per session (say,
every 10 minutes).
• setUserAuthenticationRequired()

35. User Authentication can be Required!
• The newly introduced key properties are available for both symmetric
and asymmetric keys. An interesting detail is that apparently trying to
use a key is now the official way.
• Sample app:
• https://github.com/googlesamples/android-ConfirmCredential
• Video:
• https://www.youtube.com/watch?v=VOn7VrTRlA4
• The newly introduced FingerprintManager authentication APIs also
make use of cryptographic objects, so this may be part of a larger
picture, which we have yet to see.

36. Keystore and keymaster implementation
• On a high level, key generation and storage work the same as in previous
versions.
• The system keystore daemon provides an AIDL interface, which framework classes
and system services use to generate and manage keys. The keystore AIDL has gained
some new, more generic methods, as well support for a 'fallback' implementation
but is mostly unchanged.
• The keymaster HAL and its reference implementation have, however, been
completely redesigned.
• The 'old' keymaster HAL is retained for backward compatibility as version 0.3, while
the Android M version has been bumped to 1.0, and offers a completely different
interface.
• The new interface allows for setting fine-grained key properties (also called 'key
characteristics' internally)
• Key operations support begin/update/finish pattern.

37. Key blobs
• Keymaster v1.0 key blobs are wrapped inside keystore blobs, which
are in turn stored as files in /data/misc/keystore/user_X, as before
(where X is the Android user ID, starting with 0 for the primary user).
• Are variable size and Employ a tag-length-value (TLV) format
• include a version byte, a nonce, encrypted key material, a tag for
authenticating the encrypted key, as well as two authorization sets (enforced
and unenforced), which contain the key's properties
• Key material is encrypted using AES in OCB mode,
• which automatically authenticates the cipher text and produces an
authentication tag upon completion
• Each key blob is encrypted with a dedicated key encryption key (KEK), which is
derived by hashing a binary tag representing the key's root of trust (hardware
or software), concatenated with they key's authorization sets.
• Finally, the resulting hash value is encrypted with the master key to derive the
blob's KEK

38. Per-key authorization
• The
setUserAuthenticationRequired()
method of the key parameter
builder allows you to require that
the user authenticates before they
are authorized to use a certain key
(not unlike iOS's Keychain).
• While this is not a new concept
(system-wide credentials in Android
4.x require access to be granted per-
key), the interesting part is how it is
implemented in Android M.
• The system keystore service now holds an
authentication token table, and a key operation is
only authorized if the table contains a matching
token. Tokens include an HMAC and thus can
provide a strong guarantee that a user has actually
authenticated at a given time, using a particular
authentication method.
• Authentication tokens are now part of
Android's HAL, and currently support two
authentication methods: password and
fingerprint. Here's how tokens are defined:

39. Per-key authorization(cont.)
• Tokens are generated by a newly introduced system component, called the
gatekeeper. The gatekeeper issues a token after it verifies the user-entered
password against a previously enrolled one.
• it computes an HMAC over the all fields of the hw_auth_token_t structure up to
hmac using a dedicated key, and stores it in the hmac field. The serialized
hw_auth_token_t structure then serves as an authentication token, and can be
passed to other components that need to verify if the user is authenticated.
• Management of the token generation key is implementation-dependent, but it is
expected that it is securely stored, and inaccessible to other system applications (
HW-backed)
• Gatekeeper implementation the HMAC key will likely be backed by hardware, and
the gatekeeper module could execute entirely within the TEE, and thus be
inaccessible to Android. The low-level gatekeeper interface is part of Android M's
HAL and is defined in hardware/gatekeeper.h.
• Run as binary in init.rc

40. Requirements
• Lock Screen
• Choose a Key
• Key Storage
• Key Generation
• Key Management
• Encryption & Decryption

41. Device Lock
• If you want to secure your data — protect your device.
• Before providing an access to any of application features, we can
request user to setup his device Lock Screen (if it has been not setup
yet)
• There is a special system service —KeyguardManager, that can help
us with this task.

42. Secure Device : User Authentication
• Require user authentication for key use:
• When generating or importing a key into the AndroidKeyStore you can specify
that the key is only authorized to be used if the user has been authenticated.
• The user is authenticated using a subset of their secure lock screen credentials
(pattern/PIN/password, fingerprint).
• This is an advanced security feature
• useful only if your requirements are that a compromise of your application process after
key generation/import (but not before or during) cannot bypass the requirement for the
user to be authenticated to use the key.

43. Secure Device : User Authentication(cont)
• When a key is authorized to be used only if the user has been
authenticated, it is configured to operate in one of the two modes:
• 1) User authentication authorizes the use of keys for a duration of time.
• All keys in this mode are authorized for use as soon as the user unlocks the secure
lock screen or confirms their secure lock screen credential using the
KeyguardManager.createConfirmDeviceCredentialIntent flow
• The duration for which the authorization remains valid is specific to each key, as specified
using setUserAuthenticationValidityDurationSeconds during key generation or import.
• Such keys can only be generated or imported if the secure lock screen is enabled (see
KeyguardManager.isDeviceSecure())
• These keys become permanently invalidated once the secure lock screen is disabled
(reconfigured to None, Swipe or other mode which doesn't authenticate the user) or
forcibly reset (e.g. by a Device Administrator).

44. Secure Device : User Authentication(cont)
• 2) User authentication authorizes a specific cryptographic operation
associated with one key.
• In this mode, each operation involving such a key must be individually
authorized by the user. Currently, the only means of such authorization is
fingerprint authentication: FingerprintManager.authenticate
• Such keys can only be generated or imported if at least one fingerprint is
enrolled (see FingerprintManager.hasEnrolledFingerprints). These keys
become permanently invalidated once a new fingerprint is enrolled or all
fingerprints are unenrolled.

45. Device Lock Check
• isDeviceSecure method— checks if device is secured with a PIN,
pattern or password. Available from API 23.

46. Choose Key
RSA — the only one available algorithm we can use, in Cipher, for Android Key
Store Asymmetric Keys, on API 18+ devices.

47. Key Storage
• On Android, cryptographic keys are stored in the KeyStore:
• Two Fabric Method :
• There’s also another KeyStore fabric method: getInstance("type", "provider") —that
returns a KeyStore object of the specified type from the specified Provider.
• There is one more system Provider, called “AndroidKeyStoreBCWorkaround”.

48. Key Generation
• Similarly to the key store, there is a fabric getInstance(“algorithm”,
“provider”) method, that should be used to create a key.
• There’s also another, simplified, version of that method —
getInstance(“algorithm”) . Don’t use it.

49. KeyPair generation before and after M:
• Before M, KeyPairGeneratorSpec class should be used to provide it:
• If you are trying to save key into the key store, with alias that exists
already, it will be overwritten with new key. Use setAlias() builders
method to provide alias.

50. In M:
• KeyGenParameterSpec was introduced. It is used to initialize
asymmetric and symmetric keys. KeyPairGeneratorSpec was
deprecated.

51. Asymmetric Keys
• Asymmetric keys must be signed with a certificate.
• It is mostly used in client -server communications, where client (or
server) is verifying certificate, to be certain that the server really is
who he claims to be (and not a man in the middle). You will be not
able to save asymmetric key without certificate.
• If both public and private keys are desired for usage in one
application, then you can just create a fake, self signed, certificate.
• Certificate requires a start and end date (validity duration), that could
be set with setStartDate and setEndDate builder methods. Also you
need to provide serial number and a subject of certificate, that can be
used with setSerialNumber and setSubject builder methods.

52. Asymmetric Keys(cont.)
• There’s no more need to define a fake certificate manually,
KeyGenParameterSpec will do this automatically. You still can customize
default values with:
• Finally, whenKeyPairGenerator instance is initialized with specification, use
generateKeyPair() method, to create private-public key pair. In Android Key
Store provider, this method will automatically save key in KeyStore.

53. Key Management
• KeyStore provides methods, that helps us to manage saved keys:

54. Encryption & Decryption
• On Android, encryption and
decryption are made with
Cipher:
• The transformation
represents the algorithm,
that will be used for
encryption or decryption, in
format of:
”Algorithm/Mode/Padding”.

55. Encryption & Decryption

56. Generate a new private key (example)
• Generating a new PrivateKey requires that you also specify the initial
X.509 attributes that the self-signed certificate will have. You can use
KeyStore.setKeyEntry to replace the certificate at a later time with a
certificate signed by a Certificate Authority (CA).

57. Work with keystore entries
• List entries
• https://developer.android.com/training/articles/keystore#java

58. Sign and verify data
• https://developer.android.com/training/articles/keystore#java

59. Android 9/P (StrongBox)
• Supported devices running Android 9 (API level 28) or higher installed
can have a StrongBox Keymaster, an implementation of the
Keymaster HAL that resides in a hardware security module
• Its own CPU.
• Secure storage.
• A true random-number generator.
• Additional mechanisms to resist package tampering and unauthorized
sideloading of apps.
• When checking keys stored in the StrongBox Keymaster, the system
corroborates a key's integrity with the Trusted Execution Environment
(TEE).

60. Android 9/P (StrongBox)
• To support low-power StrongBox implementations, a subset of algorithms
and key sizes are supported:
• RSA 2048
• AES 128 and 256
• ECDSA P-256
• HMAC-SHA256 (supports key sizes between 8 bytes and 64 bytes, inclusive)
• Triple DES 168
• When generating or importing keys using the KeyStore class, you indicate a
preference for storing the key in the StrongBox Keymaster by passing true
to the setIsStrongBoxBacked() method in either the
KeyGenParameterSpec.Builder class or the KeyProtection.Builder class.

61. Import encrypted keys more securely
• Android 9 (API level 28) and higher allow you to
import encrypted keys securely into the Keystore
using an ASN.1-encoded key format. The Keymaster
then decrypts the keys in the Keystore, so the
content of the keys never appears as plaintext in
the device's host memory. This process provides
additional key decryption security.
• Note: This feature is supported only on devices that
ship with Keymaster 4 or higher.
• https://android-
developers.googleblog.com/2018/10/building-titan-
better-security-through.html
• http://www.whiteboxcrypto.com/

62. StrongBox is Available

63. New Features
• Android Protected Confirmation
• Supported devices that run
Android 9 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.
• https://android-
developers.googleblog.com/2018/
10/android-protected-
confirmation.html

64. Protected Confirmation
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 (set setUserConfirmationRequired()
true)
• 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.

65. Protected Confirmation(cont.)
• 4) Set up the
ConfirmationCallback
object that informs
your app when the
user has accepted the
prompt shown in a
confirmation dialog:

66. Protected Confirmation(cont.)
• 5) Add logic similar to that shown in the following code snippet to
display the dialog itself:
https://developer.android.com/training/articles/security-android-protected-confirmation