3

I am working on an application where we need to encrypt certain assets at compile time in Gradle. We then need to decrypt them with the same private key, so we are using a symmetric key system but we could go to an asymmetric system. The key issue is that we want to keep the keys in the APK somehow but store them securely. That way we don't have to make a server request for these private keys or a partner key in an asymmetric system. The APK file itself is fairly easy to reverse engineer and decompile, including the resources and the Java code.

We are using a C library in our application, however. We are using a .so file of this library compiled for the ARM architecture. We use the SWIG interface from our application's main Java code to interact with this library. I am wondering if I can store the private keys in this library's source code and then access these keys via SWIG binding functions. I think this is the best solution for my problem because ARM .so files require a fancy commercial decompiler and knowledge of the ARM architecture to effectively reverse-engineer them. Thus making this method of getting the private keys pretty darn secure.

4
  • 2
    You're wanting to access the key from java, right? In that case, one easy way to circumvent it would be to attach a debugger and grab the key once you've called the method to retrieve it.
    – JesusFreke
    Commented Apr 16, 2018 at 18:00
  • The practice of hard coding cryptographic keys has its own CWE entry: cwe.mitre.org/data/definitions/321.html
    – julian
    Commented Apr 16, 2018 at 18:04
  • how about doing all of the decryption and other stuff in the C code? Commented Apr 16, 2018 at 18:27
  • 2
    your "pretty darn secure" is trivially broken for most seasoned reverse engineers.
    – sudhackar
    Commented Apr 17, 2018 at 5:19

3 Answers 3

3

Hiding the keys anywhere in the apk (including .so files) is definitely not enough to keep the keys secret for the long time. The code that can be executed definitely can be reverse engineered, and the key could be extracted - even without having fancy decompiler and knowing ARM architecture well (by the way, there is a non-commercial decompiler for arm32).

I strongly suggest you to read something about white box cryptography and search for the solution in this specific area which was developed in order to solve this kind of problems.

7

If your application can decrypt the files, then you should assume that anyone sufficiently interested can do so as well. End of story.

Obfuscation can slow people down, but it won't stop everyone, and it probably won't be as effective as you think it will be.

3

We are using a C library in our application, however. We are using a .so file of this library compiled for the ARM architecture. We use the SWIG interface from our application's main Java code to interact with this library. I am wondering if I can store the private keys in this library's source code and then access these keys via SWIG binding functions.

I'm totally sure you can, but what stops someone from taking that C library and passing it through objdump or Radare and figuring out where your key is stored? With something like binwalker it may require less skill than if it was in Java. If you store it as a string, /usr/bin/strings itself may pick it up.

ARM .so files require a fancy commercial decompiler and knowledge of the ARM architecture

Not really: objdump (-marm) and radare support ARM. If you've never played around with those give it a shot.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.