Current behavior
At build time, the plaintext configuration is encrypted and embedded into the native library file alongside some obfuscation operations.
However, the libreact-native-keys.so library file alone is currently sufficient for an attacker to retrieve the plaintext config.
Bypassing the following key validation procedure:
|
string hash; |
|
string halfString = base64Secret.substr(base64Secret.length() / 2); |
|
if (key == halfString) |
|
{ |
|
return plaintext; |
|
} |
|
else |
|
{ |
|
return ""; |
|
} |
Expected behavior
The key parameter (pass in from Java/Objective-C layer) should be a cryptographically required component in the decryption process. An attacker should not be able to retrieve the plaintext configuration statically from the libreact-native-keys.so file alone.
Proposed Solution
This can be addressed in several ways, but the core requirement is that the parameter needed to decrypt the config is not stored entirely in one place.
My recommendation is to use the key parameter as an active variable to reconstruct or decrypt the values of getEncryptedSecureData and/or getPasswordSecureData. By deriving the final decryption key partially from the runtime argument, the .so file alone will no longer contain all the necessary information to extract the sensitive configuration.
Current behavior
At build time, the plaintext configuration is encrypted and embedded into the native library file alongside some obfuscation operations.
However, the
libreact-native-keys.solibrary file alone is currently sufficient for an attacker to retrieve theplaintextconfig.Bypassing the following key validation procedure:
react-native-keys/cpp/crypto.cpp
Lines 27 to 36 in 0535db4
Expected behavior
The
keyparameter (pass in from Java/Objective-C layer) should be a cryptographically required component in the decryption process. An attacker should not be able to retrieve the plaintext configuration statically from thelibreact-native-keys.sofile alone.Proposed Solution
This can be addressed in several ways, but the core requirement is that the parameter needed to decrypt the config is not stored entirely in one place.
My recommendation is to use the
keyparameter as an active variable to reconstruct or decrypt the values ofgetEncryptedSecureDataand/orgetPasswordSecureData. By deriving the final decryption key partially from the runtime argument, the .so file alone will no longer contain all the necessary information to extract the sensitive configuration.