tozny/java-aes-crypto

Build.SERIAL is deprecated in SDK 26 and will return UNKNOWN

ashishdimi09 opened this issue · 4 comments

Referencing this code

String deviceSerial = (String) Build.class.getField("SERIAL").get(
null);
Since SDK 26, Build.SERIAL is deprecated and will NOT return the device's serial number. This makes it will make it non-compatible. Since SDK 26 one should use Build.getSerial() which requires the PHONE permission.

https://developer.android.com/reference/android/os/Build.html#getSerial()

This will probably make the encrypted data non forward compatible when a device is upgraded to SDK 26.

https://developer.android.com/about/versions/pie/android-9.0-changes-28

Build serial number deprecation

In Android 9, Build.SERIAL is always set to "UNKNOWN" to protect users' privacy.

If your app needs to access a device's hardware serial number, you should instead request the READ_PHONE_STATE permission, then call getSerial().

kinex commented

Does this mean that data encrypted in Android 8 or earlier cannot be decrypted in Android 9 or later? What is the reason for using hardware id at all?

kinex commented

After reviewing the code more detaily, I think serial number is not actually used at all in SDK 19 or later (serial number is read in static variable initializer but not used). So there should not be any issue.

To review it yourself see the SDK version checks in PrngFixes.applyOpenSSLFix and PrngFixes.installLinuxPRNGSecureRandom.

Thanks for the feedback and following up on the report for Tozny's AES library. For background, there was an Android entropy bug in ancient history, and Google provides a workaround that's incorporated into our library and is still availability for backward compatibility.

To emphasize, we do not use HW ID to tie an encryption key to a particular device, and we have no reason to think that this change will impact encryption or decryption (unless someone is using our library wrong). All of this code is only invoked on older devices as well. Apologies for not replying to the original report earlier.

Longer term, we want to analyze whether any of the backward compatibility code is still necessary; based on whether & how many devices are still using older versions of Android. The AES library would be significantly simpler without that backward compatibility PRNG fix.