1

To use our platform and APIs, a client requires integration of iOS and Android SDK on their mobile apps. Each of the clients is issued one API key, like any other platforms such as Crashlytics, MixPanel, etc., to communicate with the server.

We are trying to obscure the keys during any kind network interception or MITM. However, this seems to be a tough job.

So far we have tried following:
1. Storing the client keys in the key store, keychain.
2. Change the header, JSON parameter names to confuse the attacker.
3. Putting the keys in a file and then transmit it over the network.
4. The first and last call method. We are hashing the first request timestamp and then comparing it with the next consecutive calls. If the timestamp is greater than the first timestamp, then we can assume that an attacker isn't trying to replay the calls for abusing the platform.

We cannot allow keys to be seen by the attacker for a reason, each and every call is being billed to the client, and anyone aware of our platform can cause tremendous damage to our customers just by replaying the requests to our server.

How do we ensure that keys are securely transmitted and are not visible to the attacker?

Note: Once the SDK on a mobile app goes live, for a client, we are updating the keys at different hours of the day and storing in the keychain, keystore.

Thank You
Fennec

Improve this question
3
  • 3
    the app should talk to it's own server, which then talks behind the scenes to your API. in short, don't have other people's users consume your API directly because there's no way to secure that from the user.
    – dandavis
    Dec 7, 2016 at 16:33
  • 1
    dandavis makes a very strong point: trusting the integrity of the client is a losing bet. Don't put shared-secret keys in the client. But I'd be curious about an additional detail: have you researched other mobile apps' ways of dealing with this? For example some apps that integrate multiple platforms will have the client go and get OAuth access tokens for the necessary platforms. Can your platform support this?
    – Jacob
    Dec 13, 2016 at 18:44
  • No, we cannot support each and every customer of the client to authenticate with us, because the API consumption is entirely a background process, not on the frontend. If we ask our clients to authenticate the users they might not want to use the services because of a. we do not want the customer's users information. b. It will be an overhead for small, bootstrap start-ups.
    – Fennec
    Dec 14, 2016 at 6:04

1 Answer 1

Reset to default
5
+50

This depends on the kind of attack you expect:

  • If the attacker is purely on the network trying to do a man in the middle attack then protecting the connection with TLS (i.e. HTTPS) should be sufficient. Additional protection can be added by using certificate or public key pinning.
  • If TLS/HTTPS is not an option you can used digest based authentication for a proof that the client owns the token. You could of course also combine it with TLS.
  • If you fear that the attacker can get access to the app and extract the key you've lost anyway. In this case you can only try to limit the impact, i.e. use code obfuscation to make reverse engineering and extracting the key harder, employ rate limiting to limit abuse and change the access key and obfuscation strategy often enough, i.e. ideally before the key gets exposed.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .