javax.crypto.*packages. In addition, there are Android specific packages
Cryptoprovider has dropped and the provider is deprecated. The same applies to its
SHA1PRNGfor secure random.
AndroidOpenSSL, is preferred above using Bouncy Castle and it has new implementations:
IvParameterSpec.classanymore for GCM, but use the
SSLSessionwith null parameters give a
getInstancemethod and you target any API below 28. If you target Android 9 (API level 28) or above, you get an error.
Cryptosecurity provider is now removed. Calling it will result in a
SHA1PRNGas they are deprecated.
providerto implement Java Security services. That is crucial to ensure secure network communications and secure other functionalities which depend on cryptography.
provider. Application should check if used security provider is up-to-date and if not, update it. It is related to Checking for Weaknesses in Third Party Libraries (MSTG-CODE-5).
KeyGenParameterSpecclass that can be used to ensure the correct key usage in the application.
KeyGenParameterSpecindicates that the key can be used for encryption and decryption, but not for other purposes, such as signing or verifying. It further specifies the block mode (CBC), padding (PKCS #7), and explicitly specifies that randomized encryption is required (this is the default).
"AndroidKeyStore"is the name of security provider used in this example. This will automatically ensure that the keys are stored in the
AndroidKeyStorewhich is beneficiary for the protection of the key.
inputis the encrypted byte array and
ivis the initialization vector from the encryption step:
encryptedBytes) in order to decrypt it later.
SecureRandomto generate AES keys.
KeyPairGeneratorSpecused to create the RSA key pair:
SecureRandomclass to randomly generate a salt. Obviously, the salt is something you want to keep constant to ensure the same encryption key is generated time after time for the same supplied password. Note that you can store the salt privately in
SharedPreferences. It is recommended to exclude the salt from the Android backup mechanism to prevent synchronization in case of higher risk data.
Note that if you take a rooted device or a patched (e.g. repackaged) application into account as a threat to the data, it might be better to encrypt the salt with a key that is placed in the
AndroidKeystore. The Password-Based Encryption (PBE) key is generated using the recommended
PBKDF2WithHmacSHA1algorithm, till Android 8.0 (API level 26). For higher API levels, it is best to use
PBKDF2withHmacSHA256, which will end up with a longer hash value.
java.util.Randomdo not provide sufficient randomness and in fact may make it possible for an attacker to guess the next value that will be generated, and use this guess to impersonate another user or access sensitive information.
SecureRandomshould be used. However, if the Android versions below Android 4.4 (API level 19) are supported, additional care needs to be taken in order to work around the bug in Android 4.1-4.3 (API level 16-18) versions that failed to properly initialize the PRNG.
SecureRandomvia the default constructor without any arguments. Other constructors are for more advanced uses and, if used incorrectly, can lead to decreased randomness and security. The PRNG provider backing
SecretKeySpecclass. We do this by simply recursively grepping on the Smali source code we just obtained. Please note that class descriptors in Smali start with
Land end with
SecretKeySpecclass, we now examine all the highlighted files and trace which bytes are used to pass the key material. The figure below shows the result of performing this assessment on a production ready application. For sake of readability we have reverse engineered the DEX bytecode to Java code. We can clearly locate the use of a static encryption key that is hardcoded and initialized in the static byte array
providerof security services by not specifying it (it means AndroidOpenSSL aka Conscrypt).
Providercan only be specified in
KeyStorerelated code (in that situation
KeyStoreshould be provided as
provider). If other
provideris specified it should be verified according to situation and business case (i.e. Android API version), and
providershould be examined against potential vulnerabilities.
java.util.Randomclass. This class produces an identical sequence of numbers for each given seed value; consequently, the sequence of numbers is predictable.
SecureRandomthat are not created using the default constructor. Specifying the seed value may reduce randomness. Prefer the no-argument constructor of
SecureRandomthat uses the system-specified seed value to generate a 128-byte-long random number.
java.util.Random), then it is probably a statistical PRNG and should not be used in security-sensitive contexts. Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 128-bit seed is a good starting point for producing a "random enough" number.