How was AES Encryption cracked on my app?

Question

I built an app that used AES encryption with 16 characters Key and IV. It seems it could easily be hacked, as someone did it in a day.

I feel that I made a few mistakes

1. Used key & IV which was only plain text length of 16
2. Key not hashed with SHA-256
3. It was an Android app ( Xamarin Forms) and I did not obfuscate the app

Can anyone guide me on what went wrong?

[Updates]

• The app needs to operate in offline mode. That's why I hardcode keys in the application.
• This app is reading information from QR Code encrypted content. An attacker able to create a QR Code with fake information that becomes a valid QR code

Answer 1

If the characters are from $[A..Z]$ and $[0..9]$ then that makes 39 possibilities per character (byte). Then the keyspace will be $39^{16}$ and that is approximately 83-bit. This is space is achievable with supercomputers but not for ordinary people. Therefore, there must be something else around that cracks your system.

Used key & IV which was only plain text length of 16

That is not a good way.

• The IV must random, though, your mode of operation is not clear therefore we cannot recommend the exact usage. In short, we can say that a (key,IV) pair must be used only once. You can use Android's secure random to generate the random IV.

• For the key, one should go for the diceware or Bip39 to have good strength on the password. The user can still have a longer character than 16 so that at least 128-bit strength is achieved. With the password, the memory-hard password hashing algorithms like Argon2 to reduce the attack capability of the attackers.

Key not hashed with SHA-256

SHA-256 is not a password hashing algorithm we have Scrypt, PBKDF2, and Argon2 for those kinds of problems.

It was an Android app ( Xamarin Forms) and I did not obfuscate the app

This sentence indicates that probably you hardcoded the key into your application. And the attacker resolved the key by getting the package and analyzed the reversed byte code. This is not the correct way to store a cryptographic key.

If you want to communicate with your server use DHKE with your server to create the session key and possibly the IV by using the full exchanged key with HKDF. Then apply AES-GCM or ChaCha20-Poly1305 to achieve the authenticated encryption. In this way, you don't need to store secret keys. You only need the public key of your server. With this, you can achieve, forward secrecy, confidentiality, integrity, and authentication.

If you want to use app-in encryption, then get the password with a good strength from the user and derive the encryption key by using Argon2id.

You may also have the benefit of using the Android-KeyStore if that fits your needs.

---

updates

[Update] This app is reading information from QR Code encrypted content. An attacker able to create a QR Code with fake information that becomes a valid QR code

As Fgrieu mentioned that you can use a signed QR. To check the signature one only needs a public key.

• If the content doesn't need to be encrypted, then there is no need for an encryption key.

• If encryption is required, one can either install the key later and store it in the key-store or use a server-client approach so that the device doesn't use the key at all. The client either gets the key temporality from the server, or it can use the server as a decryption oracle while using a secure channel as told above.

[Update] The app needs to operate in offline mode. That's why I hardcode keys in the application

Installing the key later is the solution. You can install the key either manually in Android activity or use a specially designed QR code to read in then store it in the Android Key-Store.

Answer 2

We have little detail on the security goals or the hack (to the point that the question feels detached from reality), thus this answer is not specific.

1. Used key & IV which was only plain text length of 16

The key length of 16 chars (AES-256) is unlikely to be a real practical issue for a short-term attack. Even if we restrict to 32 = 2⁵ possible values per char, that's 80-bit, which is at least hard to break. An exception is if the key was in the code (see 3), where directly using a text key (especially if it on the tune of "MyZup3rZ3cr3tK3y") helps attack.

The IV of 16 bytes is standard, and OK in practice if it does not repeat. Constant or otherwise repeating IV can be a disaster, especially with the common AES-CTR, just like a reused pad in the OTP.

2. Key not hashed with SHA-256

That's not an issue, if the key is random. If it's not (e.g. derived from a password or passphrase), SHA-256 is inadequate and it's needed a purposely-slow "password-based" hash, e.g. scrypt or Argon2.

3. It was an Android app (Xamarin Forms) and I did not obfuscate the app

If the key was in the app's code, it's quite possible it was extracted from there. While obfuscation helps to a degree, embedding secret or private keys in code is fragile, and bad practice. Yet it's common because the alternatives are more complex, and either hardly safer or not portable.

It's also entirely possible that a hack worked around the crypto without breaking it, e.g. that code which execution is conditioned by a cryptogram was executed without cryptogram, by bypassing the test.

When a standard API is used for the crypto, that API can be where a competent hacker watches, and that can be a disaster if confidential data transits here (this is the point of encryption). Or if the key transits here, which sometimes is unavoidable (when AES is used to communicate with another device or server, and the API does not have provision for encrypted loading/export of keys).

This app is reading information from QR Code encrypted content. An attacker is able to create a QR Code with fake information that becomes a valid QR code.

What about signing the QR code? The public key can be embedded in the app, and it becomes impossible to forge a QR code that the real app will tell genuine, no matter the reverse-engineering. For small QR codes, and if something standard is thought, ECDSA or EdDSA would be fine.

Answer 3

Let's start with a couple bad assumptions you made

 The app needs to operate in offline mode. 
 That's why I hardcode keys in the application.
    

Anytime you hardcode keys into an application, you have NO security. ALWAYS assume that an attacker can get your source code or reverse engineer it and can get what they want.

You should only consider an application secure when an attacker has your source code and knows all of your algorithms. Consider all of the standard encryption and hash algorithms. These are all public yet, given an attacker has all the source code for AES, it is still considered strong, even if the attacker knows the ciphertext and IV, but not the KEY. Similarly, SHA256 is considered unbroken even if the attacker knows the output and the algorithm, they cannot derive the original input.

 It was an Android app ( Xamarin Forms) and I did not obfuscate the app

Any time you are considering security using obfuscation, you are not spending your efforts wisely. If you think your application would have been secure if you obfuscated it, you are wrong. The application still needs to run in the Android environment and there are a ton of apps that will reverse engineer the code. If they reward is big enough, someone will spend the time. You may slow down an attacker a little, but only a little.

Answer 4

You should not give the key to anyone not authorized to encrypt and decrypt data with the key. The key should be providing the security, not your app.

The reason AES didn't provide you any security was that you were not using AES as your security mechanism. You were using your app as the security mechanism.

Are users supposed to be able to decode QR codes but not encode them? Then don't give them the key that encodes them. Use an asymmetric scheme like RSA or ECDSA and only give the user the key used to verify the QR codes.

You don't explain your requirements well, but it sounds like you simply aren't using the encryption scheme as the security scheme.