Key management: Detecting that a key has been compromised?

Question

I am looking at communication between our iOS/Android mobile app on the one side, and our RESTful web services API on the other side. From the server side, I have to assume that anything I receive is suspect. I assume the mobile app could have been reverse-engineered, secret/private keys harvested, etc.

Assuming that we are correctly doing HMAC-protected symmetric-key communication, when I receive, authenticate, and decrypt an encrypted message, I know that the message was sent by someone possessing our shared secret key.

This message could, of course, be coming from an attacker who has obtained that secret key.

I’m wondering if there is a formal protocol or best practice in the key-management area that addresses this issue: As the receiver, can I detect that the shared secret is, or may have been, compromised? I think the answer is that No, there is no such “easy” solution. But if there’s an answer I’d like to know it!

I suspect that there is no answer in the key-management area. This is really “How do I authenticate the sender of the message, when the sender is our mobile app downloaded from the app store?”

Keeping signatures valid after private key compromise discusses embedding a secure timestamp from a trusted third-party timestamp provider. I don't think that helps, when I assume the attacker can do anything the compromised mobile app can do. That's the nature of web services.

ADDITIONAL INFORMATION

After observing attacker(s) of our Web Services API, I am looking for ways to improve our security architecture. I don't want to ask something so vague as to be useless!

Here's our situation as I understand it. We're eager for recommendations.

We have a relatively high-traffic web site (top 1,500 by Alexis USA rank) that's been around many years. That means we have strong experience in protecting "normal" web site and attacker traffic.

We have found that RESTful APIs connecting to our mobile app is an entirely different arena. It's quite likely that I'm not asking the right questions. I don't yet truly understand the problem space!

All API traffic is over HTTPS. I'm confident that we have transport-layer security correct because that's part of our "regular" web site experience.

Our attacker correctly uses the web services with correct authentication tokens, etc. Up to that point (the point of observing that particular set of attacks) our API traffic is plain text over HTTPS. We have mobile apps for iOS and Android in Apple and Google Play stores. Mobile app development is under our control.

From this we conclude that our attacker was able to observe our plain-text-over-HTTPS mobile app traffic. Or that our attacker reverse-engineered our mobile app (which is less likely given the higher skill level needed).

Therefore I think the places we need to improve:

1. Better-secure communication between our web services and our mobile apps.

2. Better protect our site (server-side) from attack via the web services.

I hate to ask such a wide-open question, but can I get advice / references on making these security improvements? I have asked several questions and received excellent advice over the past week, but that does not mean that I yet fully understand the problem space!

Answer 1

As the receiver, can I detect that the shared secret is, or may have been, compromised?

In short: whatever you put into the publicly distributed application you implicitly share with an attacker and (s)he will not tell you once (s)he extracted these secret information.

In detail: In the scenario you describe the secret is embedded into the application and thus implicitly shared with anybody who is able to download your application. Because of this broad distribution of the (only obfuscated) shared key you must consider that it is either already compromised or will be compromised, at least if there is something valuable to gain when using the key outside of the intended use case.

Probably the only way to detect a definite compromise is if the key is obviously used outside of your application. You might detect this with methods of anomaly detection. But if you don't detect the compromise it does not mean that the key is not compromised, it could simply mean that the hacker was smarter than you and hides its activities clever enough so your anomaly detection will not catch it.