You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The password used to encrypt the secret (when the project is configured to encrypt them) is embedded in the app and can be easily retrieved.
The password used to generate the key (in a weak way but this is an other matter) is stored in the binary as a string constant. And from what I saw, the IV is always 0000 (which is bad, you should use a random number instead).
It means that you will have to look for strings in the binary which makes it quite easy to find.
Also the password is stored as a constant (read only data). In the ELF file generated with clang this value is stored in the .rodata section.
Reproduction
You first need to unzip the APK to exctract the so file.
We can clearly identify a the password here: HelloSecretKey. As well as the encrypted secrets 9Lh16XTo0e+6tw+oD7jVx9cBTty2WSxRi75FJTEPpbA= and NkXVm1rkyXcK1SsYkV8l8mgu6BDpwBIt2iqCVjVIQRg=
Then it is easy to decrypt the secrets, you generate the key the same way you did (you should at least use a safe key generation algorithm like PBKDF2 or bcrypt).
Sadly, there is no solution I recommend. Developers should avoid to embed secret keys in their application. The problem you try to solve is actively researched and is called whitebox cryptography. Some solutions try to replace AES implementation and a key by a huge lookup table. However all the public proposal have been broken...
In the meantime, you can try to better generate and hide the key. But understand this will never be safe. Here are some ideas:
Use a random IV. IV does not require to be hiden. Use a different IV per secret you encrypt.
Use a randomly generated key instead of a password. You can have a look to KeyGenerator
You can try to hide the key in other sections of the ELF file, maybe in .text area among code
You can try to randomize a bit the place where the key is stored so it is different for each project
The text was updated successfully, but these errors were encountered:
max-r-b
changed the title
Insecure key storage: secrets very easy to retreive
Insecure key storage: secrets are very easy to retreive
Aug 8, 2018
Description
The password used to encrypt the secret (when the project is configured to encrypt them) is embedded in the app and can be easily retrieved.
The password used to generate the key (in a weak way but this is an other matter) is stored in the binary as a string constant. And from what I saw, the IV is always 0000 (which is bad, you should use a random number instead).
In AESEncryptor.java
In extern-key.h
In cipher-lib.cpp
It means that you will have to look for strings in the binary which makes it quite easy to find.
Also the password is stored as a constant (read only data). In the ELF file generated with clang this value is stored in the .rodata section.
Reproduction
You first need to unzip the APK to exctract the so file.
$ readelf -p .rodata lib/x86/libcipher-lib.so String dump of section '.rodata': [ 0] HelloSecretKey [ f] 9Lh16XTo0e+6tw+oD7jVx9cBTty2WSxRi75FJTEPpbA= [ 3c] 5d41402abc4b2a76b9719d911017c592 [ 5d] NkXVm1rkyXcK1SsYkV8l8mgu6BDpwBIt2iqCVjVIQRg= [ 8a] 58b49c7df6e825734005b0185607e8d7 [ ab] basic_string ...
We can clearly identify a the password here: HelloSecretKey. As well as the encrypted secrets 9Lh16XTo0e+6tw+oD7jVx9cBTty2WSxRi75FJTEPpbA= and NkXVm1rkyXcK1SsYkV8l8mgu6BDpwBIt2iqCVjVIQRg=
Then it is easy to decrypt the secrets, you generate the key the same way you did (you should at least use a safe key generation algorithm like PBKDF2 or bcrypt).
To finish you can decrypt the secret using openssl or whatever
Solution
Sadly, there is no solution I recommend. Developers should avoid to embed secret keys in their application. The problem you try to solve is actively researched and is called whitebox cryptography. Some solutions try to replace AES implementation and a key by a huge lookup table. However all the public proposal have been broken...
In the meantime, you can try to better generate and hide the key. But understand this will never be safe. Here are some ideas:
The text was updated successfully, but these errors were encountered: