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.
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:
Better-secure communication between our web services and our mobile apps.
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!