Native signing on Tezos with Android Biometrics (Part 2)

By Benjamin Fuentes‍

‍

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

Now, we will see what would be the perfect UX.

Tezos Native signing

A quick reminder of available algorithms on Tezos by address:

- tz1 : ed25519
- tz2 : secp256k1
- tz3 : NIST p256r1 (secp256r1 with Blake2B hash)
- tz4 : BLS-MinPk

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

‍

Workarounds

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

• Tezos : secp256r1 + BLAKE2B
• Android : secp256r1 + SHA256

‍

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

‍

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:

         
• Android should support more Signing algorithms: it would require a long lobbying effort on Google          
         
• Android should support Elliptic curve keys to sign: no idea how difficult is for Google to do this          
         
• Tezos should align his tz3 address to use secp256r1+SHA256: almost impossible due to huge regression on the Tezos network          
         
• Tezos should bring a new tz5 address supporting secp256r1+SHA256 and so be aligned with the other web2 FIDO2/WebAuthN algorithm: That should not be hard to do, just a question of roadmap priority

‍

If you want to know more about Marigold, please follow us on social media (Twitter, Reddit, Linkedin)!