How to store ECDSA public key securely in Android

Question

I am writing an Android application that needs to verify that a request is sent from a trusted party (me).

This is my current solution:

Storing keys:

1. Generate ECDSA public key / private key from a server.
2. Store private key in server. Store public key in Android app, hard-coding it as a static final String.
3. Deploy Android application.

Request some action from server to Android app:

1. Server requests a challenge message to the Android app.
2. Android app creates a random String and sends it to server.
3. Server signs random String with private key and sends it to Android app.
4. Android app verifies signature from server, if signature is verified, perform some action.

The question:

From what I understand, it is easy to reveal the server's public key by decompiling the APK. Then it seems pretty easy for the attacker to recompile the APK with the attacker's own public key, rather than the server's key.

If my understanding is correct, how can I securely store the server's public key so that an attacker cannot modify it?

Answer 1

You really do not need to worry about that, that is the reason its called public key. You should instead seek to secure your private key, because its the key you actually use to sign the data and it is only required to use the public key pair to verify the signature on the data. If an attacker uses another public key that is different from the one that was generated with your private key, it will fail verification. What you should worry about is if the attacker could de-compile your application and by-pass the logic for verifying the data/document.

And to handle your tampered (re-compiled) android application concerns, you can ensure any application that is making a request to your server comes with a token in the request header that was generated using the application signature as a salt. This signature can be generated from calling some android API's that retrieves and computes the key you used to sign the app during release/debug build (release build should be ensured). So if an attacker de-compiles your app and re-compiles it again, definitely your previous signature has been invalidated as the attacker would be forced to use a new key to sign the app. This time if this modified app calls an endpoint from your reverse engineered app, it would generate and send a token different from the original one. So from here you simply block the IP or just respond with code 401 from your server since the token in the header does not match what you are expecting.

This time, you need to secure the keystore file that you used to sign the app when you were building a release version. Don't track your keystore file with a versioning system like GIT in your code base, because once this file is in someone else's possession not in your organization, then the previous security implementation is screwed once an attacker gets hold on it. I hope i have been able to clarify some concerns of yours. Good luck

Answer 2

You should use HTTPS Public Key Pinning or Certificate Pinning to simplify.

In this case, your app's business logic will never perform crypto operations on the server payload.

The underlying transport level (TLS) is initialized with the list of keys/certificates to accept to consider the connection as trusted.

You should also accept that a determined attacker, not necessarily a so-called government-level attacker, may still alter your pinned key.

I know at least one method that theoretically works: XPosed modules, running on customized/rooted devices.

If my understanding is correct, how can I securely store the server's public key so that an attacker cannot modify it?

You should not have your security depend on this. Despite your efforts to securely build your application, any application running on hardware not under your control 1) is not your application and 2) is comparable to a public Github repository.

The first statement comes from literature, the second is mine.

You should review your threat model.

1. Who can benefit from altering that key? The device owner or a third party?
2. Who gets damaged from altering that key? You, or the device owner?