I was developing an application to test signing capabilities of Android devices. My app is quite simple: It generates a key -> it signs user-inputted text -> displays the signature
Overall it works with no problems. The other day I tried to figure out which hashing function are supported by Android Keystore, and specifically by StrongBox.
That's what I've tried:
1. Given the list of SHA functions (SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, NONE) only SHA-256 was working on the emulator, which works accordingly to this part of Android Documentation: https://source.android.com/docs/security/features/keystore/features
That made sense: even if StrongBox is not active on the emulator, it was still following the documentation.
2. Then I checked ECDSA hashing with actual mobile phone with StrongBox. (Samsung Galaxy S21 5G) Supported hashing algorithms are SHA1, SHA256, SHA385, SHA512, even NONE, and for some reason the only NOT supported (apart from MD5): SHA224
That's when I've got questions. Why so? I didn't find any reasons or articles regarding that in AOSP neither.
I accept that probably my code is just shitty, (I am still quite new to cryptography) that's why below you will find the functions I used:
FOR ECDSA KEY GENERATION:
@RequiresApi(Build.VERSION_CODES.R)
private fun generateKeyPair() {
try {
val keyPairGenerator = KeyPairGenerator.getInstance(
KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore"
)
val parameterSpec = KeyGenParameterSpec.Builder(
"biometricKeyAlias",
KeyProperties.PURPOSE_SIGN or KeyProperties.PURPOSE_VERIFY
)
.setDigests(KeyProperties.DIGEST_SHA256)
.setUserAuthenticationRequired(true)
.setUserAuthenticationParameters(0, KeyProperties.AUTH_BIOMETRIC_STRONG)
.setAttestationChallenge("attestation_challenge".toByteArray())
.setIsStrongBoxBacked(true)
.build()
keyPairGenerator.initialize(parameterSpec)
val keyPair = keyPairGenerator.generateKeyPair()
publicKey = keyPair.public
Log.d("MainActivity", "Key pair generated successfully")
} catch (e: java.lang.Exception) {
Log.e("MainActivity", "Key pair generation failed", e)
}
}
SIGNING WITH ECDSA:
@RequiresApi(Build.VERSION_CODES.S)
private fun handleButtonClick() {
generateKeyPair()
try {
val keyStore = KeyStore.getInstance("AndroidKeyStore")
keyStore.load(null)
val privateKey = keyStore.getKey("biometricKeyAlias", null) as? PrivateKey
val signature = Signature.getInstance("SHA256withECDSA")
signature.initSign(privateKey)
val cryptoObject = BiometricPrompt.CryptoObject(signature)
currentAuthContext = AuthContext.SIGN_DATA
biometricPrompt.authenticate(
promptInfo,
cryptoObject
) // Pass the CryptoObject here
} catch (e: Exception) {
Log.e("MainActivity", "Error setting up signature: ${e.localizedMessage}")
}
}
For RSA I did the same, just added a padding
.setSignaturePaddings(KeyProperties.SIGNATURE_PADDING_RSA_PKCS1)
And again, for every single digest function the signature was generated successfully, except for SHA224: Error Keystore operation failed during signing operation for both RSA and ECDSA.
In case somebody wants to check revision of my code, feel free to explore https://github.com/VKrivkov/BSP--Offline-Payments-/blob/main/BiometricRSA/app/src/main/java/com/example/biometric/MainActivity.kt
PS: Every operation is done in main activity for the sake of simplicity.
I was changing values here accordingly:
instead of
.setDigests(KeyProperties.DIGEST_SHA256)
I write
.setDigests(KeyProperties.DIGEST_SHA1)
.setDigests(KeyProperties.DIGEST_SHA512), etc.
and instead of
val signature = Signature.getInstance("SHA256withECDSA")
I write
val signature = Signature.getInstance("SHA1withECDSA")
val signature = Signature.getInstance("SHA512withECDSA"), etc.
The reason I'm asking - why only SHA224? It makes no sense to me. I don't need SHA224, just want to inform myself. Documentation is silent about that (or I'm just blind), so I'm wondering, is it a thing, which depends on a phone manufacturer, or something else?
The reason why SHA-224 is not supported by the implementation is probably because it doesn't have much use. SHA-224 is identical to SHA-256; the only differences are that it starts off with different initial values and that it cuts the output size to 224 bits. So it doesn't offer any advantages over SHA-256 other than that it separates the output value from the initial (leftmost) values that SHA-256 produces.
It's main use is for performing hashing for ECDSA with a 224 key size, as it neatly matches the field size. However, the curves with sizes below 256 bits do not offer 128 bits of security. Similarly the hash algorithm also doesn't offer collision resistance of 128 bits. Collision resistance is what matters most for digital signatures. So the P-224 (or secp224r1 curve under a different name) and SHA-224 only offers 112 bits of security for signature generation.
To be honest, I don't see much use of SHA-384 either. To me 192 bits of security doesn't make much sense, and the problem of domain separation only becomes an issue if you reuse the hash for another signature or application. In that case you might also just use the single hash two times and have the exact same issue.
Especially using SHA-384 with RSA PKCS#1, OAEP or PSS padding doesn't make any sense: the signature or ciphertext size remains the same, and you need to perform the same or even more operations (for MGF1 in OAEP or PSS) to get less security. I've tested this and the performance with SHA-512 was markedly better, without a single downside.
Note that SHA-512/224 and SHA-512/256 are also defined by NIST and those are likely not supported. They have been defined because they offer slightly better performance on 64 bit machines than SHA-256. Then again, many smart phone and desktop CPU's now have acceleration for SHA-256, so the speedup is not as necessary anymore. SHA-224 is therefore not the single hash algorithm that is not supported, or at least not anymore.
More information about the usefulness of SHA-224 (or lack thereof) can be found on the cryptography site.