TECHNOLOGY

Signing on Tezos with Android Biometrics | Part 2

In the second part of this tutorial, Benjamin Fuentes of adoption team Marigold explains how to sign onto Tezos using biometrics.

By Benjamin Fuentes

750 words, 4 minute read

Signing Android Phone Concept Blog Cover 2

In the first part of this tutorial, we talked about different solutions for signing Tezos transactions on Android but there is no native solution with the highest protection.

Now, we will see what would be the perfect UX

Tezos Native signing #

A quick reminder of available algorithms on Tezos by address:

Signing requires an asymmetric keypair and a hash algorithm. These algorithms have been selected for Blockchain performance and security purposes.

Android Keystore Crypto algorithm support #

The Android Keystore system lets you store cryptographic keys in a container to make them more difficult to extract from the device. Once keys are in the keystore, you can use them for cryptographic operations, with the key material remaining non-exportable.

This is the most secure way to handle security and integrate the Biometrics feature. An alternative would be to use another keystore that will do software-security protection and encrypt a file on the system. This later solution is less secure and does not leverage Biometrics support.

Once we go with the Android Keystore we have access to a limited list of supported algorithms

ClassRecommendation
CipherAES in either CBC or GCM mode with 256-bit keys (such as AES/GCM/NoPadding)
MessageDigestSHA-2 family (such as SHA-256)
MacSHA-2 family HMAC (such as HMACSHA256)
SignatureSHA-2 family with ECDSA (such as SHA256withECDSA)

Workarounds #

Sadly, there is no match between Tezos algorithms and Android ones. The closest match is :

Solution 1: Use an RSA key on the Keystore to encrypt any Tezos private key #

This solution is not optimal because the RSA key needs to decrypt the private key on the phone for signing transactions, at this point the Tezos private key is plaintext and this is potentially dangerous

Solution 2: Use SpongyCastle to inject missing security algorithms to Android Keystore #

SpongyCastle is a third-party Crypto provider Java library supporting secp256r1 and BLAKE2B hash algorithms. The solution consists in generating a secp256r1 keypair in the Android Keystore and protecting it with Biometrics access. Once the user wants to sign a Tezos transaction, we use the Cipher returns by the Biometric callback to encrypt the Blake2B hash of the transaction payload, this way, a valid Tezos (secp256r1 + BLAKE2B) signature is generated and sent back to the dapp.

To improve the UX, we also design a new Taquito signer to delegate the sign function to the Android device

Demo #

In this video, I am showcasing the below scenario with Android Biometrics with fingerprint access:

http://www.youtube.com/watch?v=r7tnj3NIZho

  1. The user opens the decentralized application embedding my custom Android Wallet Biometric SDK
  2. Because it is the first time the user enters the application, there is not yet a generated Keypair. The SDK is initializing the account configuration
  3. A secp256r1 is generated and imported into the Android Keystore with Biometrics protection. On the logs, we can see that the key is under Hardware security protection
  4. The user can see his tz3 address and balance to 0
  5. We send it some Tez to be able to pay for the first transaction
  6. The user sends 1 mutez to Alice

The demo does not work until the end because … Elliptic Curves on Android cannot sign a payload.

This is quite sad really … 😥

Conclusion #

Recent developments on Elliptic curves on Android have been driven by WebAuthN and Fido2 initiative. Today there is no match with the crypto space yet (not even on Ethereum using secp256k1). Also, to have a maximum of the device security and use Biometrics properly we have to use the Android Keystore.

To move the lines, there are some possibilities requiring heavy or more light development: